FAST RACE Agile Estimates

The most common question around agile estimates:

  • What are the benefits of Story Points vs Hours?
  • How to estimate and execute fixed triangle projects?
  • How to estimate Sprint to be more accurate and predictable?

Story Points vs Hours

Story Points are turned to be very popular for estimating Product Backlog. Story Points are effective when RACE principles are respected:

  • RELATIVE: Product Backlog items estimated relatively to each other using Fibonacci sequence;
  • ACCURATE: Team continuously refines and break down larger stories into smaller items to increase accuracy;
  • CONSISTENT: “1” Story point meaning established at the beginning and never changing over the time;
  • EMERGENT: Product Backlog is estimated for the next 4-6 months; new items or stories should be estimated.

The benefits of Story Points and RACE is that you can effectively measure velocity of the completed Product Backlog items and apply it to the remaining size of the Product Backlog. With RACE in place Story Points will be reliable for forecasting future release plans.

To demonstrate effectiveness of the Story Points you can try out the Paint the Story Point game.

From the other hand absolute estimates as hours are effective to use at the task level in the Sprint Backlog, keeping in mind FAST principles:

  • FOCUSED: Product Backlog items are decomposed into implementation tasks which are usually one day or less;
  • ABSOLUTE: Absolute units as hours are easy to understand. On the low level it also shows that the team understands how to accomplish the task;
  • SUSTAINABLE: Development Team updates remaining estimates at least once a day and review the progress at the Daily Scrum;
  • TRANSPARENT: Hours can be compared to the current capacity at any day in the Sprint. Sprint Burn-Down chart is very common techqnique for assessing the progress.

FAST indeed explains the benefits of using hours at the implementation task level.

How to plan and estimate fixed triangle projects?

I would like to refer to the article which describes the case study at:

The only thing I could add is that the fixed triangle makes sense for reasonably simple projects. For more complex projects the customer should be ready for change management and revisit triangle variables, at least agile helps change management to be extremely transparent.

How to estimate Scrum Sprint to be more accurate and predictable?

In Scrum Sprint we try to focus a team on how to deliver a value in the most effective way. Estimates can create some pressure to be very focused on the individual tasks rather than on the shared goal of the Sprint. I don’t recommend to rush for predictability and accuracy at the very beginning. Please, find some useful thoughts on estimates at:

Leave a Reply

%d bloggers like this: