Why Use Story Points and Velocity Instead of Hours of Effort and Numbers of People

April 14, 2013 — Posted by Al Shalloway

The Challenge of Conflating Size of Work and Time of Work

In my Lean-Agile classes, I often ask people how far away something is.  For example, if I’m in Seattle I’ll ask them how far away Portland is. I usually get an answer like “about 3 hours.”  I respond by asking “I can walk there in 3 hours?” “3 hours to drive.”  “What if I have a private helicopter?” 

We might think this is just some people being sloppy but if you google “distance between Portland and Seattle” and you’ll get 2 hours and 43 minutes in a big, bold, highlighted answer with a small “173.9 miles” that’s barely noticeable.  The fact is, we conflate distance and time. 

In software we do the same thing.  We conflate the size of the work to do (distance) with the time it takes to get it done.  As in the earlier case, these are two different things.  The size of the work is not the same as the time it will take to do the work in the same way the distance between two cities is not the same as the time it will take to get from one to the other.  Different people or teams working on the same story may result in two different times to achieve the result.   It will also be difficult to tell the different relative speeds of the teams because a team working on a bigger project may appear to be slower than a team working on a smaller project, even when they are more capable.  Our estimates will also be off because we typically estimate based on who is best capable of doing the work while they are not always the one who will do the work.  This is like estimating based on us all having the ideal vehicle to use in getting from one place to another – no wonder our estimates are off.

What We Really Want to Do

But that’s not the real issue.  The real issue is that we have two issues here:

  1. How fast our teams can build software
  2. How much time the work in our backlog will take

Doing this might not be so bad if our rate of work was constant – but it isn’t.  Interruptions and waiting for key folks often slow us down by a factor of 3-5 times.  This may seem like a surprisingly large number but can be validated when one considers what happens when delays occur between coding and testing.  What might take a few minutes to fix when testing occurs right after coding might take a few hours (or even days) when the testing takes place weeks later.  There are many other examples

The bottom line is that we want to measure the size of our work and the speed of our teams. This will enable us to do many things which conflating these issues will not provide.  Unfortunately, there is no good, consistent measurement for size of work.  One attempt at this was “function points.”  But these are not exactly what we want.  Function points may not necessarily be well correlated with the size of the work. 

What works well is some measure of the overall complexity of the work.  This will, of course, include the aspects of number of function points, size, inter-connectedness, etc.  We call these “story points.”  A story point is an arbitrary unit of measure of the size of the work.  This has often been called the amount of effort to achieve the result, but effort is not quite the right concept.  To accomplish this we must understand what completing the story means.  That is, we must agree on a definition of done.  I suggest that definition include full testing on the story – so you truly know it is completed.  Hence, the complexity of the story will include both what it takes to build it and what it takes to validate it’s been built properly.

One may wonder how an arbitrary unit of measure can be useful but the arbitrariness is not a problem.  If story points is our measure of the size of the work we can measure our velocity (how fast we get work done) by the number of story points implemented in a sprint.  For example, if we have 120 story points to do and we do 40 story points a sprint, we know it will take us 3 sprints to do the job.

In using story points, we separate these two issues – size of work and velocity of teams.  We’ll see how this can be useful, but first a few words on estimation.  It turns out that what one story point means is not really that significant.  But, to get it on a reasonable scale, we’ll say a story point is about a days worth of work. While doing this seems to contradict some of what we said, it doesn’t because estimating what a day is is not that hard – since a day of uninterrupted work is achievable.   However, once we start using story points, we’ll stop remembering where the initial value came from.  When moving forward, we’ll decide the number of story points something is by comparing it to something that has already been sized.  This is called relative estimation.

The Value of Keeping Story Points and Team Velocity Separate

The value of keeping story points and team velocity measures separate is that both will be more accurate than if they were combined.  By having velocity at the team level we will be able to better plan our work.  This is particularly important when we have to coordinate teams.  If work must be split across teams we’ll be able to accurately predict total throughput by understanding the amount of work to be done and the rate at which this work can be accomplished.

While team velocities may be different, the sizes of the work to be done can be agreed to across the organization.  This is analogous to the distance between Seattle and Portland being 174 miles regardless of whether you are walking, driving, flying or biking (and yes, I know the distances will change some, but not tremendously).

By having separate measures we can get better stability of estimating our work and seeing the velocity of our teams.

Hope you found this useful.

As always, please contact me if I can be of any assistance.

Al Shalloway

CEO, Net Objectives


Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


How do you assign points to stories objectively so that they remain valid even if the
estimators turn out not to be the ones who do the work?

Sometimes it seems to make sense to tweak the make-up of teams in order to fit the shape of upcoming work. However, doing so seems to invalidate records of team velocity and therefore make it difficult to forecast durations. Any advice?

#1: stories should only be estimated by those doing the work.

#2: Tweaking teams can make sense at times, but not if it damages the synergy of the teams working together.  If you do tweak the teams, expect the velocity of the tweaked team to go down.  There are two forces here - teams being better suited for the work, teams losing some of their synergy.  Our approach is to bring the work to the teams, not the teams to the work (at least in most cases).   Core teams are best - you probably lose more by trying adjustments.  Key folks may have to be assigned to teams for short periods to create cross-functionality.

Hi Al

We experience scenarios where the team has a capacity of say 15 story points. We commit to 3 stories each with an estimate of 5 points. We complete story A & B 100%, but story C isn't quite there in terms of definition of done - we done about 80% of the tasks but not done done. What is our velocity here? 10 story points (and we ignore the fact that we got 80% of story C done), 15 story points (because the story C may have been a little bigger than our original estimate)? 14 story points (assuming we somehow work out that we think we completed 80% of the story and it was still a 5 pointer)?


How many people do you have on the team and how long are your sprints?

I like to see a 1 story point story take about a day to build and test.

I suspect the situation you have is an issue because your stories are too big.  Stories shouldn't take more than 3 business days to complete if folks are not interrupted.  Smaller stories are generally better and make the problem you are talking about less important.  The point is, story points are only supposed to be credited when you have working code.  80% done is likely not accurate.  Lots of devs can get almost done very fast, yet take a long time to get all of the way done.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban