What is it
Lead time: Lead time is the amount of time that passes from the start of a process until 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 it matters
Agile teams aim for continuous and frequent deliveries. small iterative batches to and is a measure of how fast your getting changes or new features to the customer
Teams that practice Kanban focus on throughput, and a s 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 can tell your team how long it takes to get things done; relative to your Completed Work that tells your team how much your team can get done in relation to what they think they can get done.
Lead Time is a valuable measure of your Continuous Delivery practices and can measure all parts of your delivery process to find inefficiencies. It’s a great high-level indicator of the inefficiencies within your overall process that are holding your team back.
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 with managing expectations with stakeholders on the time it can take to deliver your goals.
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 your efforts in making small improvements that will most positively impact your process.
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 predictability
What good looks like
Lower cycle times are indicative of an iterative working culture working on small batches of work with higher release cycles. benefits of smaller lead and cycle times are improved quality, accelerated learning and lower cost to produce.
YOu’d expect tasks that are well defined and brioekn down
How Umano measures this
Practices that influence this measure
PR Comments
PR Commits
Time to approve and merge a PR (hours a PR is open)
What’s included
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.
Take a look at your usual rate Completed Work to see if there are trends in 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.
Take a look at your Time to Merge and Review Progress 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.
0 Comments