Skip to main content

Have read about hundreds of resources but I need help understanding cycle time

Last post 07:00 pm July 27, 2022 by Chuck Suscheck
4 replies
11:20 am July 26, 2022

Hello Community,

I know there have been questions asked in the past about cycle times. I generally understand the concept of cycle time. It's is basically the difference between when a work starts and when it gets completed. My question is more about the rolling average and standard deviation. 

I am currently using Azure DevOps to track my cycle time. It says that moving average is the average of data points that fall within the moving average window. It's basically calculated with the "current day" and the 20% of previous N days based on total days that is considered on the x-axis.

I would like to know if there is an easier way to interpret the moving averages. Also, what is the standard deviation? I am trying to understand exactly how is standard deviation telling me and how to calculate it 

Finally, how do we know an ideal amount of cycle time on a three week sprint? My teams cycle times are 7 and 9 days. In my eyes that is a good cycle time. Are we supposed to track it over time to see if it increases? Also, how do we know that the standard deviation is more predictable? Thank you!

 

 

 

 

 

 


08:45 pm July 26, 2022

Finally, how do we know an ideal amount of cycle time on a three week sprint? My teams cycle times are 7 and 9 days. In my eyes that is a good cycle time. Are we supposed to track it over time to see if it increases?

Good or bad? It's a starting point. What would be better is to look at the trends over time. Your team should want cycle time to shorten over time.

How do they shorten cycle time? Some ideas: Reduce work in progress (WIP), remove blockers, improve workflow, and perhaps even break work (PBIs) down into smaller pieces of value if possible.

I am a bit fuzzy on the standard deviation piece. Typically when looking at a scatter plot you want to look at probabilities to get your Service Level Expectation (SLE), perhaps somewhere around 85%?

Yuval might be able to help us: https://www.scrum.org/resources/blog/kanban-service-level-expectations-and-how-use-them-scrum


12:19 am July 27, 2022

Can you give an example of a Sprint Goal your team has recently had, and how cycle time, rolling average and standard deviation were used to help achieve it?


12:53 pm July 27, 2022

Cycle time is a lagging indicator that can help bring transparency around how long it took to develop individual PBIs and how long it takes on average. 

Similar to what Chris shared, we leverage a cycle time scatter plot with defined percentiles vs. calculating standard deviation.

You could use this information to help establish SLEs as Chris mentions, or to see if you are, on average, able to complete development of PBIs within a number of days. If your Sprint cycles are 3 weeks, you could inspect to see if 85% of PBIs are completed in 21 days or less. If 85% take longer than 21 days, there is a good chance there is a pattern of not finishing PBIs within the Sprint. Inspect to find out why. You may also see some cycle time scatter plots with a broader series of percentiles like 50%, 60%, 70%, 80%, 90% or with a spread (50%, 70%, 90%).

All that said, Ian's question is a powerful one and I can't provide an example of how it has directly helped achieve a Sprint Goal. It may offer inspectable data you can review and retrospect on when you are not able to achieve a Sprint Goal due to PBIs not reaching Done within a Sprint.


07:00 pm July 27, 2022

Standard deviation works for normal distributions - bell shaped.  It roughly indicates how wide that distribution is.  Wider distribution means more variation in the data.  

For cycle time and much of the per item work, you probably don't have a bell shaped curve for the cycle time or throughput.  Using a Monte Carlo simulation is better for applying forecasts to a non normal (abnormal?) distribution becase it takes your data, creates percentiles and then runs simulations against the "formula" derived from your data.

Your tool seems to be giving you a lot of data but not much information - like counting the grains of sand in a bucket!

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.