Get certified - Transform your world of work today

Close

Throughput: Forecasting the Delivery Rate

An alternative way to measure team success

9 November 2016

Abhijeet Verma
Softcell Technologies Ltd.


In general, we measure a team’s progress by its velocity. While velocity can help management forecast the team’s capability to deliver product backlog items (PBIs), such as stories and production issues for releases, one of the effective ways to forecast a team’s delivery rate can be in terms of its throughput.

Both throughput and velocity are ways of measuring how fast a team can complete work, or meet the Definition of Done (DoD). Knowing how fast a team is going allows the team and the stakeholders to know when something is going to be done. Since we already know what velocity is, I want to focus on the definition of throughput.
 

Definition of 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 board to help manage the delivery of stories. Throughput can be defined as the number of stories that can be completed (meet DoD criteria) in a timebox (sprint or month).
 

Ways of calculating throughput

The team pulls the highest-priority items off the backlog and works on them until they are done. They note when they started the stories and when they finished them. They do this over and over until the project ends. Every month, completed stories are summarized.
 
PBI (Story/Prod Issue) Started Completed Duration (days) Weekends (Days)/Nonworking days
A Jan 1 Jan 4 2 2
B Jan 5 Jan 12 6 2
C Jan 15 Jan 16 1 0
D Jan 17 Jan 25 7 2
E Jan 27 Feb 3  9 2
 
  • 1 day = 5 man hours
This team completed 4 stories in January, so their throughput is 4 stories per month. Each PBI takes on average 4 days (16 days/4 stories) to complete with a standard deviation of about 3 days. So each PBI is completed in 4 days +/- 3 days. With additional data, the standard deviation should tighten up unless you regularly have large variances in PBI size. Even though PBI E was started in January, we don’t count it because it was not completed in January. It will go into February’s stats.
 
PBI (Story/Prod Issue) Started Completed Duration (days)
A Sprint 1 Sprint 1 2
B Sprint 1 Sprint 1 2
C Sprint 1 Sprint 1 1
D Sprint 1 Sprint 1 3
E Sprint 1 Sprint 2 4
 
  • 1 day = 5 man hours
  • 1 sprint = 9 working days (removing 1 day which is mainly used in meetings)
The team completes 4 PBIs in Sprint 1; hence, the throughput of the sprint is 4. PBI E was taken up in Sprint 1 but was completed in Sprint 2; hence, it contributes the throughput of Sprint 2. Each PBI takes, on average, 2 days (8 days/4 stories) to complete, with the standard deviation of about 1 day. So we can expect the PBIs to be completed in 2 days +/- 1 day. We should consider only the working days and not weekends.

Since throughput relies on actual start and finish times, we can derive a predictive measure for forecasting without any estimating.

Like velocity, throughput is a team-specific number and cannot be compared across teams. It is important to note that throughput can be measured for a sprint as well and would follow the same standard process.

For my team, we practiced this and saw some wonderful results. We observed the following benefits:
  • Stories are broken to the granular level. This is a continuous-improvement practice and becomes better with time.
  • The team focuses on work completion (meeting DoD) for each picked item.
  • Focus is on the pull mechanism (start finishing) rather than a push mechanism (start developing).
  • Picking up just enough items for development means they can be tested and certified, hence reducing the QA bottleneck to some extent.
  • There is reduced fear of inflated story point estimation because the emphasis is on completed work items.
  • The development team can raise early builds for a majority of items because of small work items.
  • The story point burn-down chart shows decent progress from the second to third day onward.

 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.6 (5 ratings)

Comments

Swarna Jayaraman, CSM, 11/9/2016 6:20:32 AM
Thanks for sharing how to calculate throughput. Can you also help me to understand on when to calculate it? I assume throughput cannot be calculated on daily basis, unlike velocity.
Abhijeet Verma, CSP,CSM,CSPO, 11/15/2016 12:12:41 AM
Hi Swarna, as Throughput is a measure of progress for the team, it can be calculated for any time-box (daily/sprint length/monthly etc..). If you know how many PBIs the team is completing every day, you can present that number to them. A cumulative count would give you the Throughput value.
Shiv Jangid, CSM, 11/17/2016 6:01:42 AM
thanks for great article.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe