PERSPECTIVES
Continuous Improvement
How Cycle time can help you
deliver faster
Contents
Introduction
3
Cycle time 101
4
Cycle time in practice
5
Cycle time and Little's Law --
Paulo Caroli
6
Cycle time for Continuous Improvement --
Kevin Kriner
8
Whittling our wall to reduce cycle time --
Melissa Doerken
11
Trailing indicators good. Leading indicators better --
Scott Turnquest
13
In Summary
16
About the authors
17
Great teams are constantly striving to improve the way they work in
order to innovate and deliver faster. When teams reflect on their
process today, their conversations are largely qualitative and rely
heavily on intuition. While intuition is good, having meaningful,
actionable data can help teams make better decisions about what and
how they can improve than they would by intuition alone.
Cycle time is one of the most important and helpful metrics for teams
who are striving to continuously improve. While cycle time has been
used in traditional manufacturing industries for decades, software
teams are now starting to use it to identify ways to improve their
process and deliver faster. In this ebook, we will discuss what cycle
time is and how it can help your team improve faster.
Ethan Teng,
Product Manager, ThoughtWorks
Cycle time
101
What is Cycle time?
Cycle time is a simple but powerful metric. It is the measure of the elapsed time from the moment you start working on an item (story, task, bug, feature, etc.) until it is done.
Different teams will use different definitions for “start” and “done”. Teams often mark “start” as the time when the team starts working on an item including analysis and “done” when it is signed off by the
stakeholder, or pushed to production.
How does Cycle time help?
When looked at in aggregate and across time, cycle time reveals how smoothly work is flowing through your development process, helps you spot bottlenecks and see the effects they have on your delivery. It provides the insight you need to make improvements and deliver faster.
Cycle time
in practice
Little’s Law
“The average number of work items in a stable system
is equal to their average completion rate, multiplied by their average time in the system.” - John Little, 1961
By solving this simple first equation you are able to find out the average time for work items in your system. My whiskey bar provides us a great stable system example to illustrate how you can apply Little’s law to track the average cycle time.
My whiskey bar
As is apparent, I only drink whiskey (the left side of the bar is my wife’s). Whenever a bottle finishes, I remove it from the bar. Then I open a new one, and add it to the bar. My bar is a stable system: the rate at which whiskey bottles enter the bar is the rate at which they exit. Only 12 bottles can fit.
The number of whiskey bottles at my bar is
constant: 12 bottles. Per year, I finish an average of 6 whiskey bottles. So, what is the average time for a whiskey bottle in my bar?
Let’s apply Little’s Law
Average number of work items in a stable system
=
Average completion rate X Average time in the systemUsing my bar terms:
12 bottles (number of whiskey bottles in my bar)
=
6 bottles / year (average completion rate) X Average time in my bar (cycle time)Therefore, the average time a whiskey bottle stays in my bar is 2 years.
Give it a try! Go ahead and apply Little’s Law formula to your stable system. Given the average work items in the system (WIP) and the completion rate (throughput), you can derive the average time in the system (cycle time).
So what makes my bar a stable system?
Basically two guiding rules make my bar a stable system: WIP limit and Pull System.
1. WIP limit
WIP is the number of work items in my system. In my bar example it is the number of whiskey bottles on the bar. Bottles that have been opened, but are not finished yet. The WIP limit on my bar is 12 bottles because that's all I have space for.
(continued...)
Paulo, Agile Coach
“Cycle time and
Little's Law”
Applying Little's Law to track cycle
time
2. Pull System
Pull System describes the movement of work items driven by actual demand. In my bar example, a bottle that is finished opens a spot on my bar, thereby creating a demand for a new bottle to be opened and placed at the bar. Essentially, the movement of work items (whiskey bottles) is driven by actual demand: a finished bottle is removed from the bar, opening space for a new one that is promptly added to the bar, occupying the vacant space.
FAQs:
What if I do not have a stable system?
I would recommend trying and becoming a stable system. If the system is not stable, you will either starve for work, or have an overflow (with
increasing cycle time).
Can I use Little's Law to determine how much WIP my team can handle, or what my average
throughput needs to be - if I know my average cycle time?
Sure thing. If you are on a stable system and you know your average cycle time, then you can definitely play with Little’s law. You just have to be careful not to overdo it, especially for software delivery systems. They are empirical and there are several other things to do in order to reduce variability in software delivery.
“Cycle time and
Little's Law”
Applying Little's Law to track cycle
time
The Story
About 25 iterations ago (in our team’s 8th iteration and about 4 iterations after we first started talking about capturing these metrics!), our team began capturing and using a couple metrics for our own continuous improvement. These metrics have proven to be very useful in helping us improve our delivery process, so I wanted to share them.
Our Goals
1. To capture actual data about how our process is running.
2. To provide a baseline for continuous improvement of our software development process.
3. To use this data to help find problems, find out the root cause of those problems, and determine/ implement countermeasures so the problems won't happen again.
Cycle time and time each story/defect spends in each state
While browsing around our agile project
management tool’s help, I chanced upon a chart for cycle time of our stories. The chart could be automatically generated from data captured about our stories and defects. The tool defined "cycle time" as the elapsed time (measured in days, including weekends) between the states of In
Progress and Done.
The chart generated showed the mean, standard deviation, minimum, and maximum of the data set. Each point indicated the time that the card (story or defect) spends in each status as well as the cycle time.
The visualization was not bad, but for our
continuous improvement, I really wanted the data for each story or defect. Also, I was interested in tracking elapsed time in all states, so we could see bottlenecks, compare times across stories with the same points, and use that information to see if any of those times represent problems that we want to address.
So, I used Microsoft Excel™ to track that data, and would also write it up on our physical board along with a chart. We used this data as input into our weekly retrospectives to help improve our
process. I usually mark minimum / maximum times in each state, minimum / maximum cycle time, and highlight anything else that looks odd, interesting or worthy of the team’s discussion.
Note, the Ready for QA column is not yet used; as that is not yet a state in our tool. I'd like to have the state there so I can distinguish between In Progress and waiting to be tested to see if queuing happens, since our constraint right now is our number of Quality Analysts (QA) - we need more!
“Using Cycle Time
for Continuous
Improvement”
Kevin, Lead Consultant
A walk through of how cycle time
helped us track our progress
So, we completed our iteration and captured cycle time (the duration of the elapsed time between when a story is In Progress until that story is Done) metrics for all stories that we've completed (status = Done), and we looked at the results to see how we did. Here's an example of how this cycle time data could possibly be used for continuous
improvement during a retrospective:
Facilitator: “How did we do this iteration? Are there
any problems? Are there any opportunities for improvement?
I notice that stories #164 and #173 in the grid above have different elapsed times in different states, but they have the same cycle time of 8.1 days. Let's compare the stories:
1. Both are sized at 4 story points. 2. Both have a cycle time of 8.1 days.
3. Each has different amounts of time in each state that add up to that same 8.1 days. I'd start here. 4. What's different between the 2 stories?
a. Story #164 has 0 days In Progress, 5.1 days in
Validation/QA, and 3 days in Sign Off.
b. Story #173 has 1.1 days In Progress, 7 days in
Validation, and 0 days in Sign Off.
i. Why did Validation take 7 days? In this case, not only did it include a weekend, but the QA stories queued up as we had more stories in QA than we had QA capacity. We might consider setting Work In Process limits here, and using our Developer for the QA pair to help develop acceptance tests to get the stories done sooner.
ii. Why did Sign Off take 0 days (less than 1/10 of a day, about 2.5 hours)? Because we have a desk check with a QA, Developer, and the Product Manager (PM) to get from Sign Off to
Done. Most of our sign offs take less than 2.5
hours; only a handful take more. If they do take more about a day, it usually indicates some problem or perhaps a QA or PM is on vacation.”
“Using Cycle Time
for Continuous
Improvement”
A walk through of how cycle time
helped us track our progress
Story Status in Days Status in Days Status in Days Status in Days Status in Days Status in Days Status in Days Status in Days Status in Days Status in Days
Story Backlog None Huddle Prep Huddling
Ready to Play In Progres s Ready for QA Validatio n /QA Sign Off Cycle Time Story Points 164 72 27.9 0 2 42.1 0 TBD 5.1 3 8.1 4 173 51.9 3.8 3.8 2.2 42 1.1 TBD 7 0 8.1 4 113 108.9 28.3 46.8 17.2 17.8 2.2 TBD 4.1 1 7.2 2 168 61.9 24 0.2 4.5 27 0.3 TBD 2 4 6.2 2 175 47.1 0 1.8 0 45 0 TBD 2.9 0 2.9 1 (...continued)
A common comment I hear from folks about this time in the discussion is, “We don't really have
enough data to start determining patterns or to be predictive”. We have found that we don't need
data that is statistically significant to do continuous improvement. We're not trying to
predict the future or forecast, we're just trying to see if we can improve our process.
Benefits of the data above:
1. We can speak confidently about our process. When someone who is responsible for signing off on stories before they are done says, "It takes too long to develop these stories", we can respond and say things like, "On average, it takes 5 days to develop our 4-point stories; however, we noticed that it takes an average of 3 days for Sign Off - why is that?" It is amazing to me the statements that are made with no data to support them, and we can quickly cut through statements like these with data.
2. If we take care to use the scientific method, using hypotheses from our retrospectives about what will happen if we change one thing, each iteration becomes an experiment. We gather the data, analyze the results, and draw conclusions about cause and effect, and see what
happens. This allows us to determine the effect of changes we are required to make (such as a
new story huddle process). We are able to compare cycle time data collected from stories before the change and after the change, and give feedback to the folks who required us to use this new process.
3. Also, since we have been taking care to use the scientific method, we find that we can try just about any change to our process within reason, even changes that are still not common practice in the organization because we can try them as an experiment for one iteration, then analyze what happened, and change back if needed. 4. When we have data to support what we see,
and the data indicates a problem, that problem is not just my problem as the Iteration Manager, but rather the whole team becomes engaged in trying to solve the problem.
This collaborative problem-solving and experimentation is the foundation of
continuous improvement, and capturing cycle times is one of the most effective ways to get started!
“Using Cycle Time
for Continuous
Improvement”
A walk through of how cycle time
helped us track our progress
Continuous improvement is paramount to
consistently delivering real value to our customers. We invest in it heavily to minimize waste and always look for opportunities--both large and small--to improve how we work.
A recent example of how we’ve improved our process has been whittling and “WIP-ing” our wall. And it all began with a call to action by what had become our “weighted” wall. A couple of months ago, we had an impromptu conversation about our card wall.
We had two lanes: Ready for Sign-Off and Sign-off in
Progress, which was one way we tried to reduce
churn around development and testing, and to limit the number of sign-off issues.
However our Quality Analysts (QA) noticed a bit of a bottleneck around them -- the sign-off lanes were increasing our cycle time.
Since the Business Analysts (BA) were responsible for signing off stories, but were often busy with analysis, the QAs had to wait to test stories until the BAs pushed them through. To remove this blocker, the QAs suggested removing the “formal” sign-off lanes. After talking about the change, we decided to couple sign-off with desk checks, which we were already doing, but were now held more
accountable for.
Spurred by this whittling, we removed other unnecessary lanes and later increased our parking lot space to create a “poor man’s” WIP limit.
“Whittling our Wall”
Melissa, Business Analyst
Developers would move stories to
“Ready for Sign-‐off,” where they
would sit until...
...BAs pulled them into “Sign-‐off
in Progress” to make sure they
were reviewed and in good shape
for testing.
Together, these trimmings helped us reduce cycle time by removing bottlenecks and focusing our efforts on active work items only. It also allowed us to consolidate our wall from two boards to one (below), which effectively reduced the noise in our workspace. Our previously “weighted” wall had successfully signaled us to re-evaluate our process. It prompted a conversation that narrowed our focus to more effectively--and efficiently--deliver value.
We continue to review our process during bi-weekly retrospectives, but believe that spontaneous self-assessments are equally important and impactful in our efforts in continuous improvement. It helps us build trust among our team and with our customers and are always looking to how we can bolster our process and our product.
“Whittling our Wall”
And how it helped improve cycle time
Continuous improvement and product flow are popular themes on our product (Mingle, an agile project management tool) development team. Both internally as we reflect on our own
development practices, and externally as we build an agile project management tool that helps teams collaborate and improve together. To help us better understand our flow and gain more insight into ways we can improve, we’ve started to incorporate cycle time into team conversations. A few months ago, we rearranged our process and our card wall to improve our flow. We sensed that
these changes helped improve our flow, but to be sure we took a look at our actual cycle time to see if what we felt was true. We used the new cycle time analysis feature in Mingle to confirm what we suspected: our cycle time did improve.
As the image below shows, in the period from October through November, our average cycle time crept above 20 days before we made changes to our process. After we streamlined our wall, our wait time was reduced and our cycle time fell below 10 days.
Scott, Delivery Manager
Insight into how both can help track
progress and preempt bottlenecks
Over 20-‐day cycle time prior to
making changes to our process
Reduction in cycle time
corroborates the
improvements in our process
“Trailing indicators
good. Leading
Of course to get a full picture to feel confident of our changes we also verified that our throughput and work load remained about the same during the period over which our cycle time was
reduced.
This wasn’t a rigorous scientific experiment as we’re not looking for statistically significant results. We’re only looking for a signal that the actions we’ve taken have helped us only looking for a signal that the actions we’ve taken have helped us improve and based on our needs we have enough evidence to justify making our process changes permanent. Understanding our cycle time is thus a useful method in our continuous improvement efforts.
Trailing indicators good. Leading indicators better.
We’ve seen how incredibly useful cycle time is when looking back to make observations about how past changes affected the flow of work through our development process.
However, since cycle time involves looking into past performance (trailing indicator), it doesn’t give us real-time feedback when we’re facing problems in our flow today. To identify and fix issues going on in the development process right now, we need a
leading indicator.
We can respond faster to events that will affect our flow by looking for those things that would affect cycle time. Using a leading indicator in conjunction with cycle time would help us improve even faster.
Monitor your queue size
A key leading indicator for flow is queue size, which provides early signs that we may have problems with the flow of work through our process. A queue size that’s growing is an indicator that we’ll have problems that will be revealed later through higher cycle time.
Where the queues are
Unlike manufacturing in the physical world, software doesn’t have physical inventory stacking up on palettes or clogging a conveyor belt, making it more difficult to see the “invisible” incomplete product inventory building up. Instead of physical products, we can use stories as evidence of our work in process (WIP) and we can look at the number of stories in a particular phase of development as the queue size.
(...continued)
“Trailing indicators
good. Leading
indicators better?”
Insight into how both can help track
progress and preempt bottlenecks
For example
Consider the card wall below. Each column
represents a queue and what we see is that the Do queue is much larger than all other queues. If we know that our Do queue normally consists of only 3 stories, then the fact that the number of stories in this queue has jumped to 7 may be a sign that we’re having a problem in our delivery process. There could be any number of reasons for the increase in the queue but the main takeaway should be that something may be wrong and we should look to address it now rather than wait for the delay to show up in our cycle time.
Cycle time or queue size? Use both.
It’s probably natural at this point to question whether we should bother with trailing indicators like cycle time at all. Monitoring cycle time and queue size are both useful, just for different purposes. If you’re interested in learning how well work flows through your process so that you can provide forecasting or learn whether previous improvement efforts have been successful, then cycle time measurements are great. However, when you’re interested in heading off potential issues with your product flow you should consider using a leading indicator like queue size. I recommend using them in conjunction with each other.
(...continued)
“Trailing indicators
good. Leading
indicators better?”
Insight into how both can help track
progress and preempt bottlenecks
The growing queue size of the
“Do” queue is a leading indicator of
potential problems that would later
be revealed through high cycle
time
In summary
Cycle time is a useful metric to provide informed insight into the progress of your
development process.
Choose from various ways to calculate it, or integrate it in your development process with
a tool that analyzes cycle time.
Use the cycle time data collected to trigger and inform conversations with the team and
customer about improving and streamlining your process.
Keep exploring ways to improve, as collaborative problem-solving and experimentation are
key to continuous improvement.
How do you try to improve your process? Email us, or send your feedback
to #tw_studios #ebook. We’d love to hear your story.
Paulo Caroli
In 140 characters: Lean-‐Kanban,-‐
Scrum-‐XP-‐Agile Coach, Agile
Developer, Agile Project Manager
(Servant Leadership), Systems
Thinker, ThoughtWorker
I am a Delivery Manager
with ThoughWorks Studios.
I’ve spent the past 12
years building software
products and believe that
simplicity is one of the
most important attributes in
process, products and code.
I’m a Lead Consultant at
ThoughtWorks, working as a Project
Manager and Business Analyst on
software development projects and
consulting on lean and agile
transformation. In the past 18 years, I
have worked in a variety of
industries, including education,
nonprofits, public sector, financial
services, real estate, high-‐tech, and
healthcare services. I am very
passionate about continuous
improvement..
I am an author, speaker… essentially a
loud-‐mouthed pundit on the topic of
software development. I’ve been working
in the software industry since the
mid-‐80’s. My main interest is to
understand how to design software
systems, so as to maximize the
productivity of development teams.
I am an author, speaker… essentially a
loud-‐mouthed pundit on the topic of
software development. I’ve been working
in the software industry since the
mid-‐80’s. My main interest is to
understand how to design software
systems, so as to maximize the
productivity of development teams.
Kevin Kriner
Scott Turnquest
