A 3-minute read on two drifts in your flow numbers — both rooted in the same architectural shortcut, both fixable. Extracted from the foundational mechanism map at your-time-in-status-plugin-is-lying-to-you.
A pattern I've watched in many teams across many years: a routine workday produces routine ticket transitions. Someone clicks the wrong button by mistake; somebody else corrects it. Someone flags a ticket "Blocked" for nine minutes to signal "hold on, let me check something." Someone ping-pongs a ticket between Reviewer and Author during a fast PR round. Nothing unusual. Nothing anyone would write down.
And then the next retrospective starts from cycle-time numbers, and the numbers report the wrong-click windows as legitimate "in progress" time, and the nine-minute Blocked interval as zero, and the back-and-forth review transitions as one single In Review duration that doesn't match what anyone remembers happening. The team's investigation of "what's slowing us down?" runs against a distorted distribution of status durations — and the distortion is invisible because the dashboard renders without complaint.
The root cause for both drifts is the same: the plugin reads only current_status plus a "last changed" timestamp. It doesn't read the changelog. Every intermediate state, every reversal, every fast-succession status flip — invisible to the plugin, visible to anyone who looks at the issue's History panel.
Two 60-second checks — run either against your own data
60-second check
For wrong-click drift
Find any ticket whose History panel shows a transition reversal — Done → In Progress → Done, or In Review → To Do → In Review, or similar. They exist in every project; check the last 60 days. Compare your plugin's cycle-time for that ticket against manual arithmetic that ignores the reversed-and-corrected window. If they differ by more than 5%, the plugin reads "last changed" not the changelog, and your project's cycle-time P50 and P95 are contaminated by mistaken-transition windows the plugin treated as real time-in-status.
60-second check
For quick-toggle drift
Find any ticket that briefly passed through an intermediate status — a "Blocked" interval of less than an hour, a quick flag-and-unflag, a quick reassignment loop. Check your plugin's time-in-"Blocked" (or whatever the brief status was) against the changelog interval. If the plugin shows zero or only the most recent occurrence, your project's time-in-that-status aggregate is under-attributed by 20–40% — and every retrospective debating "how much time do we lose to being Blocked?" has been working from numbers smaller than reality.
If either check surfaces drift, here's why.
Drift 1: Manual ticket edits — the wrong-click problem
A ticket bounces from "Done" back to "In Progress" by mistake. An admin reverts it four hours later. A plugin reading only current_status and a "last changed" timestamp sees the ticket as "In Progress" for that four-hour window and attributes those four hours to the ticket's cycle time. The changelog shows the bounce, the revert, and the correct durations. The plugin doesn't read the changelog.
The skew is biased toward inflation, not deflation. Wrong-clicks add time to a ticket's reported cycle; corrections don't subtract it. For a team running 100 tickets a week, a handful of these per month meaningfully skews the P50 and P95.
The pattern is more common than people think. Jira's transition UI is easy to misclick — adjacent transitions on the same dropdown, hover-state targeting on touch devices, accidental keyboard shortcuts in the issue view. In any project with daily activity, wrong-click reversals happen every few weeks. Most teams never know it; the plugin reports the inflated number, the dashboard shows the inflated trend, the throughput conversation in retrospective starts from contaminated math.
The fix isn't sophisticated. Read the changelog. Replay every transition. Compute durations from the resulting (status, entered, exited) triples, not from the difference between created_at and updated_at. A plugin reading the changelog sees the wrong-click as exactly what it was — a four-hour spike into the wrong status, followed by a correction back to the right one — and attributes time accurately. The interval before the wrong-click stays counted against "Done"; the four wrong hours get counted against "In Progress" because that's where the ticket actually was; the interval after the correction stays counted against "Done" again. No contamination across boundaries.
Drift 2: Multiple transitions in fast succession — the quick-toggle problem
A ticket gets transitioned from "To Do" → "In Progress" → "Blocked" → "In Progress" in the same 30-minute window. A plugin reading only current_status and "last changed" sees: started in "To Do" 30 minutes ago, currently in "In Progress." Where's the "Blocked" interval? It existed for nine minutes but never gets counted.
This isn't a rare event. Teams that use Blocked status as a soft "I need a quick consultation" marker, teams that flag-and-unflag tickets to signal review-required-then-cleared, teams that ping-pong tickets between Reviewer and Author during PR rounds — all generate fast-succession transitions constantly. The plugin sees only the start state and the current state, and every intermediate signal disappears.
Cumulative effect: status-toggle patterns popular with teams that use Blocked as a flag mechanism get under-attributed in time-in-status reports by 20–40%. That's not a rounding error. That's the difference between "Blocked is averaging 8% of our cycle time" (the real number) and "Blocked is averaging 5% of our cycle time" (what the plugin reports). When the action item from retrospective is "reduce time spent Blocked," the team is chasing a smaller target than they actually have.
The fix is the same as the wrong-click drift: read the changelog. Every transition becomes a slice. A nine-minute "Blocked" interval gets nine minutes counted against "Blocked," not absorbed into a neighbor. The reasoning is identical; the architectural commitment is identical.
Why both matter — the compression is biased
Both drifts share the same root cause — the plugin reads "last changed" instead of the full changelog — and the same operational consequence: the plugin's view of your project's state is a lossy compression of the truth. Every intermediate transition that happened between two snapshots is invisible.
The compression bias isn't symmetric, either. It under-counts time spent in brief statuses (fast-succession transitions disappear) and over-counts time spent in the resolved status (wrong-click windows get attributed to the wrong interval). Net effect: your team's cycle-time numbers look worse than reality on the "we're slow" axis, AND your investigation of "what's slowing us down" looks at a distorted distribution of status durations.
This is hard to spot from inside the dashboard because the numbers look reasonable. You catch it only by comparing the plugin's per-ticket view against the issue's History panel — and most engineers don't, because they assume the plugin reads the same source they would.
The plugin I built handles both
I built BottleneckIQ because the only way to stop wrong-clicks and quick-toggles from distorting flow numbers is to read the changelog as the source of truth — every transition, every duration, computed deterministically from Jira's append-only history.
Every metric derives from the Jira issue changelog directly. Re-running the sync produces identical row counts and values — same data in, same answer out, every time. Wrong-click reversals show up as exactly what they are; brief "Blocked" intervals get counted at their actual durations. There's nowhere in the architecture where "last changed" substitutes for replay.
30-day free trial. From $10/month for teams up to 10 users, $3/user beyond. One-click install on any Jira Cloud project.
This is one of three articles on drift mechanisms in Jira flow analytics. Edit-and-toggle drift is what's here. The other two drift families:
- Business-context drift — weekends, holidays, and external waits counted as the team's cycle time.
- Workflow drift — status renames and workflow restructures distorting historical comparisons across configuration changes.
The full six-mechanism map and the architectural alternative live in the foundational post. If you'd rather skip the reading and try the plugin against your own data, the install is one click from the Marketplace link above.
If either of the 60-second checks above surfaced drift in your numbers, I'd be glad to hear what you found — francisco@bottleneckiq.com.