[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.

Kindness is the Missing Agile Value

The agile community is vibrant and passionate – full of people with great ideas on how to deliver valuable work. It can also be a difficult place to visit. We need to fix that.

Quinn Dombrowski | Hey Listen! | Flickr

Quinn Dombrowski | Hey Listen! | Flickr

To change the heart and mind of another person you first have to understand where they are coming from. You learn their story by listening. I don’t mean the kind of listening where you wait for your opportunity to drop your agile knowledge on the someone.

I’m talking about actively listening to the person and asking clarifying questions. As you gain knowledge about the person you can begin to make suggestions that are relevant to their present situation.

This does not mean that there will not be resistance to your scrum or agile suggestions. People not used to “just in time” planning or “self-organization” will likely not understand the concepts on the first pass. They will probably reject the ideas immediately.

This happens for a number of reasons:

  1. Fear:  Change is scary. It makes your problems transparent and places you in a vulnerable situation. Change means you are taking on something that is new to you. What if you look stupid? What if you fail?
  2. Success:  Management and project leaders have built careers on waterfall practices. Many have found success and promotions by adhering to predictive processes and practices. Convincing these people that agility is a more productive path is challenging.
  3. Culture:  Even if the results are not perfect – half of all waterfall projects struggle to deliver – people like the comfort of a culture they know and understand. In an agile world many traditional project behaviors do not play well. The rules change.

What this all boils down to is a user story that we are all working against when promoting agile in our organizations:  AS A PERSON I WANT PREDICTABILITY IN ORDER TO FEEL SAFE.

It is a tough nut to crack. But this user story is our reality. Where do we begin?

Be kind.

Do you remember when you were first introduced to agile? For me it was reading Kent Beck’s Extreme Programming Explained. I loved that book. It just made sense to me. And over the past 12 years since reading it, I’ve worked on my agile game. Guess what? I still struggle.

The truth is we all struggle. So be kind!

Agile is nuanced. And it is hard. If it wasn’t hard, agile coaches would be out of work and you wouldn’t be reading this blog. “It depends” is a common answer in our world, we work hard to push new ideas, and the agile space changes constantly. So be kind.

Being kind means that we accept that the first sprint of a new scrum team isn’t going to be perfect. It means that when answering a question online we do not belittle or berate people who are honestly seeking insights and feedback. It means we listen first, then speak.

Kindness is also shown when we are patient with those who still cling to their predictive processes, waterfall tendencies, and command and control mindsets. The path to agility is a marathon, not a sprint. It takes time to create new habits and practices. So be kind.

People do not show up to work with the intention of ruining your day. They have many of the same pressures that you do: spouse, kids, bills, and bosses. I believe that most people want to do the right thing. Let’s be the humble servant leaders that the agile principles call us to be and help them come around to the agile way of thinking. Listen, learn, and lead.

And yes, let’s be kind.

Question: Do you have a story about someone taking the time to help you learn agile? How did someone in the community make an impression on you? You can leave a comment by clicking here.