Nimble Work Management
Kairon - Gen AI Solutions
AKT/ AKC Access
→ Agile Methodology
→ Agile Software Development
→ Agile Program Management
→ Scrum Methodology
→ Kanban Methodology
→ Extreme Programming (XP)
→ Behaviour Driven Development (BDD)
→ Feature Driven Development (FDD)
→ Adaptive Software Development (ASD)
→ Dynamic System Development Method (DSDM)
→ Sustainable Pace
→ Story Mapping
→ Test Driven Development
→ Acceptance Test Driven Development
→ Iterative & Incremental Development
→ Pair Programming
→ Unit Testing
→ Acceptance Testing
→ Agile Planning
→ Refactoring in Agile
→ Burndown Chart
→ Lead Time & Cycle Time
→ Agile Velocity
→ Definition of Done
→ Backlog Refinement
→ User Stories
→ Scaled Agile Frameworks
→ Large Scale Scrum (LeSS)
→ Scrum of Scrums
→ Agile Release Train
→ Is SAFe Agile?
→ SAFe Implementations
→ Enterprise Agility With SAFe
→ What is Project Management Lifecycle?
→ What is a Project Management Office (PMO)?
→ What is Agile Project Management?
→ Importance of Project Management
→ What is a Project Roadmap?
→ What is Resource Management?
→ What is Work Management?
As you walk out of your manager’s office, you’re not sure how to proceed.
He’s asked you to start measuring the lead time and the cycle time for all the user stories your team implements.
Should be simple. After all, you’re already keeping track of what’s going on. But you need to figure out what these metrics are and how to calculate them.
That’s exactly what this article is about. Read it and you’ll learn what lead time and cycle time are and what they reveal about your team’s process.
Lead time and cycle time are metrics that originated in manufacturing a long time ago. The definitions have been adapted for use in agile software development, specifically within the Kanban framework.
Recently, the terminology in use in the Kanban framework has shifted:
It’s important to note that ‘customer lead time’ is about a team’s context, not the company’s.
A team’s customers are a product manager or owner who decides what work to do on the product, and the Ops and Support people who take the team’s work into production.
In Kanban, cycle time is defined as the time it takes from when you start work on a user story that’s ready for implementation, to when it’s ready for delivery (release).
In terms of Kanban board columns this is the time from when you move a card from “Ready” (“To do”) to “In progress” (“doing”) to the time when you move that card from “In progress” to “Done”.
Of course, user stories aren’t the only work on a Kanban board and you can measure cycle time for all tasks you track on a Kanban board. For example, bugs that need fixing or research you need to do before you can proceed with a user story or bug fix.
However, if you want to look at cycle time in relation to lead time, you want to focus on items that directly deliver value to the team’s and company’s customers, the user stories.
In Kanban, lead time is defined as the time it takes from a user story being ready for implementation to when it’s ready for delivery (release). This includes the time it’s sitting on the backlog waiting to be picked up.
In terms of Kanban board columns this is the time from when a card is added to “Ready” (“To do”) to the time when you move that card to “Done”.
The full picture looks like this:
You then have several options to look at and analyze your lead and cycle times.
A common way is to use the cumulative flow diagram. You can measure lead time on it by drawing (and measuring) a horizontal line across the “Ready” and “In progress” phases. And cycle time is simply the width of the “In progress” phase.
Other diagram types may be more intuitive to visualize lead and cycle times.
For example, distribution charts that plot the number of cards vertically and the lead and/or cycle time horizontally.
You can’t talk about cycle time without talking about Little’s Law.
It says that the average number of cards in a stable system is dependent only on the average rate at which work items arrive and the average time a work item is in the system.
Put in Kanban terms:
Work-Items-In-Progress = Arrival Rate * Cycle Time
This is important because it shows that to limit Work-In-Progress, you only have two options:
What’s interesting is how stable or volatile these metrics are.
A stable cycle time indicates a team working at a sustainable pace, and not encountering too many disruptions. And a stable lead time indicates stories are coming in at the same pace a team can implement them.
This is what you want as it means you can predict when a team will deliver a story, whether that’s the first up for implementation or further down the prioritized backlog.
A volatile cycle time indicates a team with challenges.
They could be onboarding new members, wrestling with new tools, facing system failures, brittle processes and tests, variability in scope and type of user stories, and anything else that makes it impossible for them to maintain a constant, sustainable pace.
These are all opportunities for improvement that’ll help a team become more predictable in their delivery of value to customers.
A volatile lead time with a stable cycle time indicates work is arriving in leaps and bounds.
The lead time will rise when the rate of arrival is higher than the team’s rate of implementing them. It’ll fall when fewer stories come in than the team can handle.
A team can’t do much about how fast work arrives, but they can set Work-in-Progress (WIP) limits on the number of items ready for implementation and in-progress, to maintain a steady flow.
The gap between lead and cycle times is the average time a story sits on the backlog waiting to be implemented.
Though having a lead time equal to the cycle time sounds nice, it actually isn’t because it would mean that team members are regularly twiddling their thumbs waiting for work.
But you don’t want lead time to differ too much from cycle time. Fully refined user stories waiting on the backlog risk growing out-of-date.
Lead time and cycle time don’t tell you how fast you need to implement user stories, or solve bugs, in order to keep up with how fast they’re arriving.
Takt time, another manufacturing metric, can help.
It’s the rate at which you’d need to implement user stories to keep up with their arrival. It’s calculated as the time available for work divided by the number of completed stories needed.
For example, when 20 user stories arrive per week, you’d have to complete stories in 0.25 days to keep up.
Few if any Kanban software products measure takt time.
This is understandable, as hardly anyone in Kanban for software development talks about it. What’s more “time available for work” can get you into all kinds of fruitless discussions about what to include and what not.
The simplest, quickest, and most straightforward way is to just count working days and not bother with the number of developers, their days off, or anything else that affects “developer available time.” That all just gives you a fake sense of accuracy.
Simply counting work days makes the calculation easy and tells you instantly whether it’s feasible, or you need to take more structural measures, like adding a development team, to keep up.
Cycle time includes wait time, but in itself doesn’t give you any insight into how much time a story spends waiting after someone has picked it up.
To get that, separate an ‘in progress’ status into ‘in progress working’ and ‘in progress waiting’. That’ll help you diagnose and address what is causing cycle times to rise. And whether cycle time is indeed falling as a result.
If separating out wait time shows that a lot of your cycle time is actually wait time, it can be a good idea to make a further distinction between internal and external factors. In addition to the ‘in progress waiting’ column, you’d then also have an ‘in progress blocked’ column. And you’d “block” a card when you’re waiting on someone outside the team.
When you have cards blocked more often simply waiting, it’s little use to try and reduce wait time further. You’d have more results chasing the people outside your team!
A team’s cycle time is an average. You can have a stable cycle time and still have a significant variance when you look at cycle time for different types of work.
Distribution charts and scatter plots of the cycle times of individual items can help you gain more insight.
If the plotted points on a distribution chart or scatter plot link to the cards they represent, you can easily dig into what the cards in the tail of the distribution have in common—and do something about it.
Coloring the points on these diagrams according to the type of work on the cards they represent, makes it easier to spot patterns and make predictions for similar work in the future.
Lead time and cycle time give you insight in your own process. Bring takt time into the picture with them and you’ll also get insight into whether you can realistically meet what’s coming at you.
Because when the difference between how fast you need to go and how fast you can go, gets too big, that calls for other measures than running harder.
So, start tracking these metrics, get a grip on your process, and gain the insight you need to know which levers to adjust.
Signup for updates!
Speed up your Agile planning and execution!
Signup for a FREE Trial of Nimble Agile