Why Should I Use Story Points for Estimation?

As someone who transitioned from regular Waterfall Software Development to SDLC, a big problem for me and the team was moving away from estimates in Man Days and the urge to have an “Accurate” estimate for the user stories under consideration. Yes, it was very hard to give up on old habits and we eventually did it because it was beneficial in the long run. 

In the previous article we understood what a Story Point is. In this article we are going to talk about 5 reasons as to why we must use Story Points and not Man Days when we do estimation for a Scrum project.

Reason 1: It Avoids the Need for Frequent Re-estimation

This is probably a very big benefit for the development team. In most projects, when we do estimation during the planning stage, not all information is available up front and the estimated values consider a lot of assumptions. As the project work begins and clarity emerges, people realize that the originally estimated numbers wouldn’t be enough and the team needs more time to do the implementation. This results in a lot of over-time and stretching from the team in order to meet the deadlines. Yes, an easy argument here is to have the estimates done more accurately but this is easier said than done. I have been working on software projects for the past 12+ years and trust me, even the most experienced developers make mistakes while estimating which is why the story point concept is much easier.

When you provide an estimate in story points, the number does not represent a finite amount of time. It represents a relative complexity and hence if the team identify an extra task or two during the course of development, we don’t need to provide a re-estimation for the entire user story. This makes life a lot easier for the team because they don’t have to worry about the reaction they will get every time they identify something new that needs to be done. This is all the more beneficial because in iterative software development, you learn new things about the product and how you can implement it with every passing iteration with fear of being reprimanded or being forced to stretch to finish the tasks.

Reason 2: It helps Reduce the Team’s Fear of Commitment

One of the biggest drawbacks of traditional waterfall method of software development is that the team is almost always forced to finish the work (and even the extra work that gets identified during the course of development) because they committed at the start of the project that, work will be completed. If we are asking the team to estimate in days for a user story, we are basically doing iterative waterfall where we are forcing the team to commit to deliver a certain man days’ worth of stories in an iteration. By eliminating this need to estimate in days for a story and replacing it with story points, people are under less stress and hence they are more likely to think rationally and even provide better estimates. This is because, when you estimate in days, a fear of whether I can finish this within the X days estimate is always going to be running in the back of the mind of the person doing the estimation and may be counterproductive.

Reason 3: It is Faster

As a continuation to the previous point, before a team arrives at an estimate in man days, they take into account the various issues they may face in future and take a lot of time before finalizing on the number. This typically takes a few days or maybe even more if the story being estimated is quite complex. However, if we are asking for a story point sizing, the team will be able to give a reasonable number much faster because the sizing is relative and doesn’t reflect a fixed time duration.

Reason 4: It does not give a False Sense of Certainty

As with any IT Project, what we plan at the start and what we finish with are two entirely different entities. Things change and we don’t have any choice but to roll with it. That is one of the strong points of Agile; it allows us to Adapt to change. Anyways, getting back to the point at hand, when we estimate a user story in Man days it kind of adds a certain level of Certainty about when the story will be completed. In reality there may be many assumptions that went into the estimate or dependencies that weren’t considered which could require a re-estimation some point down the line. By having estimates in story points which cannot be directly translated to a fixed man day figure, we don’t provide that false sense of Certainty that man days carry.

Reason 5: It encourages collaboration

In order to understand this point, you first need to understand what Planning Poker is.

Scrum recommends that we follow an exercise called Planning Poker to estimate user stories. Each team member is distributed a set of poker cards that contain the Fibonacci numbers. After reviewing each user story, all team members are asked to choose a card from their deck that would signify the estimate for the story per their understanding. The cards kept face down so there is no Peer Pressure. Everyone reveals their cards at the same time and the person with the lowest & highest estimates are asked to explain the rationale behind their estimates. After this, we repeat the exercise until the estimates converge towards a number that the team is comfortable to assign to a user story.

As this Planning Poker exercise is a team effort, the team get to share constructive criticism, have healthy debates and more importantly have fun working together as a team. Good scrum teams use the planning poker exercise of story point estimation as an opportunity for team building and encourage collaboration among members of the team.

As you can see, estimating with Story Points has many advantages. Of course, people who have extensive experience in working on waterfall SDLC projects may have difficulty making the transition from man day estimates to story point estimates. But, if you put in the effort, the results will definitely surprise you because, the benefits I have explained above are not just bookish or theoretical hoopla; they are based on personal experience when I made the transition to using Story Point estimates on my Scrum Project.