CSA_1

Estimating the Size of Scrum User Stories

• November 28, 2016• 2 min•

In Scrum, the owner of the estimates is very clear.  Only the people who do the work, i.e., the Team, have the right to offer estimates for the Product Backlog and Sprint Backlog items.  However, like many things in Scrum, the framework leaves it up to each Team to decide on what is estimated during planning.  Because Scrum Teams are self-organizing, they can choose to estimate duration, effort, size, complexity or anything else that makes sense to them.

When I work directly with teams, I prefer the Team to estimate the size of user stories using story points rather than the duration or the effort.  Jeff Sutherland, co-creator of Scrum, is also a big proponent of story points in this article on why story points are better than hours.  Here are my reasons why.

  • What are all the engineering tasks associated with completing the Product Backlog item?  For a Team to have a reasonable conversation on this topic they will need to know the detailed requirements, which may not be available at this stage.  Furthermore, since engineering tasks are defined just-in-time (JIT) during Sprint Planning, taking time to decompose a Product Backlog item into its constituent activities requires the Team to make design choices, review the existing state of the code and converge on the details of the technical solution.  We prefer to defer these detailed discussions to a point when the Team is ready to build the story.
  • Who is going to do the work?  On most Teams, there is a great deal of difference in the skill set, knowledge, experience, productivity and domain familiarity among Team members.  How one member of the Team estimates the duration of a specific engineering activity is going to be quite different from another would estimate the duration for the same activity.  Again, those decisions are typically completed JIT as part of Sprint Planning.
  • How are we going to use the estimates?  In many immature organizations, estimates are treated as commitments to deliver rather then educated guesses based on uncertain information.  In these companies, estimates are tracked against actuals.  I once saw a client who evaluated their staff on their ability to match their actuals to ±10% of their initial estimates – Yikes!  When story points are used, this encourages leaders and senior decision makers to remember that an estimate is a high-level guess and not a promise to deliver.  Providing estimates in person-days (or hours) gives a false sense of confidence in the accuracy.
Of course, no discussion on estimation would be complete without mentioning the #NoEstimates movement.  Modern Agile, created by Joshua Kerievsky from the Bay Area, also stopped using estimates (and story points) beginning as early as 2012, so it certainly is possible to be a good Agile team and not estimate.  While I am not a proponent of #NoEstimates, most of the more advanced Scrum and Agile teams I have seen have done away with estimates altogether and focus on continuous delivery of customer value.