Converting story points to hours - how does it work?

Estimates
  • 2022-03-16

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 negotiate 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. Why can't we negotiate and decide on the ratio between hours and story points?
  2. Why isn't 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 are similar to how weather forecasts work. The meteorologist uses his knowledge and observes data to forecast the weather. Similarly, development teams use their knowledge and observe the the velocity of previous sprints to forecast the the expected effort of upcoming work.

So when someone asks these questions, here is how you might answer. First, 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. Any team comparing the pear and other items on the scale can quickly see the pear falls 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 apparent.

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

So relative estimation means you are always comparing the item you want to estimate, the🍐in this case, with other items and asking if it is the same size as 🍓, 🍏 or 🍉?

Defining the 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.

Continuing with the fruit estimation scale example, the sprint velocity is all the fruits the team can complete within one sprint. Let's assign numbers (from the Fibonacci scale) to each fruit so we can add up the velocity:

  • 🍓strawberry - 3 fruit points
  • 🍏 apple - 5 fruit points
  • 🍉 watermelon - 8 fruit points

Based on this, if the team averages 30 fruit points, it can be expected each sprint, the team will complete:

  • 3x 🍉 = 24
  • 2x🍓 = 6
  • = 30 points

Or

  • 2x 🍉 = 16
  • 2x 🍏 = 10
  • 1x 🍓 = 3
  • = 29 points

Or any combination that adds up to approximately 30 points.

Expert tip Notice it's important to use estimation scales that support adding values together so that you are able to track your team's average velocity easily. This is why I don't recommend using T-shirt- , dog- or fruit- scales, because each sprint there is extra work in adding up the velcoity.

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 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 the 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 lacks knowledge about parts of the codebase they're working with
  5. Team lacks knowledge about the technology stack they are working with
  6. New team members don't get enough support from existing team members to get quickly up-to-speed

Factors positively impacting the 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 feature 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 about 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 completed 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 will most likely be unable 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.

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.

Recent Posts

Share your thoughts

Share your thoughts: