Throughput is relatively less known measure for traditional project management companies (based on PMBoK, Prince2, CMMI). However, I believe it will be gaining more respect in the near future with the spreading of the Lean concepts.
Throughput is the amount of work items delivered in a given period of time (e.g. week, month, quarter).
When we say delivered we really mean completed and possibly delivered to the customer. I.e. money is collected at the end of the process.
To understand the throughput concept, let us assume that during the last five weeks a team has delivered respectively 4, 6, 4, 2, and 3 stories per week. If there are started, but not finished stories, they do not take part of the calculations.
The average throughput for these five weeks is (4+6+4+2+3)/5 = 4 stories/week (rounded).The standard deviation is rounded to 1 story/week.
Throughput is based on real data of team’s capability to deliver. Throughput variability reflects the impact of factors such as story size, complexity, urgency, and person’s skills.
Throughput can be used for planning purposes. For instance continuing the above example, the team can estimate that their throughput (delivery rate) will be 4±1 stories per week without making any detailed estimation of the individual stories.
In Kanban, however, throughput is mainly used for tracking team’s performance. Logically, the objective is to continuously improve it.
Throughput is about the number of work items that the team is capable to deliver in a given time period, e.g. week, month, provided that they keep a uniform work load.
Throughput and velocity
Throughput is similar to the agile metric velocity, however it is used differently.
Velocity is measure used in eXtreme Programming and Scrum. It shows how much work a team can complete on an iteration or sprint. The work is usually measured in story points.
Going back to the previous example team, let us assume that the five user stories delivered during the last two weeks are of 3, 4, 1, 5, and 3 story points respectively.
Then the total number of story points that can be completed in a 2-weeks sprint is 3+4+1+5+3 = 16. That is the velocity of the team is 16 story points per sprint.
Velocity also varies because of factors like story complexity, story size, changes, team skills level, etc.
Agile teams use average velocity to estimate how many features they will be able to deliver in future sprints. However, they still have to estimate the individual user stories in order to define the backlog (the scope) of a sprint.
So, although velocity is associates with speed, in fact it is about the load, usually measured in story points, which a team can carry during a fixed period of time (iteration, sprint).
Throughput and resource estimation
Throughput can be used for estimating resources.
According to the Little’s Law
If a team keeps a steady pace of work, then the average delivery time (lead time) for a certain type of work or a class of service can be considered a constant.
The delivery rate (throughput) is the target rate to be achieved in order to meet customer deadline.
Based on this we calculate the number of work items to be processed for that duration.
E.g. suppose that lead time for a story is 0,25 week. The target delivery rate is 20 stories/week. Then
WIP = 20*0,25 = 5 stories.
Assuming that a person can only work on a single story, we need at least 5 people for implementing the complete job on time. To be on the safe side (no precise formulae for this), we would better start with a team of 6 people. :-)
Little’s Law and Throughput allow estimating the
time and resources needed to carry out a job.
To sum up, throughput is easy to collect. It is a valuable measure because it keeps you focussed on team’s performance. In addition, knowing team’s throughput decreases the effort for estimating stories (requirements), provided that they are split to reasonably small chunks. Moreover, through Little’s Law, the throughput allows estimating the resources needed for completing a given job within the time expected by the client.
