Cycle Time

In my last post, I shared Non-value-adding actions. Now that you know how to how to identify them.  On the other hand, one of the primary measure factor developers in Scrum should care about is the delivered value to PO. One of the most straightforward Scrum tools for measuring the provided value is Cycle time. The point that must consider here is that only the developers will decide if cycle time should be integrated into their process. One of the best benefits of cycle time is checking the team’s performance and identifying the workflow issues.

In a simple word, cycle time is when you start working on a task when the job is done. It has nothing to say what occurs from the beginning to the end of the process. The Scrum calculation for cycle time is simple:

Cycle time = End time – Start time

Using Cycle time in an actual environment

Imagine you as a Scrum Master realized that your team’s Cycle Time is high and want to reduce it. How do you reduce cycle time for your team?

Based on my experience, the following can be the root cause of the high Cycle time:

1- Backlog items were not clear.

2- Stories were not appropriately split.

3- In reality, some devs slower than others.

For the first two sorts of issues, you need to collaborate with the PO and do an extra study before adding stories to the backlog. Also, you can get help from the development team if necessary.

For the third case, if the issue is related to seniority and knowledge of business & product, you go for pair programming, upskilling and training.

Take a minute to follow me on Twitter if you enjoyed this post and want to see more.