Why do we use Story Points for Estimating?

Story Points - An Introduction

The scrum guide tells us that estimates should be provided by people that will be doing the work but it doesn’t tell us how we should provide estimates. It leaves that decision to us. A common tactic used by scrum teams is to estimate using a unit of measurement referred to as the Story Point. But why use Story Points instead of hours or days or any other well-known unit of time? Are we deliberately trying to obfuscate?  

What is a Story Point?

“A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements“

Why use Story Points?

Story Points are intended to make team estimating easier. Instead of looking at a product backlog item and estimating it in hours, teams consider only how much effort a product backlog item will require, relative to other product backlog items.

Ok, so it makes estimating easier but how is that useful? Story Points are of no value whatever to a business because they can’t be used to predict cost or delivery dates. Even the Scrum team cannot make any predictions as to how many Story Points it can complete in a sprint (velocity) until it’s got a few sprints under it’s belt, some months down the road.

Story Points are confusing. What’s wrong with using time as a unit of measure?

For hundreds of years we’ve had standard units of time. Why can’t we use hours or days? Well, in a nutshell, because your hour is not the same as my hour.

If you ask two developers to estimate the same task, you’ll get two different answers. While some of the difference might be explained by gaps in the specification or understanding, the fact is that developers have different knowledge and experiences so it will take more or less time to do the same work.

Ask those same two developers to rate the amount of effort required to complete one product backlog item relative to another product backlog item and you’re far more likely to end up with a consensus.

The real reason for using Story Points

So, up until now, you may have been unconvinced about the need to use Story Points.

Ok, they show the relative effort to complete work on different product backlog items but how does that help anything? Until we understand what the team’s velocity is, we still can’t predict when product backlog items are likely to be completed. Worse, if the membership of the team changes, the velocity will change and we won’t know what that new velocity is until some time down the road.

All these problems have led many to try and make a correlation between Story Points and time. But to try and match Story Points to hours is missing the point. What’s important is how many Story Points a team can complete in a sprint, known as the velocity. When you know this, you can make some predictions and you know what, they’re likely to be good. Very good.

The real reason for using Story Points is that they’re accurate.

Who says so? Jeff Sutherland, the co-author of the Scrum Guide. In his article on 'Why Story Points are better than hours' he puts it like this:  Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

Comments

Post a Comment

Popular

Application of Scrum Values

The essence of Scrum are the 5 values. A Scrum-Agile project will not be successful unless these values are demonstrated in every event, while preparing every artefact and while performing any role. In fact, these values can be demonstrated in any environment to reap benefits. Here are 10 practical instances for each Scrum value that any team can demonstrate: COMMITMENT Team members dedicate themselves to achieving the team's goals and doing their best work. They commit to the sprint goals and support each other in meeting those commitments. Team commits to delivering specific user stories in the sprint backlog, even when facing technical challenges or scope creep requests from stakeholders. Team members commit to rotating on-call duties to ensure continuous support for critical production systems across different time zones. When a legacy system needs modernization, team members commit to learning new frameworks or cloud technologies requ...
Read more

AGILE Mindset

Do your project teams have an AGILE Mindset? Delivering projects using AGILE as a methodology is no longer 'one' of the options. It is the 'only' option especially for Organizations engaged in IT services, Product & Mobile App development. For that matter, even Organizations in other sectors like manufacturing, Infrastructure and even Consulting are considering delivering some of their projects in an AGILE way. Many Organizations who have implemented AGILE as a methodology have fallen back to other traditional methods or are struggling to make it a standard practice. Having seen a number of AGILE projects from the inside and outside, I have a few thoughts on the common mistakes made by Organizations and project teams when delivering projects the AGILE way. If you are considering going the AGILE way or have encountered challenges while implementing the AGILE way, I have a few probing questions for you. The answers to these questions may hold the key for a successfu...
Read more

Science of Influence

One of the traits that Project Managers or any Leader needs to develop is the ability to influence. Every project ecosystem consists of Stakeholders, internal and external. These include your own team members. The ability of a Project Manager to influence these Stakeholders will ensure that the project is in control. Dr. Robert Cialdini has developed 7 principles of influence which can be used by Leaders to influence others. 1.  Reciprocity :  When you do people a favour, they tend to respond in a manner you want them to. However, there are some points to note. - I t’s not about what is given, but HOW AND WHEN IT IS GIVEN . Be the first to give the favour. - Let it be personalized and unexpected. Tell them ‘ I am doing this only for you ’. Suppose, you have done a favour to a person and he/she says ‘Thank you’. What is your response? Many of us say, ‘Its okay’, ‘It was my duty’ etc. Some rare person may say ‘Now you also owe me a favour’.  Instead use this principle Respo...
Read more