Only estimate when it makes sense

Many Scrum teams are asking at the classes how shall we estimate Backlog Items / User Stories? They seem not to be happy with my reply that you don’t need to estimate at all in Scrum. I try to explain. Estimates can be useful. But in that case something has to happen as a result of the estimation process. I give you few examples of such good situation:

  • Based on the estimate Product Owner decides on priorities. From the two same value stories we prioritize the smaller first as that value is cheaper.
  • Based on big effort estimation we talk about how we can split the Story so we increase the ratio (value/effort).
  • Based on the estimation Product Owner decides not to invest into that Story and remove it from the Product Backlog.
  • We had a good discussion during the estimation process which results in common understanding of the functionality (sometimes all team members feel they understand it, but once we start estimation – for example Planning Poker – we find out that we all have a different functionality in mind).
  • Learn some useful insights from other team members about it. I.e. that testing is going to be very difficult, security is a huge risky issue here, etc.

If nothing from above is applicable, and you only use it to fill estimation box in your tool, you may stop wasting your time.

Finally to estimate when the release will to be done you can better use number of stories done per Sprint than any estimates = guess.


The Great ScrumMaster: #ScrumMasterWay bookThe Great ScrumMaster: #ScrumMasterWay bookLearn more about transforming organizations, leadership, and culture with Agile & Enterprise Coaching. Check our Scrum and Agile training sessions on Sochova.com. Grab a copy of The Great ScrumMaster: #ScrumMasterWay book and The Agile Leader: Leveraging the Power of Influence book.


Disclaimer: All I write on this blog is purely personal and has no relation with any position I have, used to have or will have in the future.