Are Takt Time and Cycle Time Still Relevant for Agile Development?
Takt time and cycle time were very important metrics in Kanban and other, older lean frameworks. In this article, we’ll investigate what these metrics mean in an agile framework, whether they are still relevant, and how they can help you identify and solve critical issues in your development lifecycle.
In this article you will learn:
This is part of our series on agile metrics – see other articles in this series:
What is Takt Time in Agile Development?
Takt time measures how long it takes for a new product, version or feature to be released to your users. How often do you provide new value to your customers? In agile methodologies, takt time has dramatically increased, and most organizations are shipping releases every week, every day, or even multiple times a day.
What is Cycle Time in Agile Development?
Cycle time is the “shelf life” of an item in your development plan – how long it takes a task to go from start to finish. In Scrum methodologies, you might think that cycle time is equal to sprint length, because tasks “start” at the beginning of the sprint and “end” when the sprint ends. However, this is not always true.
In reality, different tasks within a sprint may have different cycle times. In a two-week sprint, one task may be completed within one day, while another task might take 13 days to complete.
Why is Cycle Time/Takt Time So Important?
Software development is a complex process, and a lot happens between the time a task is started and the time it is declared “done”. Cycle and takt time have a critical impact on your team’s productivity and your customers.
The faster your cycle time:
- The faster you can complete items during a sprint, and more confident you will be in delivering the scope you committed to.
The faster your takt time:
- The smaller your iterations, and the faster customers will receive new, working functionality.
- The faster you can pick up items from the product backlog and deliver them to customers as working functionality. After all, if each sprint only contains a few items, customers will still wait a long time for the functionality they need.
Cycle and takt time are closely related. If you are able to turn around items quickly, which means you are breaking sprint tasks into granular, self-contained pieces, and are able to work through those pieces quickly and effectively – you can also shorten your release cycle and deliver more in each release. This is how organizations like Google, Facebook and Amazon are managing to release software to their customers hundreds or even thousands of times every day.
How Can Cycle Time Help You Identify Issues in Your Development Process?
You can identify important issues in your process and sprint pipeline by monitoring your cycle time. Are multiple items taking several days and completing near the end of the sprint, meaning cycle time is too high? If so, you should ask the following questions.
- Does your team break down user stories into small enough increments?
Breaking down user stories into granular, self-contained elements requires diving into detail during sprint planning, and a lot of creativity. But if it’s done well, it can help teams estimate work better, understand it better, divide it better between team members, and get it done more quickly (relative to the smaller size of the task).
- How quickly are code reviews picked up and implemented?
If developers are already working on other features when their code reviews come in, they will need a context switch to go back to that old code, and implement fixes and suggestions from their peers. Build code reviews into the development process, ensuring they are provided promptly and developers have time to react and fix their code. This will improve cycle times and streamline the sprint flow.
- Is there a problem in your development pipeline tooling and process?
Everyone in agile has invested in automation and tooling, but the tooling is never perfect, and you might find that specific sprints or releases introduce new problems that were not anticipated. Long cycle times might indicate a technology issue that, if resolved, will release bottlenecks within the sprint.
- How long is your software quality assurance cycle time?
Gone are the days of “passing it to QA” and waiting for the testers to do their thing. Most testing is done by developers, or others who are an integral part of the sprint team. Nevertheless, testing takes time, and it is usually done after code has been written (except in a TDD framework).
There is still a QA cycle time, and it dramatically impacts the cycle time of each item in the sprint. Creating a streamlined process where testing happens immediately after development will help you complete tasks faster.
When You Improve Cycle Times, Watch Out for…
Like any metrics, cycle time is not a means to an end. Improving cycle time can do good, but needs to be balanced with other metrics to ensure that the development process has really improved.
When you see an improvement in cycle time, watch out for these other metrics to ensure you don’t have a new issue in another part of the process:
- Quality and technical debt – a measurement of cycle time must always include some measurement of quality. For many teams, the only measure of quality available is defect density or unit test code coverage. These are imperfect metrics, but they at least give some idea of whether tasks are being performed faster at the expense of quality, resulting in technical debt.
- Defect injection rate – related to quality – how many defects are added to the product as new features are developed? This can be measured in retrospect by looking at a trend of production defects per release. This is usually affected by the expertise of the development team and the complexity of the development project.
- Time on task – cycle time measures the “calendar distance” between start and finish of a task. It doesn’t consider how much time was actually invested in the task. If the duration of a task shrank from 6 days to 2 days, but the number of hours spent on the task grew from 10 to 20, there may be some inefficiency introduced into the process.
- Appraisal methods – appraisals such as code reviews, inspections, developer testing and user acceptance tests have a major impact on cycle time. It’s easy to reduce cycle time, for example, by removing code reviews. The idea is to see cycle times improve without hurting the quality controls built into the development process.
Cycle Time Optimization Requires a Solid Measurement of Quality
We mentioned above that as you improve cycle time, you need a good measurement of quality to ensure you aren’t building up technical debt. Existing measurements of quality are far from perfect – to understand why, see our in-depth articles on defect density, code coverage and test metrics in general.
A new category of software tools called Software Quality Intelligence is helping make quality more transparent, and provide real data about how well software is tested and the risk of production faults. This can help you combine cycle time data with a true measurement of software quality.
For example, SeaLights is a platform that collects data about which parts of your product have recently changed and are not sufficiently tested (looking at all types of tests, including unit, integration and acceptance tests). SeaLights helps you visualize test gaps, understanding if new features represent a quality risk.
Read our white paper, Quality: The Missing Metric for Development Managers to understand how quality data can help you streamline your sprint and improve development team velocity.