Hours vs Story Points – Demystifying Sizing

I’ve worked with many different Agile teams from different organizations. Story points are a common topic of confusion and frustration on teams, particularly new teams. I hear questions like, should we use points or hours? Should we use T-shirt sizes? Should we use Fibonacci? Should we estimate the tasks or the stories?

In this post I’m going to explain how we use story points in Scrum. It is important to note that Scrum does not require any particular sizing or estimating technique. I’m going to explain Story points because it’s one of the most adopted techniques in Agile. The method I’m going to explain is a best practice.

Story points are a number assigned to a story, or PBI (product backlog item), to give it a relative size compared to other items in the product backlog. Before I go any further, let me explain something about “Stories”. User stories are a technique from eXtreme programming which expresses the need from the user perspective. A PBI doesn’t have to be in a user story format. In fact, if the item is not related to a user, don’t waste your time putting into a user story format. Creating a story that says something like “As a BA I need to write requirements so…” is bad. Often we refer to all the PBIs as stories, even though they all may not be in a user story format.

Back to story points. The story points do not equal hours, days or weeks. When estimating story points, the team is trying to figure out how big a story is compared to other stories. The team, those who will actually do the work, estimates the points.

For simplicity, let’s go through a basic example. The Product Owner created a Story which says “As an Admin User, I need the ability to disable other user accounts”. The team then during a backlog planning/sizing session looks at the story and asks the Product Owner questions. After the questions are answered, it becomes clear that the work is small. The team agrees to assign the story with 2 points, using a rough order of size scale like Fibonacci (1, 2, 3, 5, 8, 13, 21). The team then moves on to estimate the next story. The next story reads “As an Admin user, I need the ability to perform batch updates in the system and run real-time reports”. The team has many questions for the product owner about this story. There a lot of unknowns and potential complexity. The team then decides that due to the complexities, the story is much bigger than the previous story. After some back and forth, the team agrees to assign the story with 8 points.

The basic example I provided is how story points are used in Scrum. The points give a relative size to stories in the product backlog. That’s it. It’s not complicated.

Things get a little more interesting with Sprints. Before Sprints start, teams conduct a Sprint Planning Session. This is when the team determines what stories (which are already sized with points) will be completed in the Sprint. For 2 week sprints, it’s advised the planning session should be 4 hours or less.

During the Sprint planning session, the team breaks down the stories into tasks. The tasks are estimated in hours, one day or less per task. Once the time for the tasks is estimated, the team has a good idea of the work they can commit to in the Sprint. They can compare the estimated time of the tasks against their capacity. If they know one team member is on vacation for example, using the task estimates they can better plan for the Sprint.

When the Sprint is in progress, the team updates how much time is left to complete the tasks at the end of each day. This provides the data needed for the Sprint Burn down chart. The Sprint burn down chart shows the time remaining to complete the tasks. The Sprint burn down doesn’t measure completed story points, it measures completed hours of the tasks. Below is an example of a Sprint burn down chart:

Now, up until this point I’ve referred to story points only for relative sizing, with no relation between time and points. Yet, once teams establish a stable velocity (average amount of points they complete in a Sprint), they can use points to forecast release planning and a product roadmap. Although release planning is not a core Scrum event, it is widely used. When teams plan for a release, which may be several sprints in the future, they track using a Release burn down chart. Unlike the Sprint burn down chart, the Release burn down measures the completed story points. The release burn down tracks how many story points remain to be completed to meet the release.

Below is an example of a Release burn down chart: