Story points: Why not use time?

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

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.