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
Unexpected blockers or dependencies during Sprint execution
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.
Data Source
Data for the metric can be collected from a task tracking system (Jira, TFS, Rally etc.).
Copyright © 2024 EPAM Systems, Inc. |
|---|
All Rights Reserved. All information contained herein is, and remains the property of EPAM Systems, Inc. and/or its suppliers and is protected by international intellectual property law. Dissemination of this information or reproduction of this material is strictly forbidden, unless prior written permission is obtained from EPAM Systems, Inc. |