nav-try-button

large_Studlagil-Iceland-127038898_m.jpg

medium_Studlagil-Iceland-127038898_m.jpg

small_Studlagil-Iceland-127038898_m.jpg

thumbnail_Studlagil-Iceland-127038898_m.jpg

Studlagil-Iceland-127038898_m.jpg

Discover why story points are a better alternative to estimating time in agile development. This post explains the benefits of using story points for more accurate planning and forecasting. Learn more about this popular estimation technique today!"


### Critical problems with time estimates
#### Problem: It depends on who does the work, how long it will take 
You will find experienced team members and less experienced members in any team. It will take less time for a team member to implement changes on a well-known codebase. Similarly, it will take more time to implement changes that depend on an unfamiliar API. Each team member has a different level of knowledge and experience. So when team members discuss time estimates, they struggle to agree on an estimate when each member is thinking 
> 'how long will it take 'me' to implement this story?'

We need a way to move away from this line of thinking because team members' knowledge and experience are different.

#### Problem: Uncertainty not actively tracked
When team members discuss a story and how they will get it done, they base their estimate on what they know. Some overlook what they can't see and give a best-case estimate. Some will assess uncertainty and include additional time to account for it. The big challenge is deciding how much time to account for the uncertainty. Because you only know how long it takes when the work is complete. So while uncertainty isn't being assessed, measured, and used to forecast progress, your team will struggle with estimates.

There is a solution to these problems. The answer is to use story points, relative estimates, and the team's velocity. Let's discuss how it works. 



### How do story points, relative estimates, and team's velocity solve these problems? 

#### Solving: It depends on who does the work, how long it will take 

Relative estimates solve the first problem. Instead of asking: 'how long will this story take me?' Compare each story you estimate and ask, is this story the same size as other stories that are:
- one-story point?
- two-story points?
- three-story points?

..and so on. Research shows we are better at estimating effort using relative estimates. And by using the Fibonacci sequence as the scale, rather than continuous scale such as time, the difference between each item makes it relatively easy to find a place for each story. Then end of each sprint, track the total number of story points the team completed. That's the team's velocity. The team's velocity will be approximately the same from one sprint to another, given team members are using a similar time each sprint and story uncertainity is similar to previous sprints. Each sprint has a fixed timeframe allowing teams to [convert story points to delivery time](https://smartguess.is/blog/story-points-to-time/) as needed. 

#### Solving: Uncertainty not actively tracked
We solve the second problem by *assessing*,  *measuring*, and *forecasting* progress based on actual data. We *assess* uncertainty when assigning story points. For example, when two stories are of a similar size, while one involves an API the team is unfamiliar with, it will get a higher story point estimate. Secondly, by *measuring* the team's velocity every sprint, we collect data on backlog items completed involving risk and uncertainty. By collecting data on the team's velocity, we measure story progress and the actual time uncertainty has taken. Third, we *forecast* progress using the average velocity of past sprints, allowing us to answer questions such as [covered here](https://smartguess.is/blog/story-points-to-time/):

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?

The forecast will work while past velocity is a good indicator of future velocity.  Naturally, this will break down if part of the team frequently moves to other urgent work such as production issues, which is a topic for another post.

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


Story points: Why not use time?

Björn Brynjar Jónsson

large_Bjorn-Brynjar-Jonsson.jpg

medium_Bjorn-Brynjar-Jonsson.jpg

small_Bjorn-Brynjar-Jonsson.jpg

thumbnail_Bjorn-Brynjar-Jonsson.jpg

Bjorn-Brynjar-Jonsson.jpg

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

Silent Estimation

Planning Poker

Solutions

Blog

Pricing

Contact Support

Documentation

Security FAQ

Support

No setup, One Click - Planning Poker you run directly from the Jira backlog. "It's the best app ❤️ we've used. **Learn more**

With Bucket Estimation, intuitive drag & drop, you got all your estimation needs  covered  🚀  **Learn more**

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

Story points: Why not use time?

Recent Posts

Share your thoughts

Planning Poker

Bucket Estimation

Share your thoughts: