What is a Story Point?

After going through the basics of Scrum, the different meetings, the different Artefacts etc., it’s about time we start digging into details of how Scrum could be implemented in a Project.

If you are someone who is not new to Agile Software Development or Scrum, you may have heard the term “Story Point(s)” when people talk about estimates. The purpose of this article is to help you understand what a Story Point is and how you must be using it for your project.

What is a Story Point?

Story Point is a unit of measure for expressing an estimate of the overall effort that will be required to implement the User Story under consideration. Each user story will have a Story Point estimate assigned to it. When we estimate with story points, we assign a point value to the item. The value by itself does not have a meaning and is more of a relative identifier of the size or complexity of the story in comparison to another story. For ex: a story with a 2 story point estimate is perceived to be twice as complex as one with a 1 point estimate.

Instead of assigning numbers like 1, 2 & 3, teams could even assign values like 1000, 2000 and so on. As I said before, the actual number by itself is insignificant. What matters is the relative ratio of the numbers.

What should I consider before Arriving at a Story Point?

As the story point is going to represent your estimated effort to develop a story, the estimate must include everything that could potentially impact the effort. Some considerations include:

The amount of work to do – This is the most important consideration because if there is more work to be done, obviously the estimate will be higher.

Real Life Trivia: For teams that are transitioning from regular waterfall SDLC projects the most common mistake they do is to associate a story point with a fixed duration (either hours or days). Yes, having such kind of a conversion factor makes estimation very easy but that is not Scrum. Scrum recommends that the estimate is a representation of the complexity rather than an accurate depiction of the duration in days the team is going to take to finish the work.

The complexity of the work – The complexity involved in the work we are taking up should definitely be a consideration factor while arriving at the story point estimate. The more complex the work, the higher the estimate will be. As we have already covered volume of work as one parameter, we should be focussing on things like how likely are people to make mistakes while implementing this, do we know everything required to begin work etc.

Risks & Assumptions that could impact the work – The earlier in the life of a Story the estimation is happening, the more uncertainty exists around the requirements because even the product owner is probably still making up his mind about what the product is expected to do. There would be a lot of assumptions and even potential areas for change in the future. All these represent risks to our work and accordingly will result in a higher estimate.

Real Life Trivia: Scrum does not recommend any weightage or order of priority for us to consider among these 3 factors while arriving at the story point number. The team is expected to exercise their judgment and arrive at a number that can help quantify the story’s complexity and work required in a reasonable manner. For example, you could start with a number to represent the amount of work involved. Then you could consider the risks and uncertainties to adjust the number again. The greater the risk likelihood or impact, the greater the impact it is going to have on the number. Then we could consider the complexity of the work to be done. We could consider factors like how much study, trial & error experiments, negotiations with stakeholders etc required during the course of implementation and then adjust the number to arrive at the final figure.

Like I said before, the story point is not a representation of the duration in days or hours but rather is a number that represents complexity. The Story point can be pretty hard to grasp especially if you are someone very used to the waterfall methodology of software development. Nevertheless, if you try to do it for a couple of sprints, you will get the hang of things and should be able to take things forward the Scrum way…