Has this ever happened in your weekly stand-up?
Project Lead: Our users would have a better experience if we sorted the inventory list alphabetically rather than by quantity. Luca, can you write up a Jira task for this and then assign it to yourself?
Luca: Uh huh, yeah. Got it. I’m in the middle of that billing module refactor, and I still need to review Irene’s pull request before we can release her patch this afternoon. And there’s that new frontend developer that I need to onboard tomorrow. But yeah, I’ll get to it.
[Three weeks later…]
Project Lead: Didn’t we talk about sorting the inventory list alphabetically a few weeks ago? I thought I mentioned that we needed that done, but I can’t find it in Jira anywhere. We should really get on that. Luca, can you write up a Jira task for this and take it for the upcoming sprint?
If the inventory alphabetization task never made it into Jira, and Luca hadn’t picked it up to start work on it, then what do we do about the three-week lag time? Is there a metric to ensure that this type of lag isn’t overlooked? There is, and it’s called Cycle Time.
This post is the fifth in a series of detailed articles about DORA metrics. Previously, we looked at:
Today, we’re covering Cycle Time. Your next thought is probably this: “Wait a second. There are only four DORA metrics. Cycle Time isn’t a DORA metric.” You would be correct, astute reader!
So, how did Cycle Time make it into this series? Ultimately, we’re all about helping your team focus on its goals. Certain metrics—whether they’re explicitly DORA metrics or not—can empower your team to progress toward those goals. In addition to the four DORA metrics we’ve covered, Cycle Time is incredibly important for improving your team’s productivity.
In this post, we’ll look at what Cycle Time is and isn’t, why it’s important, and how to improve it. Let’s start with the fundamentals.
Cycle time: What it is (and isn’t)
We define Cycle Time as the time taken from a request being made to code being healthy in production. The initial request may be something like, “Hey Nancy, can we send users a monthly summary of their unpaid invoices?” At this point, the Cycle Time clock starts ticking. And it will tick until the monthly summary feature is in production and healthy.
That makes Cycle Time a broader and more inclusive metric than Change Lead Time. Cycle Time addresses the needs of stakeholders who can request features (“Jared, can we get 2FA for all mobile users?”) to end users who expect software to work reliably (“Danny, the user who complained about missing badges on his profile, sent a message saying it works now.”).
What isn’t Cycle Time?
The Lean community has a definition of Cycle Time that’s about how much time is spent actually working on an item. That’s an important metric. For example, you’d like to know if the team is pulling all-nighters to keep Change Lead Time low. As we continue discussing Cycle Time for this article, however, let’s think of the holistic flow of change, from request to healthy code.
What’s the difference between Cycle Time and Change Lead Time?
We define Change Lead Time as the time it takes your team to respond to changing conditions, events or needs, and it is measured from the date of the first commit to the date the change is deployed to production.
Change Lead Time is all about tracking how long it takes to go from “Hey Bob, let’s have you get started today on the Print Job Automation ticket in JIRA” to “Joe, I deployed that feature yesterday, and it’s looking good.”
Change Lead Time tracks the time from the start of work to production release.
Cycle Time, on the other hand, tracks the squishier, more human side of feature delivery. It includes the front end of the work item — from when the work item was requested — through that request’s definition and iteration and implementation, until the time it is available to users.
Why we need cycle time
Two issues that can derail projects are:
- Excessively large backlogs
- Failure to deliver what the business wants.
Let’s drill down into each of those.
Accountability for your backlog size
Backlogs are a fine way to keep a buffer of work for the team, but they must be reasonable in size. They cannot be several years’ worth of work. Why can backlog size be such a productivity killer?
Little’s Law reminds us that the amount of work in progress (backlog size) is directly related to delivery time. If your team wants to deliver features to users faster, then it needs to reduce the number of work items in progress — a slimmer and more tightly prioritized backlog — or it needs to improve its work throughput, or both.
It’s much easier to put a work item into the backlog, avoiding conflict, rather than saying, “Your idea will never see the light of day.” Cycle Time keeps your team accountable, not letting you get away with conflict-avoidant procrastination.
When a team tracks Cycle Time for a work item, the clock starts ticking as soon as an item is created (request), even if that item is thrown immediately into the backlog. Keeping an eye on Cycle Time will surface a team’s tendency toward backlogs of unusual size.
Avoiding “this isn’t what we asked for”
What the business needs can be a nebulous thing sometimes: the latest initiative might be a crystal-clear project with defined outcomes, or it might be a pet project of an exec. In either case, everyone’s understanding of those needs will improve over time and will absolutely be influenced by the latest posts trending on LinkedIn.
It’s hard to distill an understanding of a business need into well-defined requirements. But if you don’t have a clear definition, your developer resources will be wasted building something that nobody is asking for.
The time needed to arrive at a clear definition for requested work — and all of the iterations that occur before even the first line of code is written — is accounted for in Cycle Time.
Although Cycle Time is not a DORA metric, tracking it can bring out tendencies in your team and in the organization that affect your goals but that other metrics might not capture. For example, looking at Cycle Time may lead you to conclude, “Brad’s feature requests always seem to have four weeks tacked on to the front just to figure out what he’s actually asking for.”
How (and why) to improve cycle time
Improving Cycle Time will make your team’s delivery feel snappier and more responsive to your stakeholders. They’ll ask for a feature, you’ll deliver it in days or weeks, and they’ll brag to their friends in other companies about how things just happen for them. They’ll probably attribute that to leadership skills or time management or something, but humor them: everyone wins here.
Measure, then manage
Relentlessly tracking DORA metrics and Cycle Time in your delivery pipeline is important. Some aspects of your system need to be measured before they can be managed, and Cycle Time is one of them. Once you’re able to see how metrics evolve over the course of several deliveries, then you can address the causes.
Choose strategic goals
Select a Cycle Time metric goal that makes business sense, and then work out how and when to achieve that goal. A strategic approach means that you can share this with the entire team and celebrate wins. Without this approach, you’re likely to investigate small issues in metrics without getting a win that you can share with the wider organization.
For example, your Cycle Time goal might be: This quarter, we want to reduce the average Cycle Time for all new work requests to six weeks. When everybody in the organization knows this is the goal, then several things start to happen:
- Team members will become more thoughtful about what work requests to bring up, and better prioritization will begin to take place.
- Team members will become more disciplined about defining their work requests before bringing them up, so as to reduce the amount of time lost to rework and clarification.
As your team gets into this rhythm, and the culture of requesting (and delivering on) work improves, then you can incrementally level up your Cycle Time goals. Ultimately, just like in improving any of the DORA metrics we’ve covered in this series, improving Cycle Time will help your team to execute faster and turn around features faster.
The do’s and don'ts of Cycle Time
Do: Involve the team
It’s human nature to want someone to own a process. However, Cycle Time spans so many different kinds of work that you would do well to ensure everyone is aware of the metric and your goals. As you pick a strategy and settle on some strategic goals, communicating what you’re aiming for is vital for achieving it.
If the team is aware of the metrics, they can find ways to improve them.
Don’t: Pad the backlog
If you’re accepting stories in the backlog that you know you will never do, you’re deceiving your colleagues, and your Cycle Time will show it. Instead of using the backlog as a substitute for difficult-but-important team conversations, seize the opportunity to focus team members on high-priority and high-value work.
Do: Go for the wins
Sometimes, changes in your process will improve more than one metric at a time. For example, if the developer team and the platform team focus on improving Change Lead Time, then they’re likely to improve Cycle Time in parallel. As you think through strategic goals for improving your team, look for the big wins. Having a tight feedback loop for your delivery systems and how your metrics are affected will help you see what’s working and what isn’t.
Look for relative lulls in workload so that your team can experiment without struggling under the pressure to deliver.
Don’t: Try to eat the elephant
Every so often, there’s a Herculean request that comes in, typically with some urgency from senior people. (“Brad says we need it all done by next month!”) Many teams will respond by canceling vacations and throwing people at it.
It’s always worth trying to break down these massive requests. Even if you do have a real business need with a fixed deadline, breaking it down into smaller parts allows you to assess and improve Cycle Time in small chunks, instead of tackling it all at once — possibly when it’s too late.
Do: Give credit
In Frederick Taylor’s pioneering work in the 19th century (The Principles of Scientific Management), he encouraged teams to perform better by writing down what the previous shift achieved. Of course, it’s seldom helpful in an organization to pit teams against each other. However, it is important to share the wins. If there’s an improvement, give the responsible team some recognition.
Don’t: Ignore the red flags
We’ve all had that one order or one customer where everything went wrong. If you end up being asked to do something ill-defined or incorrect, and your gut is telling you that something is wrong, listen. Teams sometimes end up working on things that they know are wrong because they don’t want to disappoint stakeholders. The resulting fiasco can ruin your metrics, derail improvements, and shipwreck morale for weeks to come.
If you are forced to work on something, think about how to raise issues early and mitigate the risks. Nothing will ruin all your metrics like a full fire drill.
Conclusion
Used correctly, tools like the DORA metrics can turn your team from OK to awesome. Use that power wisely! It’s always too easy to reward ingenuity and hard work with… more hard work. In addition to crushing our business goals, we need to look after our people and work out how to help them level up their careers. People who are relaxed and happy and having the time of their lives are good for your team.
In this final post on critical metrics for team goals, we’ve introduced Cycle Time and explained why we need it and how to improve it. It’s not a DORA metric like the four metrics we looked at previously in our series. However, it is just as important in helping you put numbers to organizational culture and team work progress.
