[QUESTION] Why Do Scrum Teams Estimate in Story Points Instead of Hours?

Management wants to know how long it will take to get something done. The problem is that people are terrible at estimating features in hours. Why? Because it is hard work, inaccurate, and not a lot of fun. Scrum teams have a better way – story point estimation.

Steve Dalton | Poker Planning | Flickr

Steve Dalton | Poker Planning | Flickr

Hours or duration is complex to estimate on software projects. Teams and individuals are expected to figure out how many hours a particular user story will take to implement – before doing any actual work. It’s not surprising that 60% of software projects fail at this task.

Hours have a different meaning to different people. Developers have varied skillsets, abilities, competencies, domain knowledge, and experiences. Given a diverse development team, a consensus on how many hours a user story will take to finish will be extremely difficult to reach.

For example, let’s take two developers – Senior and Junior. They have been asked to estimate USER STORY X. Senior, who has many years of experience, thinks that USER STORY X will take 5 hours to complete. Junior, who just graduated from college and is working at his first job, and thinks that it will take 10 hours to complete the story. There is no way to reconcile these estimates and reach consensus.

Even if the hours could be reconciled, the meaning behind the hour estimates are unclear. Is that 5 hour estimate expressed in ideal time or elapsed time? In other words, is that 5 hours of work assuming no interruptions, distractions, and other commitments? OR is that 5 hour estimate really 20 hours in duration because the work was spread over 3 days due to meetings, disruptions, or other life events?

Instead, scrum teams use story points – a unit of measure for the size of a user story. The actual values and units are not as important as the value of the stories relative to one another. A story that is a 10 should be twice the size of a story that is a 5. The estimate is also all inclusive. Everything that is need to get the user story completed is considered in the process.

In our case, Senior and Junior can decide that USER STORY X represents 1 story point. They could then look at other user stories on the product backlog and decide the story point value of the remaining user stories based on their relative size to USER STORY X.

This abstraction removes the complexity of estimating in hours and simplifies the estimate to a relative sizing exercise. Mike Cohn put it best in his excellent book Agile Estimation and Planning:  “A story-point estimate is an amalgamation [consolidation] of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherit in it, and so on.”

Hours based estimating is popular, but it is also more complex. It is also frequently wrong. There are many variables that are out of your control that you end up having to factor in (more guessing) or ignore (bad guessing).

Estimating is waste. Customers do not pay for estimates. You can’t claim ROI from an estimate. Scrum teams do not deliver estimates at the end of every sprint, they deliver working software. Estimates have no intrinsic value. So why invest a lot of time on them?

Since scrum teams know that they are going to be “wrong” when estimating, they use story point estimation to quickly and inexpensively size their user stories. As they inspect and adapt their work during and after each sprint, they can revisit their estimates and adjust as needed.

Scrum: Velocity Measures Story Points, Not Productivity

Scrum teams rely on metrics to inspect and adapt. Taken too far, the metrics tend to lose value and in some cases cause harm.

Robert Donovan | Velocity | Flickr.com

Robert Donovan | Velocity | Flickr.com

Last week I wrote about 5 agile metrics to measure high-performance scrum teams. At the top of the list was the most controversial metric that scrum teams use: velocity. This seemingly simple metric is just a measurement of how much effort a scrum team can complete within a given sprint.

Velocity is – in its simplest form – the sum of the story points completed in a sprint.

The temptation that many organization face is to turn velocity in to a performance metric.

For instance, I was recently asked what I thought about setting an objective to increase the team’s velocity by 10% by the end of the year. My answer: It’s a terrible idea.

  1. Encourages gaming:  An intelligent scrum team will realize that if they gradually inflate their estimates over the course of a year they will hit their 10% objective – WITHOUT delivering more value to the organization.
  2. Increasing velocity is not the goal of scrum:  We are interested in delivering valuable, high quality software to our companies in a sustainable way. How does a 10% increase in velocity get the scrum team there?
  3. Quality suffers as a result:  A scrum team that is forced to increase velocity will have to make tradeoffs to complete the additional stories required to get the numbers higher. Quality inevitably suffers when these types of decisions are made.
  4. Lots of unknowns:  Scrum team members leave the company, they get sick, and go on vacation. An estimation can also be way off – it is an ESTIMATION. If the scrum team learns something new about a story, velocity can dramatically go up or down.

Another idea that managers try is to compare the velocity of one scrum team with another. This is usually an attempt to normalize velocity across multiple scrum teams. It’s a meaningless comparison as scrum teams have different skills, goals, tools, and approaches to estimating work.

Flame wars often flare up over questions like: “Does a scrum team get credit for the story points related to bug during a sprint?”

Some scrum team members say, “Yes! We did the work and it should show on our velocity.” Others say, “No way, you already got credit for that story and are now cleaning it up. No double dipping!”

Mike Cohn did a great job of answering the question here. Essentially, he says pick whichever way makes sense to your team and be consistent. Easy, right?

Questions like these come up regularly and show a general lack of understanding of how velocity should be used.

Velocity is a limited metric that can only tell you what you achieved in the past and could possibly do in the future. During sprint planning it can help a team avoid over committing. During a sprint retrospective an up or down trend in velocity could lead to a discussion about the team’s definition of done or other team practices.

And there is the value that comes from tracking velocity. It is in the conversations that it causes the scrum team to have. These discussions are opportunities for the team to inspect and adapt their practices. The new insights will hopefully lead to more valuable, working software being delivered to the organization.

Which is important because according to the Agile Manifesto, “Working software is the primary measure of progress.”

Question: Which metrics do you use to drive conversations on your scrum team? You can leave a comment by clicking here.