My preferred approaches to estimation on Agile projects

Jason Yip
3 min readJan 1, 2023


Initial assessment: Blink Estimation

For initial assessment, use Blink Estimation. Is this worth attempting? Which one is a better bet to take?
Blink Estimation for the initial assessment

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

For refinement, use User Story Mapping and Swimlane Sizing. Roughtly, what do we need to build? Roughly, what should the releases look like?
User Story Mapping and Swimlane Sizing for refinement

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

To reduce risk with inaccurate estimates, use Early Release. From “Will it be ready to launch?” to “What should we add next?”
Early Release to reduce the risk with inaccurate estimates

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.

To avoid overcommitment, count the stories. How much do we typically complete, week-by-week?
Count the stories to avoid overcommitment

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.



Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl