Why "In Review" Has Been Sitting There for Three Sprints

There is a ticket in your sprint board that has been sitting in "In Review" for eleven days. The sprint ends in two. You have asked about it at standup twice. Both times, the engineer said it was being reviewed. You did not follow up because that is a reasonable status for a ticket in a column called "In Review." But the sprint is failing and this ticket is on the critical path, and nobody told you until today.

The problem is not the engineer and it is not the reviewer. The problem is that "In Review" is a single status label covering at least five different real-world situations — and the sprint board cannot tell you which one you are in.

Five things "In Review" actually means

When a ticket sits in the "In Review" column, the Jira status tells you one fact: that the engineer moved it there. It does not tell you whether a PR exists, whether the PR has been looked at, whether the PR has conflicts, or whether the engineer is even still engaged with it.

What "In Review" actually means — the five real states hiding behind one status:

  State 1: A PR is open, reviewer is active, things are moving
  -> This is what "In Review" is supposed to mean.
  -> Estimated frequency: less than half the time.

  State 2: A PR is open, but the reviewer has not looked at it
  -> Common cause: reviewer is in crunch, is out sick, or was
     auto-assigned and hasn't noticed.
  -> Days lost before anyone raises it: 3–5.

  State 3: A PR is open but has merge conflicts that block review
  -> Engineer may not have checked back on the PR since pushing it.
  -> Status in Jira: unchanged.

  State 4: No PR exists — the engineer moved the ticket to "In Review"
     manually or prematurely
  -> Sometimes done to show progress. Sometimes by accident.
  -> The ticket is not actually in review by anyone.

  State 5: The PR was reviewed, changes were requested, and the engineer
     has not yet addressed them
  -> Engineer moved on to another task. PR is technically "waiting on author."
  -> Status in Jira: still says "In Review."

Each of these states calls for a different response. A reviewer who has not looked at an open PR needs to be nudged or reassigned. A PR with merge conflicts needs the engineer to return to it. A ticket with no PR at all needs a conversation about where the work actually stands. A PR waiting on the author to address review comments is a different kind of stall than a PR waiting on the reviewer to show up. The Jira status is the same for all of them.

Why standup never surfaces the stale ones

Standup is designed around what people are working on right now. A ticket that moved to "In Review" four days ago and has since stalled is not what anyone is working on right now — so it does not come up. The engineer who pushed the PR has moved on to the next ticket. The reviewer who hasn't looked at it is busy with their own work. Nobody is carrying the responsibility to track that this specific PR has gone cold.

Why standup doesn't surface stale review tickets:

  Day 1 — ticket moves to "In Review"
  -> Engineer says: "I've got a PR up, waiting on review."
  -> Scrum master notes it. No action needed yet.

  Day 3 — same status, same answer
  -> Engineer says: "Still waiting on review."
  -> Sounds normal. Nobody escalates.

  Day 5 — same status
  -> Engineer is now working on something else. Ticket stays "In Review."
  -> Standup question: "Anything blocking you?" Answer: "No, I moved on."
  -> The stale ticket is not blocking the engineer right now.
  -> It is blocking the sprint. Nobody connects these two facts.

  Day 10 — sprint review
  -> Three tickets in "In Review." None are done.
  -> Post-mortem question: "Why didn't this come up earlier?"
  -> Because at no point was it anyone's explicit job to check.

The scrum master's standard intervention — "is anything blocking you?" — is technically answered correctly when the engineer says no. They are not blocked. They are working on something else. The stale ticket is blocking the sprint. The engineer does not feel that distinction because they are not waiting on the stale ticket to continue their current work.

This is why blockers that don't get raised at standup still kill sprints. The mechanism is not that engineers are hiding information — it is that the information lives in a system state, not in anyone's head.

What the scrum master actually needs to know

For every ticket in "In Review," a scrum master needs to know four things: Is there a linked PR? If yes, has anyone looked at it recently? If yes, is it blocked by conflicts or waiting on a response? And regardless of all of that — how long has this ticket been in this state relative to its original estimate?

None of these answers are in Jira. They are distributed across GitHub PR state, CI status, and the ticket's own history. Getting them today requires either an engineer to look it up or access to GitHub — neither of which is realistically available to a scrum master on a ten-person team who is trying to do a midpoint sprint health check without interrupting three ongoing standups to chase down answers.

This is the same pattern as the data staleness problem in sprint planning — the sprint board reflects what people said, not what the system shows. By the time the gap becomes visible, the sprint is already compromised.

How Kognita closes the gap

Kognita's Jira MCP integration connects ticket state to the code and PR activity behind it. A scrum master can ask in plain language — no GitHub access, no reading code, no understanding of branch names or CI pipelines — and get answers grounded in what the system actually shows.

What a scrum master can ask Kognita + Jira MCP:

  "Which tickets have been in 'In Review' for more than 3 days?"
  -> Returns: 4 tickets, with age, assignee, and linked PR state

  "Do any of those tickets have a linked PR?"
  -> Returns: 2 have PRs, 2 do not

  "For the ones with PRs — are those PRs stale or blocked?"
  -> Returns: PR #841 has had no reviewer activity in 6 days.
              PR #857 has merge conflicts flagged by CI.

  "For the ones without PRs — what's the last activity on those tickets?"
  -> Returns: Last comment on PROJ-214: 4 days ago.
              Last status change on PROJ-219: moved by the engineer 7 days ago.

  "Which of these four tickets are on the critical path for other sprint work?"
  -> Returns: PROJ-214 is a dependency for PROJ-231 and PROJ-238,
              both of which are not yet started.

The answers are not inferred from standup or ticket comments. They reflect the actual state of the PR: whether a reviewer has been assigned, whether the reviewer has opened the PR, whether CI is passing, whether there are unresolved conflicts. A scrum master who can surface this on day five of a ten-day sprint can intervene — reassign the reviewer, prompt the engineer to return to address comments, flag the missing PR — before any of these stalls become sprint failures.

What a full "In Review" audit looks like at sprint midpoint

The most useful point to run this check is at the midpoint of the sprint — not at sprint review, when it is too late to do anything, and not at daily standup, where the signal is too noisy to catch systematic patterns. At the midpoint, there is still time to intervene on most stalls if you can see them.

Sprint "In Review" audit — Day 8 of 10:

  Tickets in "In Review": 5

  PROJ-201  Age: 2 days  PR: open, reviewer assigned, last activity yesterday
  -> Status: normal, monitoring

  PROJ-214  Age: 7 days  PR: open, no reviewer activity in 6 days
  -> Status: stalled — reviewer may be unavailable
  -> Dependency: PROJ-231 and PROJ-238 cannot start until this merges

  PROJ-219  Age: 9 days  PR: none linked
  -> Status: no PR exists — ticket moved to "In Review" manually
  -> Last engineer comment: 8 days ago

  PROJ-233  Age: 4 days  PR: open, merge conflict blocking CI
  -> Status: engineer has not returned to address conflict

  PROJ-244  Age: 3 days  PR: open, review completed, changes requested 2 days ago
  -> Status: waiting on author, engineer has not responded

  Sprint risk: 4 of 5 "In Review" tickets are not progressing.
  2 downstream tickets cannot start until PROJ-214 unblocks.

The snapshot above is what "In Review" actually looks like when you can see through the status label to the underlying system state. Four of five tickets are not progressing. Two downstream tickets are waiting on one of them. A scrum master looking at this on day eight can still act: escalate the reviewer, prompt the engineer, and decide whether the two downstream tickets should be deferred or have their dependencies broken.

The same scrum master looking only at the sprint board sees five tickets in "In Review" and no signal that anything is wrong — because the Jira status is unchanged and nobody raised a blocker at standup. The difference between those two situations is whether the scrum master can see actual system state or only reported status.

Final take

The "In Review" column is the most opaque part of a sprint board. It is where work goes to stall without triggering any of the usual escalation mechanisms — not standup, not Jira alerts, not any automated warning. Tickets sit there looking like progress until the sprint closes and the team realizes they never moved.

The fix is not a new standup question or a stricter definition-of-done policy. The fix is connecting the status column to what the system actually shows: whether a PR exists, whether it is being reviewed, whether it is blocked, and how long it has been sitting in any of those states.

A ticket sitting in "In Review" for eleven days is not a review problem. It is a visibility problem. You can't fix what you can't see — and the sprint board alone does not let you see it.