Scrum Cycle Time
- Natallia_Mendzel@epam.com
- Anastasia Baranouskaya
- Katsiaryna_Subach
Purpose
Scrum Cycle Time shows how much time, on average, an issue of a specific type spends in a delivery pipeline. Measured in days as a duration of appropriate sprints. Main purpose: knowing how big this timing is, it gives a chance to continuously monitor it towards improvement (acceleration).
How metric helps
Scrum Cycle Time helps understand how fast a business need is transformed to a value delivered to a client. It can be, to some extent, an idea of the "Time to Market" measure. Knowing such thing, one has more flexibility in estimations and planning. Usually, the shorter this measure, the faster things go to market (i.e. to production).
Questions it answers
how much time, on average, an issue of a specific type spends in a delivery pipeline
how fast a business need is transformed to a value delivered to a client
how throughput can be evaluated
how stable team's flow is
how predictable delivery is
How metric works
Chart overview
Chart shows Scrum Cycle Time - Axis Y by sprint - Axis X. Scrum Cycle Time is measured in days. On hover over a column a hint appears that reveals:
Average Scrum Cycle Time - metric value visualized in the chart;
Maximum time spent in a delivery pipeline for issues completed in this sprint;
Minimum time spent in a delivery pipeline for issues completed in this sprint;
Number of completed issues in this sprint.
By click on a column a pop up appears with information about the issues included into the calculation:
Issue ID
Type
Priority
Summary
TOP-5 problems metric identifies
Calculation
Schematically, here is the idea how this metric is calculated:
SCTsprint =∑SCTsprint_i /N,
where
SCTsprint_i = "End" timestamp of a sprint in which an item was accomplished (e.g. story done) - "Start" timestamp of an active sprint an item was planned for the first time
N - a number of issues get into a Done status within a selected sprint excluding invalid bugs.
Example
Sprint 1 dates: Jan 2 - Jan 15
Sprint 2 dates: Jan 16 - Jan 30
Sprint 3 dates: Jan 31 - Feb 13
Sprint 4 dates: Feb 14 - Feb 28
Sprint 5 dates: Mar 1 - Mar 15
Story1 was created on Jan,1 and planned for Sprint1. The team started working on it on Jan, 5 and then on Jan, 10 it was decided to suspend development and remove it from the scope. Then on Feb,3 it was decided to work on in in Sprint4. It was started in Sprint 4 and finished on Feb, 20.
Story2 and Story3 were created on Feb,13, taken into Sprint4 iteration . Story 2 completed on Feb,25. Story 3 was completed on March,2.
Cycle Time for Story1 is Feb,28 - Jan,2 = 58 days, as Sprint4End - Sprint1Start
Cycle Time for Story2 is Feb,28 - Feb,14= 14 days as Sprint4End - Sprint4Start
Cycle Time for Story3 is Mar,15 - Feb,14 = 29 days as Sprint5End - Sprint4Start
Cycle Time for Sprint 4 = (58+14)/2 = 36 days
Cycle Time for Sprint 5 = 29/1=29 days
Unusual cases:
1 Issue completion date is earlier than a sprint start it is assigned to: issue SCTsprint is calculated by a sprint lifetime issue completion date is covered by.
2 Issue completion date is later than a sprint finish it is assigned to: issue SCTsprint is calculated by a sprint lifetime issue completion date is covered by.
3 Project has 2 active sprints in the same time and one of the sprints is started later and finished early then other. Issue is assigned to this short sprint and completion date in frame of it: issue SCTsprint is calculated by a sprint with later end date. Assigned sprint is not affected
Data Source
Data for the metric can be collected from a task tracking system (Jira, TFS, Rally etc.).