How to Calculate Cycle time: 5 Steps to Faster, More Predictable Delivery

Do not index

Calculating cycle time is, at its heart, a simple idea: it’s the elapsed time from when work actively begins on a task to when that work is considered complete. Think of it as the true "time-in-process," giving you a brutally honest look at how fast your team turns ideas into delivered value.

Your Delivery Speed Is a Mess, and Cycle Time Is Why

Let’s be honest. Your team’s delivery feels unpredictable. One sprint you’re crushing it; the next, a simple feature takes an eternity. You've heard about "cycle time," but it feels like another piece of agile jargon that’s more theory than practice. The kind of thing consultants love to talk about but no one actually does.

The truth is, it’s the single most important metric you're probably ignoring. This isn't about cracking a whip or micromanaging; it's about finally seeing the invisible friction that’s strangling your process.

The Unvarnished Truth About Your Workflow

Metrics like velocity can be dangerously misleading. They tell a story of output without revealing the brutal, knock-down, drag-out fight it took to get there.

Cycle time tells the unvarnished truth about your team's health and the efficiency of your entire software development lifecycle management. It exposes the hidden wait states, the review bottlenecks, and the communication gaps that grind progress to a halt.

Think of it as the diagnostic tool that finally shows you where the system is clogged, not just that it’s slow. It answers the one question that truly matters: Once we start something, how long does it really take to get it done?

This isn't just a software problem. The need for clear cycle time tracking was thrown into sharp relief by global supply chain chaos. Post-2020, manufacturers saw their operational cycle times swell as teams spent up to 30% of their time just on coordination and paperwork, killing innovation. Sound familiar?

Why It Matters More Than You Think

Ignoring cycle time means you’re flying blind. You can't give stakeholders reliable estimates, you can't identify process bottlenecks with any real precision, and you definitely can’t make data-driven decisions to improve. You’re left with gut feelings and sprint-by-sprint guesswork.

The goal isn't just to measure how much work gets done, but to understand the flow and speed of that work from start to finish. A healthy, predictable cycle time is the bedrock of a high-performing team.

By focusing on this metric, you shift the conversation from "Are we busy?" to "Are we effective?" It forces a hard look at every single stage of your process, from the first line of code to the final deployment. It’s about building a smoother, faster, and more predictable delivery engine.

The No-Nonsense Way to Calculate Cycle Time

Calculating cycle time shouldn't require a Ph.D. in statistics. The core formula is so simple it’s almost misleading:

Completion Date – Start Date = Cycle Time

Easy, right? But this is exactly where most teams get tripped up. The real work isn't the math; it's getting everyone to agree on what "Start Date" and "Completion Date" actually mean. It's the messy, undefined space between those two points that sabotages the whole effort.

Defining Your Start and End Points

Let's just get this out of the way: if your team can't agree on when work actually begins, your cycle time metric is useless. Seriously. Is it when a PM drops a ticket into the "To Do" column? When an engineer slaps their name on it? Or is it the moment they push their very first commit?

There’s no single right answer here, but there is definitely a wrong one: not having a clear, agreed-upon definition in the first place.

My advice? Work starts the moment an engineer pulls a ticket into an 'In Progress' state. This is a clear signal. It signifies an active commitment to start development, not just think about it.

Likewise, "Done" needs to be totally unambiguous. Is it when the code is merged? Or is it when it's live in production? For most SaaS teams, the only "Done" that truly matters is when the feature is actually in the hands of your customers. Anything less is just a stop along the way.

A truly no-nonsense approach to calculating cycle time demands ruthless consistency. Understanding how to establish clear processes through writing Standard Operating Procedures can dramatically improve your data's reliability and make these definitions stick.

A Practical Example From the Trenches

Let's imagine a small SaaS startup, 'SyncUp,' working on a new calendar integration.

Start Date: An engineer pulls the ticket from 'Ready for Dev' into 'In Progress' on Monday, May 6th, at 10:00 AM.

The work moves along but then hits a snag. It finally moves into 'In Review' on Wednesday, May 8th.

After some feedback and a few more commits, it gets pushed to 'QA' on Friday, May 10th.

Completion Date: The feature is deployed to production, and the ticket is moved to 'Done' on Monday, May 13th, at 4:00 PM.

So, what's the cycle time? We measure the total elapsed calendar days, which comes out to 7 days and 6 hours.

Notice we didn't skip the weekend. Why? Because from the customer's perspective, the work was still "in progress." Your internal process doesn't pause just because your office does; those delays are a real part of the story. This is one of many success metrics that reveals the whole picture, not just the parts that are convenient to measure.

To avoid manual spreadsheet hell, you need to configure your Jira or Asana boards with distinct statuses that mirror your actual workflow. A simple, effective setup looks something like this:

To Do: The prioritized backlog of work.

In Progress: Active development is happening right now.

In Review: The code has been submitted for peer review.

Done: The feature is live and available to users.

With this kind of structure, your project management tools can automatically track the time spent in each active stage. You get the real data you need without the headache.

Finding the Data You Actually Need

The formula for cycle time is simple. The hard part? Getting clean data. Your ticketing system is supposed to be a goldmine, but it's often more of a minefield. If your workflow is a mess of poorly defined statuses, you’re just collecting garbage. And we all know what garbage data leads to.

Let's get practical. You should be spending your time on analysis, not wrestling with administrative tasks. This is where your project management tool becomes either your best friend or your worst enemy.

Taming the Jira Beast

For most of us, that tool is Jira. Instead of manually digging through ticket histories like an archaeologist, you can pull exactly what you need with a well-crafted Jira Query Language (JQL) query.

Here’s a basic JQL query to get you started. This will pull all the tickets from a specific project that hit “Done” in the last 90 days, giving you a solid dataset to work with:

project = "YOUR_PROJECT" AND status = "Done" AND status changed to "Done" during (-90d, now())

Run that query and export the results to a CSV. This file is your raw material. You'll find columns for the ticket key, summary, and—most importantly—the creation and resolution dates. Those timestamps are the bedrock of your calculation.

If you feel like you're constantly fighting Jira, we've got a whole guide on agile project management with Jira that can help make it work for you.

This infographic breaks down the simple flow from when work actually starts to when it’s finally delivered. That entire duration is your cycle time.

The key thing to remember is that the clock starts ticking the moment work begins and doesn't stop until that task is truly complete.

Visualizing the Flow Without the Grunt Work

Manually crunching numbers in a spreadsheet is a path to madness. Sure, it works, but it’s a soul-crushing time-suck you can’t afford. You need to see trends, identify outliers, and get a feel for the health of your process at a glance.

Thankfully, you don’t have to live in spreadsheets forever. Jira has some powerful built-in reporting tools that can do the heavy lifting, as long as you know where to look. One of the most valuable—and criminally underutilized—features for this is the Control Chart.

A Control Chart, like the one below, instantly visualizes the cycle time for every single issue.

This chart gives you the average cycle time (that solid blue line) and the standard deviation, making it incredibly easy to spot the outliers that demand a closer look.

A Control Chart moves you from a static number to a dynamic conversation. It’s not just about what your average cycle time is, but why it fluctuates. See those dots floating high above the average? That's where your biggest process improvement opportunities are hiding.

By using these native tools, you automate the most tedious part of the job. This frees you and your team up to have the more important conversations about what the data is actually telling you.

What to Do When Reality Gets Complicated

Your development process isn't some pristine, linear assembly line, and your cycle time calculations can't pretend it is. The neat little formula of Completion Date - Start Date shatters the second it meets the messy reality of building software.

What happens when a ticket gets stuck for three days waiting on a design decision? Or when that "must-have" feature gets punted to the next sprint? These aren't edge cases; they're just another Tuesday. Ignoring them gives you a vanity metric, not a diagnostic tool.

Handling Blocked Time

So, does that three-day wait for a design approval count towards cycle time?

Yes. Absolutely. It has to.

From the customer's point of view, the work has stalled. The value they're waiting for is stuck in limbo. Hiding this "blocked" time is like ignoring traffic jams when you estimate your commute—it’s just lying to yourself and guarantees you'll be late.

At a startup I advised, the team started tracking blocked time as its own state. They were horrified. It turned out that over 40% of their total cycle time was spent in a "Blocked" column. This wasn't a slow development problem; it was a massive, invisible communication bottleneck between product, design, and engineering that was strangling their delivery speed.

The most valuable insights are hiding in the messiest parts of your process. Don't sweep blocked time under the rug; put a spotlight on it. It’s a giant red flag pointing directly to your biggest constraint.

You can get a handle on this pretty easily in Jira:

Create a "Blocked" status: When a ticket is stuck, drag it into this column. Your Control Chart will instantly visualize just how much time is lost to waiting.

Use flags: Add a "Blocked" flag to tickets. This is a bit less disruptive to your board's flow but still lets you run JQL queries to see the damage.

Dealing with Spillovers and Abandoned Work

Another classic headache is work that bleeds over from one sprint to the next. The ticket was started, but then priorities shifted, and it got pushed. This is usually a symptom of poor planning or good old-fashioned scope creep. Your cycle time calculation for that ticket has to include the entire ride—from its original start date to its eventual finish line, even if that journey spans a month.

And what about tickets that are started and then abandoned entirely? These are tricky. My advice is to create a "Canceled" or "Abandoned" status. While they won't have a completion date, you should still track how much time was torched before someone pulled the plug. This "wasted effort" metric can be just as revealing as cycle time itself.

Your Cycle Time Sucks. Now What?

So you went through all the work of calculating your team's cycle time, and the number staring back at you is… not great. It's depressingly high, and your first instinct might be to panic.

Don't. This isn't a moment for blame. It’s a clear signal that your system has a problem, not your engineers. And the great thing about systems is that they can be fixed. A high cycle time is a process problem, a communication breakdown, or a planning failure. Now that you have the data, you can stop guessing and start targeting the real bottlenecks killing your team’s momentum.

Break Down Your Stories

If a ticket consistently takes two weeks to get across the finish line, that's not a ticket—it's a project disguised as a story. These huge, monolithic tasks are a primary cause of bloated cycle times. They’re nearly impossible to estimate accurately, a nightmare to review, and almost always get bogged down in scope creep.

The fix is deceptively simple: make your tickets smaller. Radically smaller. Each ticket should represent the smallest slice of value that can be shipped on its own. This doesn't just speed up delivery; it gives your team a steady stream of small wins, which does wonders for morale.

Cut Your Work-in-Progress (WIP)

This one feels completely backward at first, but it’s one of the most powerful changes you can make. To get more done, you have to start less. When every engineer is juggling three, four, or even five tasks at once, their focus is shattered. Nothing moves forward efficiently because everyone is drowning in context-switching.

I worked with a fintech startup that cut their cycle time in half—inside a month—by rolling out a strict "two tickets per engineer" WIP limit. The team pushed back hard initially, certain it would slow them down. Instead, it forced them to collaborate. Engineers started pairing up to unblock work and swarming on pull requests to push tasks over the finish line.

High WIP is a traffic jam on your delivery highway. By limiting the number of cars on the road, you allow everything to move faster. It’s not about doing less work; it’s about finishing more work.

Streamline Your Handoffs

Every time a ticket changes hands—from product to design, design to engineering, engineering to QA—you create an opportunity for delay. These handoffs are the hidden friction slowing your whole process down. One of the best ways to smooth these out is with automation. If you're curious about where to start, this guide on What Is DevOps Automation and How Does It Work is a great resource.

And this isn't just a software thing. In manufacturing, smart factories have used AI-driven process optimization to slash cycle times by around 20%. It's proof that a data-driven approach delivers real results.

Ultimately, a high cycle time is a gift. It’s a clear, data-backed mandate to make your processes better. And if you’re looking for more ways to get your team humming, check out our deep dive on how to improve team productivity.

Common Cycle Time Questions, Answered

Alright, you've started calculating the numbers, but this is usually where the real questions start popping up. Let's get into the stuff that trips teams up in the real world—no theory, just practical answers.

What’s a “Good” Cycle Time for a Software Team?

Everyone asks this, and everyone wants a magic number. I'm going to disappoint you: there isn't one.

A "good" cycle time is one that's stable, predictable, and—ideally—getting shorter over time. If you're a startup slinging a new web app, a median cycle time of 3-5 days from 'In Progress' to 'Done' might be a solid target. But that number is completely meaningless for a team working on a complex enterprise system or embedded firmware.

The goal isn't to hit some arbitrary industry benchmark you read in a blog post. It's to figure out your own baseline and relentlessly focus on improving from there.

How Is This Different From Story Points or Velocity?

This is a big one. They measure completely different things, and confusing them is a classic mistake.

Velocity and story points are all about output—how much "stuff" your team gets through in a sprint. Cycle time measures speed and flow. It tells you how fast a single piece of work moves from start to finish.

You can have a massive velocity number but a god-awful cycle time. How? By starting a ton of large tickets and working on them all at once. Many forward-thinking teams are ditching velocity altogether because focusing on cycle time actually forces you to improve predictability. Chasing velocity points often just leads to inflated estimates and rushed, sloppy work.

Don't mistake activity for progress. A team can burn through a mountain of story points and still take an eternity to deliver a single valuable thing to a customer. Cycle time cuts through that noise and tells you how fast you're actually shipping.

Do We Include Code Review and QA in the Calculation?

Yes. Full stop. Absolutely.

There’s no debate here. Your cycle time must measure the entire journey, from the moment a developer starts coding until that feature is in the hands of a customer or is 100% shippable.

If your team's definition of "Done" includes code review, QA, and deployment, then all that time has to be in the calculation. If you exclude these stages, you’re just lying to yourself with vanity metrics. Worse, you're hiding the very bottlenecks in your process—like a ticket sitting in "Ready for QA" for three days—that are probably causing the most pain.

Ready to stop wrestling with spreadsheets and start getting real-time insights into your team's cycle time? Momentum unifies your standups, sprint planning, and Jira data into a single, streamlined view. See your team’s flow, identify bottlenecks, and build a more predictable delivery engine. Get started for free.