Cycle Time is one of the metrics that can be very helpful in improving works of Agile Team as well as it can be used in planning upcoming work to make it more efficient and predictable. Last but not least, it is easy to measure, which make it even more useful.
Cycle Time is the amount of time needed to complete some task. It might be the time needed to create a new feature or to resolve some production issue. It can measure the time from creating the idea until it is deployed onto production and available to users (it’s called Lead Time). It can be the time needed for the Development Team from start working on Product Backlog Item until it meets the criteria of Definition of Done – and I am going to focus on that case.
How to measure Cycle Time
Let’s start with how to measure Cycle Time. For this I am going to use some simple development flow, one which I like: TODO (item is waiting to be picked up), IN PROGRESS (development work is in progress a.k.a. working on it), IN REVIEW (once development is done, code changes need to be reviewed to ensure quality and compliance with some agreed rules), IN TEST (all related work is deployed into a test environment for the final quality assurance), DONE (work meets DoD).
Cycle Time for that flow will be the amount of time which passed from the first time PBI landed in IN PROGRESS status until it has been moved to DONE status – for the last time (and this is an important part).
For example, a new day started, and team start working on some PBI item at 8:00am (moved to IN PROGRESS). Then at 11:00am development part is done (including some initial testing on the local environment, moved to IN REVIEW). After half an hour (at 11:30am) it has been accepted and deployed to test environment (moved to IN TEST). The quality assurance is finished at 1:00pm (moved to DONE). At this point, Cycle Time for that PBI is 5 hours (from 8:00am until 1:00pm), but some from the team found out some new issue related to that item (at 2:30), reported a bug, so additional work needs to be done (moved to IN PROGRESS). At 6:00pm after doing other code review and one more testing PBI is finally closed (moved to DONE). The Cycle Time for that item is not 5 hours, but 10 hours.
We can compare that to measuring Cycle Time to get to work (and being able to work). I leave my house at 8:00am. I’m reaching my office at 8:30am but then I realize that I forgot my key-card (I’m not able to enter the office), so I need to get back to my house (9:00am), I need to look for my key-card and go back to the office. I’m there at 9:45am. Cycle Time is 1 hour 45 mins, not 30 min (I was not able to work after 30 min even if I’ve been there).
Improve Agile Team
Now, how this can help to improve Agile Team. First of all, we can observe the trends of Cycle Time – does it goes down with the time (usually means good things, work is going faster), or does it goes up (not so good signs) or is it stable. And that can be an objective way to validate or reject some experiments the team is running.
While compering some additional data, like Cycle Time for work IN PROGRESS, we can identify some bottlenecks in our process (I know “Individuals and interactions over processes and tools”, but still we use some processes in our day to day work). The graph below shows two data: Cycle Time (time needed to meet DoD) and Cycle Time In Progress (time needed for coding to be compleated) – for the simplicity, this chart presents the average values (average of Cycle Time done in given sprints) for each sprint.
Cycle Time can be useful also in adjusting estimation practices within the Team. How you ask? We can use data to see some discrepancy in our estimation pattern.
From that chart, we can see that our Stories estimated to 3 USP (blue dots) and 8 USP (green dots) take less time than it was in the past. But what is happening with one estimated to 5 USP (red dots)? In the past, it was something between 3- and 8-pointer, but now it seems like a random. Maybe, as a team, we should take a deeper look into that.
Important note: As it is better to make a decision based on some (even limited) data than a gut feeling, please keep in mind that we should take a look at the problem from different angles (use more than one metric in your decision process, more is better, too much is not good as well).
Predict the feature
You may say that why we need some Cycle Time in the planning when we have the team’s velocity. For one, I’ll say more information is better and in addition Cycle Time, historical information, is able to provide you with a probability of succeeding. But I will share more details in the next post.