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.

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…

Scrum Artefacts

In the previous article we covered the different meetings we could have in a Scrum Project. In this article, we are going to look at the various artefacts that are maintained in any scrum project.  

Product Backlog

The product backlog is arguably the most important artefact for the scrum project team. The Product Owner maintains this backlog which contains the prioritized list of product features or functionality that need to implemented with higher priority items on the top. At the beginning of each iteration, the scrum team will pick up the top ranked items and work on them. Some important points about this product backlog include:

• It is a force ranked list of functionality with every item having its own priority
• No two items can have the same priority
• The list is visible for all stakeholders
• Any stakeholder including the scrum team, can add items to this list/backlog
• The product owner maintains the priority of the items in the backlog
• It is updated & refined regularly, preferably in each scrum sprint during the backlog refinement meeting

Product Backlog Item

As we just saw, the product backlog is a prioritized list of items and they are called Product Backlog Items. Each of these items could be individually built, tested and shipped. In most scrum projects, these items are often written as User Stories. Each story has its own detailed requirements as well clearly defined acceptance criteria. The stories are usually sized in such a way that a few members of the team can finish the story within a few days (at max within a single iteration). Some important points about these product backlog items include:

• It specifies the “What” aspect of the feature to be incorporated into the product
• It is usually in a User Story format
• Has specific and clear Acceptance Criteria
• Can be estimated & implemented by the team individually

In some cases, it may not be feasible for the team to build the user story in entirety during a single iteration. Such stories are called “Epic Stories” and are broken down into smaller more manageable sized child stories and each of these children are individually implemented by the scrum team.

Real Life Trivia: A Major point of contention between the scrum team and the product owner is often times the acceptance criteria for a user story. Experienced scrum masters will make sure that when a story is selected for development during a sprint, the story’s acceptance criteria is clearly and unambiguously defined. Some people also call this as the “Definition of Done” which the team needs to accomplish to say that the story development is completed. 

The Sprint Backlog

The spring backlog is nothing but the product backlog items that are shortlisted from the overall product backlog as the potential items for inclusion in the current sprint. This list is identified as part of the Sprint Planning meeting during the beginning of the Sprint. The Scrum team commits to a certain scope at the start of the sprint and focuses on getting them completed during the Sprint. These committed backlog items are usually categorized into 3 major groups – Tasks Not Started, Tasks In Progress and Tasks Completed. A sample backlog chart would look as below:

Some important points about the Sprint Backlog include:

• The backlog is decided based on the commitment by the scrum team and is often times negotiated to achieve certain business objectives as envisioned by the product owner
• The backlog does not change during the sprint execution
• If additional tasks are identified by the scrum team during sprint execution to meet the scope committed during the sprint, they will be added to the list
• The list is used as reference during the daily scrum/stand up meetings
• The list is transparent and visible to all team members

Some scrum teams use electronic tools to represent this sprint backlog while many scrum teams prefer the old school approach where team members put up sticky notes on a white board.

Real Life Trivia: In the “Ideal” scrum world, there is no such thing as a commitment from the team with regards to what will be delivered in a Sprint/Iteration. The team will make a best effort attempt at delivering the user stories identified as part of the sprint backlog and if they are unable to do so (for whatever reasons they may be) the unfinished go back to the backlog and may be prioritized again for continuation in the next Sprint. However, in “Real life” projects, we don’t have this luxury. As we are working toward a product goal (which invariably would have a client impact) the team is expected to keep their commitment for the Sprint and deliver the functionality that was planned during the iteration planning meeting.

Sprint Task

Once we have the committed backlog for a particular sprint, the team will start breaking down the backlog items into more granular tasks. The tasks will address the “How” part of achieving the “What” mentioned in the Product Backlog Item. Each of these tasks is typically 1 or 2 days’ worth of work and each PBI could have more than one team member working on their tasks collaboratively to achieve the PBI’s acceptance criteria. Some important points about the Sprint Tasks include:

• Each task would require a few days of work (Ideal recommendation is at max 1 or 2 days)
• The remaining effort is re-estimated daily for all tasks during the daily stand up
• Usually one member of the team will be primarily responsible for each of the tasks
• A single backlog item could require multiple sprint tasks like analysis, design, implementation, deployment, testing etc. They are all taken up during the same sprint by one or more members of the team collectively.

Sprint Burndown Chart

The Sprint Burndown Chart as the name suggests shows us the work progression by the team wherein we start off with the 100% pending work to be completed on Day 1 of the sprint and work our way towards 0% pending work on the last day of the sprint. Every day during the daily scrum/stand up meeting, the team will share updates regarding the completion of tasks and collectively the team works towards finishing all of the planned backlog items for a sprint by the end of the sprint. That is why it is called a “Burn Down” chart where we target to hit 0% pending work before the end of the sprint. A sample Burndown chart would look as follows: 

While the “X” axis is straight forward and has the dates for the iteration, you may be wondering what the numbers on the “Y” Axis of this chart represent. They represent the amount of work left.

Real Life Trivia: You might be wondering why does the burn down chart go up instead of down during the initial days of the sprint. That is because, when a sprint starts, during the first few days the team is still in discovery mode finding out more work items which would eventually need to be finished for the backlog item to be marked as “Completed”. Hence the small spike during the first few days and the gradual progression towards 0 as tasks gets completed one by one.

Some important points about Burn Down charts include:

• On a daily basis, this chart can show us the total work that still remains (in hours or days – depends on the teams preference) for a particular sprint
• The chart is updated daily and tasks are also re-estimated daily to ensure the chart is an accurate representation of the pending work
• It helps the team self-organize and focus on pending items

Real Life Trivia: In many organizations that have recently adopted scrum practices, the burn down chart becomes more of a management reporting tool rather than a tool to facilitate self-organization within the team. In such a case, this becomes more of an impediment to the team because people with authority over the team are constantly monitoring the progress and the teams efficiency could come down as a result of this constant supervision. In such cases, the Scrum Master should take the initiative to discontinue use of the burn down chart and allow the team to work without such distractions.

In some organizations, apart from the sprint burndown, they also track something called as a Release Burndown chart where they track the completion of product backlog items over the course of multiple sprints. As with any product, the product backlog grows constantly and it is very rare for this burn down chart to hit 0% pending stories because companies constantly enhance their products and it is more of a matter of priority where low priority enhancements will stay in the backlog and get replaced by higher priority enhancements.  Usually Scrum Teams will use the term called “Story Point” while estimating user stories as well as tracking completion. For a release level burn down the number on the Y axis could be Story Points left while for Sprints the Y axis could represent maybe Days or even a more granular measurement factor. People who are very fond of the Waterfall methodology (or are unable to forget it) may choose to have a burn down that represents pending work in Man Days even for Releases.

On a related note, In scrum projects the scrum master captures a metric called “Velocity” which signifies the number of story points of work completed by the team in each iteration. The average velocity of the previous iterations could be a decent yardstick for the management team to predict the potential number of sprints the team may need to finish the remaining items in the overall product backlog. Don’t worry, you will learn more about Velocity and Estimation very soon.