Throughput and velocity are ways of measuring how fast a
team can do work. Knowing how fast a team is going allows the team and their
stakeholders to know when something is going to be done.
What is Velocity
Velocity (http://www.extremeprogramming.org/rules/velocity.html)
is a commonly used metric for teams using Extreme Programming or Scrum as their
guiding principles for software development. Velocity is a unit-less measure
that tells the team how much work they should take on each iteration or sprint.
A simple example of calculating velocity:
At the first sprint planning meeting the team estimates the
top 10 stories and believes that they can complete 6 of them in the next 2
weeks based on the following estimates.
|
Story
|
Points
|
|
A
|
3
|
|
B
|
5
|
|
C
|
1
|
|
D
|
5
|
|
E
|
2
|
|
F
|
1
|
|
Total
|
17
|
At the end of 2 weeks stories A-E are complete and F is
started, but not complete. This teams velocity is 16 point per iteration, or
about 32 points per month. Note there is no credit for partially done work. The
next iteration the team estimates stories until they have stories that add up
to 16 points. At the end of the iteration they measure what was actually
completed and repeat until the project is done.
Velocities cannot be compared across teams because velocity
is derived from estimates created by the team and since no team estimates the
same way it is impossible to compare them.
Velocity is also not a productivity metric. Wanting to see the
velocity have a constant increase is like asking to increase the speed of
light. Velocities do vary over time due to various factors (like the fact that
software is complex), but tend to stabilize if the work and personnel are not
fluctuating too much.
What is Throughput
Throughput is not commonly used in software development, but
is becoming more prevalent with the introduction of lean concepts. Throughput
is most common when using a kanban scheduling board (http://blogs.consultantsguild.com/index.php/wayne/2008/02/01/no-more-iterations)
to help manage the delivery of stories.
Throughput is the number of things that can be done in a
given period of time.
A simple example of calculating throughput:
The team pulls the highest priority item off the backlog and
works on it until they are done. They note when they started the story and when
they finished it. They do this over and over until the project is over. Every
month someone summarized the information about the stories that were completed.
|
Story
|
Started
|
Competed
|
Duration
|
|
A
|
Jan 1
|
Jan 4
|
3
|
|
B
|
Jan 4
|
Jan 12
|
8
|
|
C
|
Jan 12
|
Jan 13
|
1
|
|
D
|
Jan 13
|
Jan 25
|
12
|
|
E
|
Jan 25
|
Feb 3
|
9
|
This team completed 4 stories in January so their throughput
is 4 stories per month. Each story takes on average 6 days to complete with a
standard deviation of about 5 days. So 90% of stories are completed in 6 days
+/- 5 days. With additional data the standard deviation should tighten up
unless you have large variance in story size on a regular basis. Even though story E was started in January we don't count it because it was not completed in January. It will go into February's stats.
Since throughput relies on actual start and finish times we
can derive a predictive measure for forecasting without any estimating.
Note that duration ignores the fact that some days are
weekends.
Like velocity throughput is a team specific number and
cannot be compared across teams.
Challenges with Velocity
Velocity is based on an abstract unit such as Story Points
(http://en.wikipedia.org/wiki/Story_points)
that are not always easy to explain to stakeholders (or even the team
sometimes). Stakeholders often want to know how many days a story point
represents. Since story points are relative to each other there isn't a direct
mapping, although many team do grudgingly come up with an equivalence. To get
around this some teams estimate in ideal or engineering hours. Unfortunately
the same questions get asked. "How do I convert your funny agile units into
days?" See also http://www.think-box.co.uk/blog/2006/02/ideal-time-vs-story-points.html
Velocity also requires the team to spend time estimating the
stories. I'm not sure I ever met a developer who enjoyed estimating and even
with planning poker (http://en.wikipedia.org/wiki/Planning_poker)
most team member do what they can to get out of the estimating meeting yielding
less than useful results. One team I know of estimated everything as "?" once
they got tired.
As in all estimation the results are only as good as the
information at hand. When you are estimating something you've never done before
the accuracy can be all over the place.
Challenges with Throughput
The big knock against throughput is that it requires you to
have relatively similar size stories in your backlog. This is true to a point.
If your stories are not of a similar size your standard deviation will be
larger leading to a larger range in your completion date predictions.
Which to Use?
In my context (stable teams working on product lines) I
prefer the kanban/throughput combination. We don't have the dreaded planning
meeting and we are still able to tell our stakeholders how many stories they
should plan on having in the next release.
If you are currently using velocity it is very little
overhead to start tracking throughput as a way to double check what your
velocity metric is telling you.