Lead Time: Why it Was Slow in Kanban, and How it Hurts Scrum Teams Today
In this article you will learn:
- What is the significance of lead time in Kanban and Scrum methodologies
- 5 causes of lead time in older Kanban development organizations
- A modern meaning of lead time and how it can help you improve a Scrum sprint pipeline
- Lead Time in Testing: re-prioritizing to discover critical and long standing issues
What is Lead Time?
In Kanban methodology, lead time is the time it takes for a task which appears in your workflow to be completed and delivered to customers. This is an important metric because in Kanban, tasks constantly enter the pipeline and we need to know how quickly the team is completing them.
In Scrum methodology, lead time is supposedly constant. Scrum is a time-boxed approach, where teams operate in fixed-length sprints of 1-4 weeks. For example, if a team commits to completing 10 user stories in the next two week sprint, the lead time of those user stories will be two weeks.
That’s the simple answer, but there’s a complex answer we’ll explore further in this post, to understand how a modern definition of lead time can shed light on problems and inefficiencies in the sprint pipeline.
5 Causes of Long Lead Times in Kanban
Kanban is Japanese for “card”, and is a workflow system invented by Toyota in the late 1940s. The classic Kanban system is a board with cards depicting tasks that need to be performed by a team. The board has columns representing statuses, and when a task changes status, cards are moved physically to the next column.
There are five common causes of long lead times in Kanban systems:
- Handoffs and manual procedures – as soon as some of the workflow stages in the Kanban system involve a handoff from one department to another, or a manual process, lead times start to increase.
- Approval processes – in large enterprises, there can be long, complex approval processes for changes to software.
- Environment management and provisioning – waiting for a new environment to be provisioned or installed by IT can create long lead times and increase the cost of software deployments.
- Manual software deployments – many organizations still deploy code manually. Automating manual deployment can cut “lead times” by over 90%.
- Manual software testing – although test automation technology is advanced and widespread, many test automation tasks are still manual, causing complexity, errors and delays in completing and delivering software tasks.
Many of the above issues have been taken care of in the Agile/Scrum framework. The Scrum team is self-sufficient, able to provision environments independently, and equipped with tools that automate most aspects of testing and deployment.
They are also, at least in theory, not subject to handoffs and manual approvals, except at the end of a sprint when software may undergo acceptance testing by stakeholders.
So is lead time “not a thing” in Scrum methodologies? Let’s find out.
Lead Time in Scrum: A Modern Meaning and Using it to Improve Your Sprint Pipeline
When a customer voices a requirement, that requirement enters the product backlog. Once in a while, the product owner and Scrum team create a release plan spanning several sprints, and decide which tasks from the backlog will be done when.
Some tasks enter the release pipeline and are scheduled to be done at a known point in the future. Other tasks do not enter the release plan and stay in the backlog. How long do they stay there? Nobody knows – until you measure the time.
How Can Lead Time Help a Modern Scrum Team?
Measuring lead time helps you understand how good your team is at addressing all customer and stakeholder requirements.
- It’s very easy to add items to the backlog and forget them, focusing only on the sprint at hand and the items prioritized for the current release.
- However, all items in the backlog represent a requirement that was important for a customer or a stakeholder at some point in the project, and may still be important.
- “Grooming” your backlog is important, to ensure you are not counting issues that are not important or relevant anymore given the evolution of the product and customer requirements.
- After the backlog is groomed, measuring “lead” time from the moment a task enters the backlog to delivery, can give you an idea if there are “neglected” requirements hiding in your pipeline.
3 Useful Lead Time Measurements
- Lead time for each item in backlog – measure lead time for each task in your backlog, and display it visually in the list of backlog tasks. Tasks with a high lead time will immediately jump to your eye.
- Average lead time for all tasks in backlog – counting only items which have not been selected for the current release. Track this number across releases – if it is increasing, you may have a capacity problem.
- Maximum lead time – measure maximum lead time and watch tasks that have the highest lead time – customers have been waiting for these the longest. May be worth revisiting them, and either removing from the backlog or including in the current release.
Lead Time in Testing: Re-prioritizing to Discover Critical, Long Standing Issues
Tests and bug fixes are part of the items in your backlog and release plan. Important quality improvements are often neglected, in favor of more urgent items such as new features or production bug fixes. Are you measuring the lead time of your old quality tasks? Some of them may become next week’s production disaster, or technical debt that will gradually build up and hamper your ability to innovate.
A new category of development tools called Software Quality Intelligence help dev teams prioritize tests and quality improvements using real time data. For example, SeaLights is a quality intelligence platform that can help you discover test gaps in your code – areas of your product which are frequently used in production, have undergone recent code changes, and are not sufficiently tested.
In can be quite powerful to combine a test gap analysis, from a platform like SeaLights, with lead time measurement. Of your old, neglected quality tasks, which are extremely important to prevent quality issues in the product? Those should be reprioritized and added to upcoming sprints. On the other hand, backlog items that refer to areas of the product which haven’t recently changed, are already tested or are not currently used in the product, can be set aside.
Read our white paper, Quality: The Missing Metric for Development Managers to better understand how quality data can improve the efficiency and velocity of your Scum team.