What is Lead Time, Cycle Time and Wait Time
Lead Time: Lead Time is the amount of time that passes from the start of the development process of an item through to its completion. (Issue created → Issue completed)
Cycle Time: Cycle Time is the amount of time a team spends actually working on producing an item, up until the product is ready for shipment. (Issue In Progress → Issue completed)
Wait Time: Wait time is the amount of time that passes from the start of a process until a team actually start working on it. (Issue created → Issue In Progress)
Why Lead Time, Cycle Time and Wait Time matters
Typically, customers want their product shipped as fast as possible with minimal effort.
Understanding how long it takes your team to design, build, review and ship a feature is key to answering the question from your customer “When will I get it?”. Teams can respond with a greater degree of certainty and confidence when managing stakeholder expectations on the time it can take to deliver your goals.
For teams applying the agile method, their practices are grounded in the 12 Agile Principles, with relevant principles focussed on frequent, continuous delivery:
Principle #1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Principle #3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Principle #10 Simplicity - the art of maximising the amount of work not done - is essential
Teams that practice Kanban focus on throughput, and as a result they usually put a heavy emphasis on Lead Time. The faster a team can move tasks through the pipes, the better throughput they can achieve.
Scrum teams can use Lead Time to understand how long it takes to complete items. Teams can also cross check this measure with their rate of Completion Rate which helps them understand how much you can get done relative to what they think they can get done.
Lead Time is a valuable measure of your team’s Continuous Delivery practices, allowing teams to inspect all parts of your delivery process to find inefficiencies that are holding your team back.
Better understanding your time cycle (for example, idea to development is 2 weeks, but idea to live is 2 months) helps you understand where in the delivery lifecycle you’re most blocked. Your team can then more confidently choose where to focus their efforts in making small improvements to most positively impact their workflow.
Time taken across all items worked in the sprint provides insight into the complexity of the work being undertaken to release to customers.
Lead Time can also be used as a measure of your team’s predictability by indicating how consistently they take to build and merge items over time.
What good looks like
The goal of measuring a team’s Cycle Time is to quantify and understand the speed at which your team can deliver working software.
Shorter cycle times mean an optimised process and faster time to market. Shorter cycle times are also indicative of an iterative working culture working on small batches of work with higher release cycles. The benefits of smaller lead and cycle times are improved quality, accelerated learning and lower cost to produce.
Longer Cycle times usually indicate waste or inefficiencies in your team’s workflow, resulting in delays for your customers.
How Umano measures this
By reviewing all tickets within an iteration, Umano identifies all the tickets that were completed within the iteration that was allocated to that iteration. We then Identify when each of the tickets that were completed during the sprint is created (created_time), when they were moved to progress (moved_to_progress_time) and when each of the tickets was completed (completed_time).
The median time for all tickets completed in the sprint is then assigned to Lead, Cycle and Wait times.
What’s included?
Each model looks and specific activities within the tools. Below is a list of activities that contribute to Lead, Cycle and Wait Time and activities that do not have an impact on this metric.
Included | Not included |
All issues identified in the team’s board. | All sub-tasks within a ticket assigned to the iteration. |
Practices that influence this measure
Number of ticket additions mid-iteration
The ratio of change in ticket titles
The ratio of change in ticket descriptions
The ratio of change in ticket acceptance criteria
Number of tickets inherited to the active interval from a previous iteration
Wait time of tickets
Cycle time of tickets
Tips for improving Lead Time, Cycle Time and Wait Time
Small batch sizes have the effect of lowering cycle times by factors of 10 to 100.
Get clear requirements; take time to define your tasks well by providing a description, ideally framed as a user story so it’s clear what the customer will be experiencing when this task is shipped.
Break your task down into small pieces to improve the team’s understanding of what’s being asked of them and what’s required to deliver the task as defined.
Take note when your Lead Time or Cycle Time rises above your usual rating; this can act as a signal that there is a problem.
Track time variables for each ticket type to better understand the impact of the type of work your team undertakes has on its speed. This can also provide insight into where in the code or the process time is being sunk, and lead to a possible refactoring.
Reduce the number of items that are WIP status, and maintain your development pace
Take a look at your usual Completion Rate to see if there are trends in WIP tickets being carried over multiple sprints.
Use Sprint Stability to help you work with your stakeholders to manage the amount of new work coming into your sprint, or reprioritise WIP tickets that don’t relate to your sprint goal.
Take a look at your Time to Merge and Review Progress (coming soon) metrics in Umano to understand the impact of PR comments and number of commits on a PR, along with the duration of merging a PR as this can contribute to longer Lead Times. The more commits on a PR, the worse the original PR so ideally this number should be low.
Look to automate your tests as much as possible.
Review the impact of your deploy system and any lagging impacts this has on your speed to deliver.
Resources
Cycle Time vs Lead Time vs Takt Time: https://tulip.co/blog/lean-manufacturing/cycle-vs-lead-vs-takt/