Why Mixing Bugs, Features, and Requests in One Cycle Time Metric Breaks Your Planning

[#1]

Picture a team reviewing its cycle time report during a retrospective.

The average cycle time is around eight days. The trend looks stable. The dashboard is neat enough to make everyone feel slightly more organized than they were before the meeting.

At first glance, everything seems fine.

Then someone asks: "Eight days for what exactly?" That’s where the metric starts to wobble.

In many Jira projects, production bugs, customer requests, new features, technical debt, and operational tasks all end up in the same cycle time report. The number looks precise, but it represents work that moves through the system in very different ways.

A bug might be resolved in a few hours because it blocks customers. A feature may need discovery, development, testing, review, and stakeholder approval. A customer request might spend half its life waiting for feedback from someone outside the team.

When all of that is averaged into a single number, the result can be misleading. It may still be mathematically correct, but it becomes much less useful for planning.

That’s why teams can look at a stable cycle time trend and still struggle with missed forecasts, unpredictable sprint commitments, and stakeholders asking why delivery feels slower than the dashboard suggests.

The issue isn’t cycle time itself. The issue is that bugs, features, and requests are measured as if they all follow the same path through a workflow.

The Hidden Problem with "Average Cycle Time"

Imagine your team completed the following work last month:

Work Type	Average Cycle Time
Production Bugs	2 days
Customer Requests	7 days
Features	18 days

Now combine them into a single report. Congratulations. Your average cycle time is roughly 9 days.

Unfortunately, nobody can actually use that number.

If a customer reports a critical bug, nine days sounds terrifying.

If Product wants a new feature delivered, nine days sounds unrealistically optimistic.

If leadership asks for forecasting data, the answer inevitably becomes: "Well... it depends."

And when every planning conversation starts with "it depends," your metric has already stopped being useful.

Here's What the Same Data Looks Like Visually

Many teams only see the blended trend. Unfortunately, the blended trend can hide completely different realities underneath.

Blended Cycle Time Trend

Looking only at this chart, you might conclude that everything is running smoothly.

Now let's look at what was actually happening underneath.

Month	Bugs	Requests	Features
Jan	2d	6d	19d
Feb	2d	7d	17d
Mar	1d	8d	18d
Apr	2d	9d	15d
May	1d	10d	16d
Jun	1d	11d	14d

The blended metric tells one story:

"Nothing really changed."

Reality tells three different stories:

• Bug resolution improved significantly.
• Feature delivery became faster.
• Customer requests became slower.

Three important trends. One average completely hid all of them. That's why planning based on blended cycle time is like driving with fogged-up glasses. You're moving forward, but you're missing most of what's happening around you.

Different Types of Work Behave Differently

The reason this happens is simple: different types of work naturally move through Jira differently.

Bugs Move Through the System Differently

Think about the last production incident your team handled. Nobody organized a discovery workshop. Nobody debated roadmap priorities. Nobody scheduled a stakeholder alignment session. The goal was simple: fix the problem. Bugs are usually urgent, relatively well-defined, and often skip queues that would slow down planned work. As a result, they tend to move through the workflow much faster than features or requests do.

Features Follow a Different Path

Now compare that with a feature. Before a feature reaches Done, it may pass through discovery, design reviews, technical discussions, stakeholder approvals, QA cycles, and scope changes. Even highly efficient teams expect features to spend more time in progress because they're solving larger and less-defined problems.

Requests Often Spend Time Waiting

Requests introduce another challenge.

Many requests spend significant time waiting:

• Waiting for customer feedback
• Waiting for approvals
• Waiting for procurement
• Waiting for legal review
• Waiting for another team

In some organizations, nobody actively works on a request for most of its lifecycle. And that's perfectly normal. The problem appears when all three work types get squeezed into the same metric. Mixing them together is a bit like comparing emergency room visits with annual health checkups. Both belong to healthcare. Neither follows the same timeline.

Even Atlassian's Flow Metrics Philosophy Points in This Direction

If you've spent time exploring flow metrics, you'll notice a recurring theme:

Metrics become useful when you're measuring similar types of work.

Cycle time isn't designed to answer:

"How long does everything take?"

It's designed to answer:

"How long does this type of work usually take?"

Imagine combining:

• a 30-minute production fix,
• a two-week feature,
• a month-long compliance initiative,
• and a customer request that took five days to get approved.

Averaging them together may produce a number. It won't produce insight. That's why mature teams separate flow metrics by class of work. Not because it's more sophisticated. Because it's more useful.

How Jira Already Gives You Everything You Need

Fortunately, solving this problem doesn't require rebuilding your Jira setup, introducing a new workflow, or investing months into a reporting project.

Most teams already have the data they need.

Jira knows which issues are bugs, stories, requests, incidents, tasks, and epics. The challenge isn't collecting more information. The challenge is organizing it in a way that reflects how different types of work actually behave.

Option 1: Use Work Item Types

The simplest approach is to calculate cycle time separately for work item types.

For example:

• Bugs
• Stories
• Tasks
• Service Requests
• Change Requests
• Epics

Instead of discussing one average cycle time, compare how each category behaves independently. Suddenly, forecasting becomes much more realistic.

Instead of saying:

Average Cycle Time = 9 Days

You can say:

• Bugs = 2 Days
• Requests = 7 Days
• Features = 18 Days

That's the kind of information stakeholders can actually use.

Option 2: Use Components or Labels

Many organizations have delivery streams that aren't captured by issue types alone.

Examples include:

• Customer Escalations
• Internal Improvements
• Technical Debt
• Security Work
• Regulatory Requests

Components and labels can help create more meaningful planning categories.

Option 3: Create Classes of Service

Teams using Kanban often classify work based on delivery expectations.

Examples include:

• Expedite
• Standard
• Fixed Date
• Intangible

This approach helps reveal why certain types of work constantly disrupt planning and consume capacity.

The Real Challenge: Keeping Metrics Consistent

Separating work is the easy part. Keeping those measurements consistent over time is where things become difficult.

If you've ever rebuilt the same Jira report three months in a row, you know exactly what happens next. Definitions start drifting. Different teams calculate cycle time differently. Stakeholders request new filters. Dashboard numbers stop matching retrospective reports. Eventually, someone exports everything to Excel and promises they'll clean it up later. 

(We all know how that story ends.)

This is exactly the kind of challenge specialized reporting apps are designed to solve.

Measuring Classes of Work with Time in Status

One approach many Jira teams use is Time in Status by SaaSJet, which transforms Jira issue history into actionable flow metrics and time-based reporting. Instead of treating every issue as identical, teams can analyze work by issue type, status group, project, sprint, assignee, label, component, or any Jira filter.

The real advantage isn't just seeing cycle time. It's creating consistent definitions that teams can reuse over time.

For example:

• Bugs
• Features
• Customer Requests
• Technical Debt

Each can each have their own historical baseline, making sprint planning and forecasting significantly more reliable.

And planning based on historical evidence tends to work much better than planning based on optimism.

(Optimism is wonderful for relationships. Less so for delivery forecasting.)

Features That Help

Report Summary

Report Summary provides high-level metrics that help answer questions such as:

• How long does work actually take?
• Which category is slowing delivery?
• Are we improving over time?

Advanced Filtering

Column Filters help you narrow results directly inside the table — without changing the report configuration or creating additional Jira filters.

You can use filters to:

• focus on specific statuses
• find items that exceed SLA or cycle time targets
• identify long-running tasks
• review work completed during a specific period
• isolate empty or missing values

Status Groups

Status Groups allow teams to combine statuses into categories such as:

• Working
• Waiting
• Review
• Approval

This often reveals that delays are caused by waiting rather than execution. Time in Status supports predefined and custom Status Groups for exactly this reason.

Dashboard Gadgets

Instead of rebuilding reports before every meeting, teams can publish reports directly to Jira dashboards and share live metrics with stakeholders. All reports can be added as dashboard gadgets.

Real-World Examples

Engineering Teams

One engineering team noticed that their overall cycle time looked healthy.

After separating bugs from features, they discovered that features were spending excessive time in Code Review and QA.

By tracking cycle time per status and identifying Dev ↔ QA rework loops, they reduced cycle time by 25% and significantly reduced rework.

The metric wasn't wrong.

It was simply hiding the real problem.

IT Support Teams

Support teams often mix:

• Incidents
• Service Requests
• Customer Follow-ups

into a single reporting bucket.

Separating working time from customer waiting time helped reveal the true bottlenecks, reduce SLA breaches, and improve resolution speed.

Product Teams

Product organizations frequently measure all roadmap items together.

When teams started tracking review and decision time separately, they identified aging ideas and approval bottlenecks, leading to faster decision-making and fewer stale initiatives.

Leadership Reporting

Executives rarely need prettier dashboards.

They need answers to questions like:

• Are features becoming slower?
• Are bugs being resolved faster?
• Which teams spend the most time waiting?
• Is planning becoming more predictable?

Those answers come from segmented metrics, not blended ones.

Key Takeaways

If you remember only five things from this article, make them these:

✅ A single cycle time metric rarely tells the full story.

✅ Bugs, features, and requests behave differently and should be measured separately.

✅ Jira already contains the information needed to classify work.

✅ Planning improves when forecasts use historical baselines for each class of work.

✅ The most valuable reports aren't the ones with the prettiest charts—they're the ones that help teams make better decisions.

The next time someone proudly announces:

"Our average cycle time is 8.4 days."

Try asking:

"For bugs, features, or requests?"

The answer may reveal more than the metric itself.

Over to You

How does your team classify work when measuring cycle time?

Do you track separate metrics for bugs, features, requests, technical debt, or operational work?

Or are you still using one blended cycle-time number for everything?

I'd love to hear what's working (or not working) in your Jira reporting approach.