Converting story points to hours - how does it work?

Estimates

Converting story points to hours - how does it work?

Thousands search online every month for answers to questions such as:

  1. How do you convert 3 points to hours?
  2. Table mapping story points to days?

Also, some teams are negotiating the ratio between story points and hours with stakeholders. This is a mistake, as we will soon see.

Story points are different from other measurement units people use. So it's not surprising many are looking for answers.

The questions we will answer in post

  1. So why can't we negotiate and decide on the ratio between hours and story points?
  2. So why isn't there a one-to-one mapping between story points and hours?
  3. How do we convert story points and velocity into duration?

The short answer is

the relationship between time and story points is measured and not negotiated. It is different for each team. It changes as teams improve their methods and vice versa.

Story points is similar to how weather forecasts work. The meteorologist uses his knowledge and observes data to forecast the weather. Similarly, a development teams use their knowledge and observes velocity of previous sprints to forecast expected effort of upcoming work.

So when someone comes by asking these questions, here is how you might answer. First, let's define story points and sprint velocity before explaining how these concepts relate to time.

Defining story points

Story points are units of measure for expressing an estimate of the overall effort required to implement a product backlog item. Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty.

'A relative estimate,' what does that mean?

When teams estimate a story, they compare the effort relative to other stories they have already estimated. Let's take an arbitrary fruit estimation scale to explain:

  • strawberry
  • apple
  • watermelon

Let's estimate the weight of a pear relative to the fruits on this scale. The team can quickly and easily determine the pear will fall into the same category as the apple. It's quick and easy because the differences between the weight of the items on the scale are clear.

This is exactly the reason why the story point scale uses the Fibonacci sequence or a close approximation: SmartGuess-Fibonaccy-Approximation.jpg

Defining team's sprint velocity

Team sprint velocity is the total number of story points a team completes within one sprint. For example, a team's velocity of 30 story points tells us they will complete stories that add up to approximately 30 story points fully manned during a regular sprint.

Coming back to the initial questions:

1. Why can't we negotiate and decide on the ratio between hours and story points?

The ratio is calculated based on a team's actual sprint velocity, i.e., completed stories from previous sprints. Hence every team will have a different velocity, and this is normal. Furthermore, the ratio is never fully fixed in stone. It will gradually improve or decline depending on various factors such as:

Factors negatively impacting team's velocity

  1. Team is attempting to deliver on an impossible deadline - cutting corners
  2. Level of codebase technical debt is high
  3. Automated testing is in a bad shape
  4. Team is lacking knowledge about parts of the codebase they're working with
  5. Team is lacking knowledge about the technology stack they are working with
  6. New team members will need support from existing team members to get quickly up-to-speed

Factors positively impacting team's velocity

  1. Team is working on a sustainable pace - constantly removing obstacles holding them back
  2. Technical debt is actively being reduced
  3. Automated testing is improving - problems are found and fixed early
  4. Team is gaining knowledge about parts of the codebase they are working with
  5. Team is gaining knowledge about the technology stack they are working with
  6. New team members get good help when starting and get quickly up-to-speed

2. Why isn't there a one-to-one mapping between story points and hours?

For the reasons mentioned above, there doesn't exist a mapping table mapping story points to hours. It depends on each team's context, experience, and current velocity.

3. How do we convert story points and velocity into duration?

Once information about a team's velocity and story estimates are in place for upcoming work, we can answer questions such as:

  1. When can you deliver feature A?
  2. What can you deliver before the end of next quarter?
  3. Can we get features A delivered before the end of next quarter?

Suppose the team's velocity is 30 story points every two-week sprint. Then in four weeks, they will complete approx. 60, in six weeks 90, and so on. If the team has five members and one member is away during a sprint, the velocity drops to approximately 4/5 * 30 = 24.

Now we can answer questions for when and for how long the work we are planning will likely take:

Question 1: When can you deliver feature A?

This is a fixed scope, variable time question. During development, the team's velocity will always vary a bit. The green and red lines show variability in how many story points are competed in each sprint.

So looking at the image, having a fixed scope question, when a certain number of story points are delivered, the answer is most likely in the following range:

  • x gives the best-case scenario
  • y gives the worst-case scenario

Question 2: What can you deliver before the end of next quarter?

This is a fixed time, variable scope question. Looking at the image, having a fixed time question, we can see that most likely, the team will

  • Complete all stories below x
  • Some of the stories between y and x
  • None of the stories above z

Question 3: Can we get feature A delivered before the end of next quarter?

This is a fixed time fixed scope question. Looking at the image, if x is not within the green and red lines, the team most likely will not be able to deliver feature A in time.

In this case, the discussion that needs to occur is how to proceed. There are only three real options:

  • Give the team more time
  • Cut scope
  • Or a combination of both

Watch Henrik Kniberg explain these concepts

Henrik Kniberg covers these concepts in his excellent video "Agile Product Ownership in a nutshell." The discussion on estimates starts at 11:28.

shape1shape2

About Smart Guess

We help teams educate stakeholders by providing actionable answers to common misconceptions about estimates. So more teams can use estimates to their advantage, and fewer are held accountable for delivering on impossible deadlines.

Like, retweet, or share your thoughts on Twitter about this topic.

Share your thoughts:

Recent Posts