large_Surpriced-face-26170509_m.jpg

medium_Surpriced-face-26170509_m.jpg

small_Surpriced-face-26170509_m.jpg

thumbnail_Surpriced-face-26170509_m.jpg

Surpriced-face-26170509_m.jpg

Agile Planning with relative estimates is tricky. One-to-one mapping between story points and time doesn't exist. Learn how converting story points to time duration is measured based on past performance. As with any performance, your team's performance can decline and improve, and you have an impact. Learn what factors negatively impact your team's performance and how to convert story points to a time duration. 



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.

SmartGuess-When-can-you-deliver-feature-A.png

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

SmartGuess-What-can-you-deliver-end-of-next-quarter.png

### 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

SmartGuess-Can-you-deliver-feature-A-before-end-of-next-quarter.png

## 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. 

HenrikKniberg-video-for-more-info.jpg

**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.


Converting story points to hours in Jira | How does it work?


https://marketplace.atlassian.com/apps/1225496/

Free app

nav-try-button

SG-full-color-black.svg

SG-full-color-blue.svg

SG-logo-black-07.svg

SG-logo-color-05-MarketPlace.svg

SG-logo-white-06.svg

SG-full-color-white.svg

Using existing tools

Not using existing tools

Are you?

Planning Poker

Async Planning Poker

Bucket Estimation

Backlog Forecasting

Solutions

Blog

Pricing

Creator

Story

About

Contact Support

Documentation

Security FAQ

Support

Forever Free. No setup. One Click—Planning Poker you run directly from the Jira backlog. Including
- **Fully featured Planning-** & Async -Poker
- **Fully configurable** Card decks
- **Role-based controls**, Team lead, Observer, etc.

Perfect for two teams - up to 31 story estimates/week.

Everything in Free included, plus:
- **Unlimited Estimates:** No limits, no boundaries.
- **Silent Estimation:** Estimate large backlogs fast.
- **Atlassian Fortified:** Enhanced security and reliability.
- **Free Demo and Trial:** Experience the Pro Plan before committing.


Smart Guess can be used from within the Jira Backlog

large_PlanningPoker-from-Backlog-E.png

medium_PlanningPoker-from-Backlog-E.png

small_PlanningPoker-from-Backlog-E.png

thumbnail_PlanningPoker-from-Backlog-E.png

PlanningPoker-from-Backlog-E.png

Silent Estimation by Smart Guess allows teams to estimate large number of stories faster

Blog: Converting story points to hours in Jira | How does it work?

Share your thoughts

Smart Guess Free

Smart Guess Pro