Finding the Real SDLC Bottlenecks in Healthcare Software Delivery

[#1]

A release can take longer than expected, even when development and QA appear to be progressing smoothly. Additional time often accumulates between key stages — in review queues, during testing, verification, integration, or simply while waiting for release.

In the healthcare industry, where the delivery process may also include stages related to compliance, quality, risk management, and regulatory requirements, a single overall cycle time metric can hide where delays are actually happening.

Start with the workflow behind the cycle time

Before trying to reduce cycle time, first look at where that time is actually being spent.

A Jira workflow might look like this:

Development → Code Review → Awaiting QA → QA → Testing → Verification → Ready for Release

In regulated products, some of these stages carry more than engineering weight — Verification, for instance, often maps to a formal activity the team has to complete, not just a QA pass. 

The exact status names will vary from team to team, but the principle doesn't: cycle time shows how long it takes to complete work across the workflow. What it doesn’t show is which stage contributes the most to that time.

For example, the average cycle time for a release might be around 11 days. But when you break it down by status, the picture can look very different:

At first glance, “Development” appears to be the longest active stage. However, the breakdown shows that work spends another three days in “Awaiting QA” and two days in “Ready for Release.” This means a significant portion of the total cycle time is spent outside the actual development and testing stages.

This is where the Time in Status report becomes useful. It shows how long each Jira work item spent in each stage of the workflow during the selected period. Instead of relying only on the overall Cycle Time metric, you can see what is happening at each stage behind that number.

The goal is not to automatically consider the longest status as the “bottleneck.” Instead, this division helps focus the analysis: where exactly is the most time being spent and which stages need to be studied in more detail?

Separate active work from waiting

This distinction is especially useful when your Jira workflow clearly separates active work from waiting stages.

QA and Awaiting QA, for example, tell two different stories.

If a work item spends three days in Awaiting QA but only seven hours in QA, treating the whole period as “QA takes almost four days” would hide the more useful signal.

The next question is no longer whether testing itself is slow. It is why work spends considerably more time before QA than inside it.

The cause might relate to capacity, handoffs, work in progress, ownership — or, in regulated workflows, a queue behind a reviewer who isn't on the engineering team at all, such as QA sign-off, a clinical reviewer, or a compliance approval. 

Time in Status app by SaaSJet lets you create status groups and separate active work from waiting time, so you can compare how much of that duration is waiting versus active work. 

There is one important limitation here: the distinction has to exist in the Jira workflow. If waiting and active QA are both represented by the same QA status, the status history cannot tell you how much of that interval was waiting and how much was active testing.

Make sure you are measuring the right time

This matters more than it might seem in regulated delivery, where a review or approval step often depends on someone outside the engineering team's own calendar — a compliance reviewer working standard business hours, for example, while the engineering team runs shifts or operates across time zones. Without adjusting for that, a queue that's actually waiting on business-hours availability can look identical to one that's genuinely stuck. 

Time in Status app includes Work Schedules, where you can configure working days, working hours, breaks, holidays, and timezone. The app then calculates status duration according to the selected schedule.

That can be useful when, for example, you want to compare queues using business time rather than 24/7 elapsed time, or when teams operate on different schedules or in different time zones.

It is not a measure of how many hours somebody was actively working on the work item. It simply lets you choose the time basis that matches the process you are analyzing.

In regulated software, long does not automatically mean inefficient

For MedTech teams, status duration needs additional context.

IEC 62304 defines lifecycle requirements for the development and maintenance of medical-device software. ISO 13485 addresses quality-management systems for medical devices. ISO 14971 covers risk management for medical devices, including software as a medical device (SaMD). These standards define processes and requirements; they do not prescribe a particular Jira workflow or Jira status names.

That is why a long Verification, Review, or approval-related status should not automatically be treated as waste.

If the actual workflow distinguishes:

Awaiting Verification → Verification

then Time in Status app can measure both states separately. The team can then ask a much more useful question: is the duration coming from the controlled activity itself, or is additional time accumulating before that activity begins?

The same approach can be applied to design review, quality approval, risk, change control, or release readiness steps when those processes are represented in Jira.

In a regulated environment, the objective is not simply to shorten every stage. It is to understand whether the time recorded in that stage matches the process the team expects.

Integration work can show a different delivery pattern

Teams building healthcare interoperability products — FHIR APIs, HL7 interfaces, EHR integrations — often see integration-related work reported as slower than the rest of the codebase. Before treating that as an execution problem, it's worth checking why.

Integration work depends on external systems, partner environments, and third-party schedules the team doesn't control. That dependency shows up as time in status whether or not anything is actually wrong on the team's side — which means comparing it directly against standard feature work, in one blended average, will make it look inefficient by default.

Instead of assuming integration work is slower, compare it with the rest of the product. If Testing or Verification stands out, check whether the pattern appears across all work items or only in a particular project, work type, release, or other Jira category.

This is where status-level analysis becomes more useful than a project-wide cycle-time average: it reduces a broad "integrations take too long" problem to a specific stage and a specific set of work that can be investigated.

Also look for rework, not only long statuses

Some SDLC problems are difficult to spot from duration alone.

Consider a work item moving through:

Development → QA → Development → QA

Each individual visit to QA may be short, but repeated movement through the same part of the workflow still adds to the overall delivery time.

Time in Status includes two reports that are useful here. Status Count shows how many times a work item entered a particular status, while Transition Count shows how many times it moved between specific workflow statuses.

That lets you distinguish between two patterns that may initially look similar.

One work item may spend a long time waiting before QA. Another may repeatedly move from QA back to Development.

Both can extend cycle time, but they point to different problems.

Do not stop the analysis when development is “done”

The final stages before release are easy to overlook.

If the workflow contains Ready for Release, Pending Release, or another pre-release state, include it in the analysis.

A work item may already have passed Development, QA, Testing, and Verification but still accumulate additional time before reaching the end of the delivery workflow.

If that stage consistently represents a meaningful share of cycle time, the next investigation should focus on the process between technical completion and release rather than trying to make Development faster.

Again, Time in Status gives you the duration. The team determines what that duration means.

Put the whole diagnosis together

For one recent project, sprint, release, or another meaningful Jira scope, work through the data in this order:

1. Time in Status — see where the overall time is accumulating.
2. Work Schedule — decide whether you need elapsed time or duration based on the team's working calendar.
3. Average Time — check whether the pattern is common across the selected scope.
4. Narrow or group the data — compare relevant scopes with filters/JQL, or use Row Grouping or Pivot Mode with a supported report to analyze work-item data by Jira fields.
5. Status Count and Transition Count — check whether repeated movement and rework are contributing to the delay.

These are all reporting capabilities available in Time in Status by SaaSJet.

The goal is to move beyond:

Our average cycle time is 12 days.

and understand what those 12 days are made of.

Maybe Development is the longest stage, and that is expected.

Maybe QA itself is fast, but work waits several business days before QA begins.

Maybe Verification duration looks reasonable on its own, but work keeps returning to it — a pattern that's easy to miss in a regulated workflow where a long Verification stage already looks unremarkable. 

Maybe development and testing are complete while work continues to accumulate before release.

Those are very different delivery problems, and they require different decisions.

Try Time in Status by SaaSJet on the Atlassian Marketplace and discover the real bottlenecks in your healthcare software.

Disclosure: I'm part of the SaaSJet team.