Initial assessment: Blink Estimation
I got a group of really smart people in a room, with at least 10 years’ experience each, and asked them.
Dan North, “Blink Estimation”
For initial assessment of whether something is worth attempting at all OR to choose between different options, I prefer Blink Estimation, aka project-scale Planning Poker.
Key points
- Ensure all relevant perspectives are represented
- Requires experienced participants
Just enough refinement before starting: User Story Mapping and Swimlane Sizing
Talk about the user’s journey through your product by building a simple model that tells your user’s story as you do.
Jeff Patton, “User Story Mapping”
After the initial rough sizing, in order to get just enough refinement to start delivery, I prefer using User Story Mapping to further break things down and design releases. If additional estimation is needed to roughly size releases, I prefer using Swimlane Sizing.
Key points
- When User Story Mapping, go for full breadth and just enough depth
- Just enough detail and only for the first release or two. Refine the rest later.
To reduce the risk of inaccurate estimates: Early Release
If you aren’t embarrassed by the first version of your product, you shipped too late.
Reid Hoffman
Early Release is the main trick to avoid having to worry so much about whether estimates are super accurate or not. If you have a target launch date, design your release strategy such that a minimally acceptable version is ready by at latest, the 50% mark. Everything after is “gravy”. It’s no longer, “will it be ready to launch?”, but rather “what should we add next to make the launch the best it can be?”
To avoid overcommitment for iterations: Break things down into small Stories and just count them.
When you break down work into Stories that are roughly 1–5 Story Points, you’ll begin to notice that they average out to 2.something. Many teams started to notice this and thought: “Instead of using Story Points, why don’t we just count Stories instead?”
Jason Yip, From “Load Factor” to “Velocity” to “Story Points” to “Counting Stories” to “Lead Time” to …
If you’re working in timeboxes (i.e., Iterations or Sprints), to avoid overcommitting, I prefer breaking things down into small Stories and just counting them. Don’t bother with Story Points or similar at the Iteration-level.
See also
See George Dinwiddie’s Software Estimation Without Guessing for a more detailed exploration.
