Zombie Work Detector: Finding Tickets That Move But Don’t Progress (+Meet New Rovo Agent)

[#1]

Busy boards. Moving cards. No outcomes. If that sounds familiar, you’re looking at zombie work—tickets that shuffle between steps without actually getting closer to “Done.”

This guide presents a calm, low-friction approach to identifying and reducing zombie work using the Time in Status app for Jira and its new Rovo Agent FlagFocus. You’ll see where flagged time piles up, which statuses create drag, who’s actually waiting, and what to fix first—all with built-in reports. No spreadsheets, no exports.

What we mean by “zombie work”

Zombie work is any issue that looks active (changes owner or bounces between statuses) but is functionally blocked. These items often get Flagged, wobble between In Progress ↔ Review ↔ Waiting, and quietly age out of sprints.

Why it matters: zombie work soaks up capacity, distorts burndown, and makes cycle/lead time look worse than team reality. The cure starts by making blocked time visible—where it lives, how long it lasts, and what loop causes it.

Meet FlagFocus (Rovo Agent for Time in Status)

FlagFocus by Time in Status turns flagged intervals into clear, defensible signals. (Before you start, make sure you have installed the Time in Status by SaaSJet app, as Rovo agent is part of its functionality.) You provide a JQL filter and a time window; the agent reads each issue’s history and returns two compact tables:

Outputs

• Flagged Overview: Period • Filter • Total Flagged Time • Issue Count
• Flagged Time by Status: Total Flagged Time plus a per-status breakdown and % share

Why it’s useful

• Triage faster: Escalate the status with the most flagged time (e.g., Waiting on Vendor).
• Fix root causes: Tighten Definition of Ready, approvals, or handoff rules where spikes appear.
• Prioritize unblockers: Sort by longest-flagged issues and clear the path first.
  
  

How to open the agent

1. In Jira, go to Chats.
2. Search “Rovo Agent FlagFocus.”
3. Open the agent and use a starter prompt or paste your own JQL + period (e.g., “last 30 days”).
   Tip: start with “Tell me about yourself.”

Good starting scopes 

Team board, last 30 days
project = ABC AND statusCategory != Done AND Flagged is not EMPTY

This sprint
sprint in openSprints() AND Flagged is not EMPTY

Service/JSM waiting
project = JSM AND Flagged is not EMPTY AND status in ("Waiting for Customer","Waiting on Vendor")

Keep the same window each week so your trend stays honest.

The full detector: how the app completes the picture

FlagFocus shows where blocked time accumulates. The built-in reports of the Time in Status app for Jira explain why and how to reduce it, all without leaving Jira. Below are focused “detectors” with the exact reports to open, what to look for, and minor, reversible fixes.

Detector 1 — “Stuck in Review” loop

Open:

• Time in Status report (duration in In Review / QA Review)
• Status Count report (how many times items re-entered Review)
• (Optional) Transition Count report to confirm In Progress ↔ Review ping-pong
  
  

Signals: Review owns a large share of Time by Status; Review duration high; many items show Status Count > 1 in Review.

Small fixes: Split overloaded Review into Code Review and QA Review; require a PR to enter Code Review; nudge a status change on handoff (assignee change → move to next step).

Prove change: Review duration falls in Time in Status. (If you like a single glance, the Average Time report for Review helps.)

Detector 2 — “Waiting black hole”

Open:

• Time in Status report for Waiting for Customer/Vendor
• Time in Status per Date report to see waiting trend by week
  
  

Signals: Waiting spikes on certain weeks.

Small fixes: Make Waiting states explicit and ensure SLAs pause; add reply-based automations to bounce back to working; publish response expectations for vendors/customers.

Prove change: Waiting duration trends down.

Detector 3 — “Handoff hell” (ownership changes without status clarity)

Open:

• Assignee Time report (who actually “held” the issue)
• Status Entrance Date report (late returns to earlier steps)
• Status Count / Transition Count (frequent backsteps)
  
  

Signals: Many assignee changes while flagged; Review → In Progress backsteps; silent handoffs (owner changes but status doesn’t).

Small fixes: Require a status change on handoff; add “Definition of Done for Review” so work doesn’t bounce back.

Prove change: Fewer backsteps; shorter Assignee Time while flagged.

Detector 4 — “On Hold inflation” (Done that isn’t done)

Open:

• Time in Status report for On Hold (and Done, if reopen loops are common)
• Status Entrance Date report to verify Done only after dependencies clear

Signals: On Hold grows; items enter Done and later re-open; long On Hold on a few issues in FlagFocus’s “longest-flagged” list.

Small fixes: Guard Done (block Done if dependencies are open; route to On Hold); add a “dependency resolved” check before moving to Done.

Prove change: On Hold duration decreases; fewer reopen loops.

Detector 5 — “Design/Approval bottleneck”

Open:

• Time in Status report for Designers Review (or your approval step)
• Status Count report for re-entries into the approval step
• Sprint Report to see Completion Rate stabilize after fixes

Signals: Approval step has high flagged share; multiple re-entries into that step; completion feels lumpy across sprints.

Small fixes: Definition of Ready for design/approval (assets attached, acceptance clarified); time-boxed reviews; clear SLAs for internal approvers.

Prove change: Approval duration falls; Completion Rate steadies in Sprint Report.

The core reports at a glance (and when to use them)

• Time in Status report — where the time actually accumulates (by status).
• Assignee Time report — who’s truly “holding” the issue during blocked intervals.
• Average Time report — a quick roll-up for a specific step (e.g., Review) if a single number helps.
• Status Count report — shows re-entries (great for spotting loops without complex math).
• Transition Count report — confirms A↔B ping-pong (e.g., In Progress ↔ Review).
• Status Entrance Date report — catches late backsteps and validates that Done is final.
• Time in Status per Date report — shows durations trending week over week after you change a rule.
• Sprint Report — end-to-end sprint health (Velocity, Workload by Assignee, Completion Rate, Committed vs Completed, Scope Change).

FAQs (the pragmatic answers)

Should “Waiting” count against teams?
Treat it as neutral visibility. If SLAs pause, don’t weaponize it—use the Waiting share to negotiate response windows or improve customer comms.

What if Review is always #1?
It’s doing too many jobs. Split Code Review vs QA Review, require a PR to enter Code Review, and recheck next week.

How small is “small” for a fix?
If you can’t roll it back in one click (disable a validator/automation), it’s too big for the first pass.

Try it this week

• Open Chats → Rovo Agent FlagFocus and run it for last 30 days on your team filter.
• Take the top status from the breakdown and open Time in Status for that step.
• Make one reversible change.
• Re-run next week; share a one-liner before/after.

When zombie work is visible, it’s solvable. The Time in Status app for Jira—plus FlagFocus—gives you the shortest route from “we feel blocked” to “we know exactly where to loosen the knot,” and the rest of the reports help you lock in the win.

Book a demo