Why Is Estimation (i.e. — Story Pointing) and Tracking Velocity Important?
By: Goodspeed
Tags: Software, Scrum, Software Development, Agile, Development

Q: Why is estimation (i.e. — story pointing) and tracking velocity important?

Estimation is a forward-looking prediction of the effort required to complete an increment of work, most commonly (but not always!) measured in story points. This is typically done at the individual user story level, but can also be applied to larger work items such as features and epics when planning large-scale, multi-team releases.

Velocity is a measure of the amount of work a team has completed in the past — sometimes referred to as the work shipped within a single sprint (“our velocity last sprint was 25 story points”) or as an average across multiple sprints when in the context of referencing a team’s capacity to complete work (“our team’s velocity is 25 story points per sprint”).

The purpose of tracking a team’s velocity is two-fold:

Predict Future Performance: Teams most commonly average their velocity over a couple of recently completed sprints as a general indication of the amount of work they could do in future sprints. During Sprint Planning, this average is used to determine how much work the team can commit to completing within the sprint — they simply pull in work until the sum of story points in the sprint backlog is equal to or just below the team’s averaged velocity. For longer-term planning, the team’s averaged velocity is used to estimate when a large body of work could be completed by first estimating the backlog size (in story points), then deriving a duration (“with a team velocity of 25 story points per sprint, our backlog of 250 story points is likely to be released in 10 sprints”).

Image by Author

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” — 8th Agile Principle

Promote Continuous Improvement: By tracking a team’s velocity over time and plotting it on a velocity trend chart, teams can monitor the consistency of their velocity sprint-over-sprint to identify opportunities for improving the way they work in an effort to become more predictable by first stabilizing, then increasing velocity over time.

At the end of the day it’s up to your team to decide how important these benefits are to you. To help with this, ask yourself these questions:

Do I need to improve the speed in which my team is able to get to done?

Does the amount of work my team is able to complete sprint-over-sprint need to become more predictable?

Am I constantly being asked to provide release date estimates?

Do we struggle to provide said release date estimates with a reasonable level of accuracy?

Does the work my team performs require a high level of cross-team coordination with others?

If the answer to any of the above questions is yes, then tracking the team’s velocity is probably a good idea. If you decide to do so, consider the following:

Never Compare Velocity Between Teams: Each team is unique — their size, developer experience levels, estimation methods, product and technology they work on, etc. are so different that any comparison of velocity across team’s is futile. Story points are a completely arbitrary, unitless measurement that only make sense within the context of the team performing the estimation. Instead, analyze trends of a specific team’s velocity to gauge the overall health of the team and identify opportunities for improvement.

Improvement Doesn’t Always Mean Increasing Velocity: Remember, velocity is primarily used to predict a team’s future output, either to plan the next sprint or provide accurate release dates, and is typically calculated as an average of the story points completed in prior sprints. The team’s actual output is likely to be different from the average, either lower or higher, depending on the complexity of work being done, unforeseen roadblocks, and other miscellaneous factors that inevitably arise throughout a sprint. Using averages to predict team output hides the volatility of sprint-over-sprint performance. Teams should first focus on achieving a stable velocity with the goal of becoming more predictable; then, emphasize increasing their velocity while continuously promoting and maintaining a sustainable pace of development.

Photo by Scott Adams from Dilbert Cartoons (Source)

“It’s better to be roughly right than precisely wrong.” — John Maynard Keynes

Don’t Fall into the Precision Trap — When estimating release dates for large bodies of work using your team’s average velocity, avoid estimates that imply a greater level of precision than is realistically possible. Estimates need to be accurate, but should only be as precise as the data available at the time. In general, the farther out a project’s end date is, the less precision is possible in predicting the end date. Try using the following guide that proposes a reasonable resolution to use for release estimates based on how far out the estimated release date is:

6+ Months Away: Quarter of Release

of Release 3-to-6 Months Away: Month of Release

of Release 1-to-3 Month Aways: Sprint of Release ± 1 Sprint

of Release ± 1 Sprint <1 Month Away: Day of Release ± A Couple Days

There are certainly more advanced methods of estimation using historical sprint data to calculate confidence intervals and provide date ranges rather than a single-point estimate to demonstrate work that probably will be completed vs. likely to be completed vs. probably won’t be completed — I’ll cover these in future stories, so stay tuned!

In a nutshell, velocity is a great tool teams can use to continuously improve their processes by first stabilizing, then increasing the amount of work they complete each sprint in the name of providing reasonably accurate estimates that are necessary for strategic business planning.