Simple

Links and ideas for creating simpler or smaller stories

Working First, Awesome Later

My basic philosophy is that as I begin a unit of work, my first goal is to simply make the thing work. After it works, I test to see if it solves the problem/adds the value I expect. After I’ve hit those milestones, then I worry about things like usability, efficiency, edge cases.

That isn’t to say edge cases and NFRs aren’t important…they are. But until you’ve proven that you can make the thing work and you have feedback (ideally from a customer) that the thing you’ve just built solves their problem and adds value, any effort spent on more complex scenarios may be wasted effort.

The 3 problems and the order in which I solve them

  1. Can I make it work?
  2. Does it add value?
  3. Everything else

(A valid argument can be made that finding out if something adds value is the most important thing to discover. I agree, but I find that the path to answering that question requires you to build or create something small to get feedback first.)

Patterns for Early Learning (80% value with 20% effort)

  • MVP is rarely “minimum” — focus on learning
  • Test the system first, then worry about customer value
  • Happy Path first — Pretend it is easy
    • Make assumptions (all users are the same and they don’t make mistakes)
    • Skip configuration
    • Skip interfaces
  • Split on variations in data
  • Split on variations in complexity
  • Build the thing with the fewest options first (reduce choice)
  • Use INVEST to test your stories for splittability
  • Walking Skeleton/Thin Slice
  • Find the RAT
  • A fantastic story splitting flowchart

Misc. Links