Cycle time and velocity are both commonly used to measure and improve software teams’ ability to estimate how long it will take for them to complete a piece of work. While both metrics have their time and place, cycle time is generally the more useful measure of the two. But before we get into the why, let’s quickly define both metrics.
What is velocity?
Velocity is an estimation of how many story points an agile team can complete within a sprint. It conveys the average number of story points completed in past sprints. Velocity helps teams plan their work and decide how much work to include in their next sprint.
What is cycle time?
Cycle time is a measure of how long it takes for a team to complete a piece of work from start to finish. It’s commonly used to understand how long it takes to deliver a piece of work and optimize the team’s speed.
Why is cycle time a better metric than velocity?
While both cycle time and velocity can be used in a variety of different ways, planning estimates are a common use case for both. In this comparison, we’ll focus on that particular objective. However, it’s also good to note that making the right decision between the two depends heavily on your context.
1. Cycle time is harder to game
One of the main reasons agile teams use story points to estimate time-bound work is that the abstraction makes it difficult to compare teams with one another. That’s because the size of a story point is subjective, allowing each team to come up with their own definition. Unfortunately, this also makes velocity inherently easy to game. In fact, increasing velocity is as simple as over-estimating how long it will take you to complete a task and adding a larger number to your issue tracker.
While cycle time is a more objective unit of measurement than story points, you could still argue that cycle time can also be gamed by lowering the scope of work you complete in a given cycle. That’s partially true, but this kind of optimization will most likely work in your favor. Most teams are working on overly large issues anyway, and splitting the work into smaller batches helps them iterate faster.
This is especially true for smaller pieces of work, such as pull requests. And since decreasing your cycle time requires you to complete work measurably faster, your team will have to identify and fix real process bottlenecks to improve.
2. Cycle time helps spot outliers
A good way to continually improve a team’s ability to plan and estimate work is to have open discussions about outliers and understand why a specific task took much longer than estimated. In other words, if you can’t identify and drill down into outliers, it’ll be hard to get better at planning as a team.
Story point -based velocity, on the other hand, has one additional level of abstraction on top of time. That extra layer makes it harder for teams to get to the important discussion on why a specific task exploded. And without that conversation, it’s nearly impossible to improve the team’s planning accuracy over time.
When you’re using cycle time for planning, the goal is that all the planned units of work (user stories in particular) are approximately the same size. With this practice, you team learns to split work into equally sized chunks, which helps you better estimate how many issues of different kinds (bugs, tasks, stories) you can complete in a sprint. And when you notice that any issue took longer than expected, you can have an informed discussion about what caused it and learn from it.
3. Cycle time doesn’t add meetings to your calendar
Measuring velocity comes with the overhead of planning poker. Planning poker is a type of meeting where the whole software team comes together to guesstimate the effort of different tasks. This technique results in gauging a number of story points for each task. The problem is, planning poker and guessing the size of a task is additional work that in itself provides little value.
With the right tools, measuring cycle time doesn’t add any extra meetings or ceremonies to your work weeks. With the cycle time based planning approach, your team will spend more time in splitting and better defining tasks, which is valuable work that contributes to creating the actual solution.
Bonus: Cycle time is connected to improved business outcomes
As an added bonus, out of the two metrics, only cycle time is directly related to business outcomes. And while this argument has nothing to do with planning and estimation, it’s still important to address for the following reasons.
Firstly, the link between cycle time and business outcomes has been extensively researched by the DevOps Research and Assessment team. When talking about the cycle time of features shipped to customers, this metric determines how fast you’re able to ship additional value to your customers. Software teams with fast cycle times learn faster and can outpace their competition.
Secondly, it pays off to look outside your immediate use cases when you’re making a decision on what to track. Besides, getting to your objectives with a minimum number of metrics will make things easier. So if you choose to use velocity for the planning estimation use case, you would still want to follow cycle time as well because it’s linked to business outcomes. By measuring only cycle time you will satisfy both of these needs with one metric.
Thirdly, given the strong link to business outcomes and the objective unit of measurement, cycle time is a great metric for continuously improving your software teams’ ability to iterate quickly. After all, teams that ship fast have more opportunities to learn and improve their planning accuracy. In addition, discovering and fixing bottlenecks related to cycle time, such as too much work in progress or long wait times for code reviews, are closely related to improving estimation accuracy, since these are exactly the kind of things that make estimation difficult in the first place.
Can we use cycle time as our north star metric?
Unfortunately, cycle time is not a silver bullet either. While it’s a proven metric for improving planning accuracy, when used in isolation, you run the risk of obsessing over a single metric and compromising other important aspects of software development productivity. That’s why measuring cycle time should be balanced with other metrics that can indicate if you’re going too fast, such as change failure rate.
How should you decide what to measure, then? It’s relatively easy to come up with a large number of metrics that all seem to give a signal of some sort. What’s difficult but crucial is being able to separate the wheat from the chaff, especially when your engineering culture is at stake.
Luckily, there’s new research in the area of software team performance, making it that much easier to confidently select a holistic set of measures that can help you get towards your objectives. The SPACE framework combines much of this latest research under a single framework. We strongly recommend familiarizing yourself with the framework when thinking about which metrics to adopt in your organization.
