Green on the outside, red on the inside. Learn what engineering leaders on Reddit say about Jira tickets moved to Done before the code ships, velocity that doesn't match delivery and status reports nobody trusts at enterprise scale, and how Keypup MCP compares each issue's closure date, workflow history and sprint with the state and merge dates of its linked pull requests to measure how much of your reported "Done" has no merged code behind it.
TL;DR: In large engineering organizations, a Jira ticket in "Done" doesn't always mean the code is merged. Tickets are closed on the last day of the sprint to protect velocity, moved straight from In Progress to Done, or closed while the pull request is still waiting for review. This is watermelon status: green on the board, red in Git. Velocity, roadmap reports and release notes are all built on it. The Keypup MCP Server reads each Jira issue's closure date, workflow status history, sprint, story points and type, and the state, merge date, review state and build status of the pull requests linked to it. Your AI assistant can then measure how much of your reported "Done" was closed ahead of its code, how far reported velocity is from merged velocity, when and from which status tickets jump to Done, which teams do it most, and which "Done" tickets still have code in flight today.
Every engineering leader has sat in a steering committee where the dashboard was green and the release was late. The board said the features were done. Git said otherwise. And nobody in the room could tell how much of the green was real.
In a team of eight, the engineering manager knows which ticket was closed a bit early. In an organization with 1,200 engineers, 60 Jira projects and 400 repositories, the gap between the board and the code becomes invisible for structural reasons:
The result is a status report that is green on the outside and red on the inside — and leaders who stop trusting it.
Roadmap forecasts are built on velocity. If one point in five was booked before its code was merged, every forecast built on it is optimistic by the same amount — and the gap shows up as a slipped release, not as a data quality issue.
Release managers build their scope from the tickets in Done. Tickets closed ahead of their code end up in release notes for features that aren't in the build, or in "ready to ship" lists for code that is still waiting for review.
Once leaders discover that Done doesn't mean done, they stop reading the board and start asking people. Status meetings multiply, engineers spend more time reporting than building, and the tool meant to give visibility becomes the reason for more meetings.
"Watermelon projects", tickets closed to hit sprint commitments and velocity that doesn't match what ships come up again and again wherever engineering managers, program managers and directors compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/EngineeringManagers, r/projectmanagement and r/agile.
"Every program was green in the monthly review. Then integration testing started and half the 'done' stories had PRs still open or not even created. We weren't lying, exactly. We just measured the board instead of the code."
"Teams move tickets to Done on the last afternoon of the sprint so the burndown looks right, then merge the PR on Monday. Multiply that by forty teams and my roll-up is fiction. I don't know by how much."
"Our velocity went up 30% in a year and nobody could explain why delivery didn't. Turned out a couple of teams were closing tickets when the PR was opened, not when it merged. Nobody was checking."
The pattern holds: leaders report on the board, but nobody checks whether the code behind "Done" was actually merged.
The Keypup Model Context Protocol (MCP) Server gives your AI assistant structured access to the data Keypup imports from Jira and from GitHub, GitLab, Bitbucket and Azure DevOps. For this analysis, what matters is each Jira issue's closure date, current workflow status, workflow status history, sprint and sprint end date, story points, type and project, and, for the pull requests linked to it, their state, the date of the last merge, their review state, build status and lines changed.
A pull request is linked to an issue when it references the issue key — in its title, or in its body or a commit message after a closing keyword such as "fixes" or "resolves". Issues without linked pull requests are left out of every prompt below: that work may not need code, or its pull requests may not reference the key. An issue was closed ahead of its code when at least one linked pull request merged after the issue was closed or is still open today, or when none of its linked pull requests were merged. "Done" statuses are the names your workflows use — here Done, Closed and Resolved. Durations are in business days — Monday to Friday, 09:00 to 17:00 UTC by default; adjust the working hours and time zone to match your teams.
The first question: how much of what Jira calls Done was closed before its code was merged?
MCP Prompt:
For Jira issues closed in a Done, Closed or Resolved status in the last 12 months that have at least one linked pull request, show the number closed, the share closed before all their linked code was merged, the number whose last linked pull request merged after closure with the median business days between the two, and the number whose linked pull requests are still open or were all closed without merging.
Output: Status Integrity Health Check — Last 12 Months
Key Insight: One "Done" issue in seven was closed before its code was merged. Most of that code lands a few days later — but 2,650 issues reported as delivered have no merged code behind them at all.
Velocity is where watermelon status does the most damage: it feeds every forecast.
MCP Prompt:
For the PAY project's last 8 closed sprints, considering only issues with at least one linked pull request, show as a dumbbell chart the story points of issues closed by the sprint end date, against the story points of those issues whose linked pull requests were all merged by the sprint end date.
Output: Reported Velocity vs Merged Velocity
Key Insight: About one reported point in five had no merged code by the end of its sprint. Reported velocity grew 26% between sprint 41 and sprint 48; merged velocity grew 11%. The gap is widening — and every forecast built on reported velocity inherits it.
If tickets are closed to protect the sprint, the timing will show it.
MCP Prompt:
For the same issues, group them by business days between closure and the end date of their sprint — 5 or more before, 2 to 5, 1 to 2, the last day, after the sprint end. Show the number closed as columns and the share closed before all their linked code was merged as a line.
Output: When Do Watermelon Issues Get Closed?
Key Insight: Issues closed on the last day of the sprint are almost five times as likely to be ahead of their code as issues closed a week earlier — 33% against 7%. The sprint boundary, not the work, decides when they move to Done.
A ticket that goes through In Review and QA before Done has passed checkpoints. A ticket that jumps from In Progress hasn't.
MCP Prompt:
For every workflow status change into Done, Closed or Resolved in the last 12 months, show as a donut chart the share by the status the issue moved from.
Output: Which Status Do Issues Jump to Done From?
Key Insight: More than one move to Done in four skips the statuses meant to prove the work is finished. Some of it is legitimate — duplicates and won't-fix tickets closed from the backlog — but In Progress straight to Done is the board's version of "trust me, it's merged". The status names depend on your workflows: map yours before reading the split.
An organization-wide rate hides the teams where the board and the code have drifted furthest apart.
MCP Prompt:
As a heatmap, show by Jira project and month of closure over the last 6 months the share of issues with linked pull requests that were closed before all their linked code was merged.
Output: Which Teams Report Ahead of Their Code?
Key Insight: MOB sits above 23% every month and DATA is drifting up, while PLAT went from 21% to 8% in six months. The spread between teams is far larger than month-to-month noise — which means it's a practice, not an accident, and practices can be copied.
The teams with the highest velocity get the most attention in planning. Is their velocity real?
MCP Prompt:
For each Jira project, show as a scatter plot the average story points closed per sprint over the last 12 months against the share of issues closed before all their linked code was merged. Size each point by the number of issues closed.
Output: Is High Velocity Partly Watermelon?
Key Insight: The three highest-velocity projects are also among the most likely to close work ahead of their code. Part of what looks like speed is points booked before the merge. CORE and CHK show that high throughput doesn't require it — they're the teams to learn from.
The last step turns the analysis into a list someone can act on this week.
MCP Prompt:
List open or draft pull requests whose linked Jira issue is closed. Show the issue key, issue type, story points, issue status, business days since the issue was closed, the pull request state, review state, build status and lines changed. Sort by time since the issue was closed.
Output: Done Issues With Code Still in Flight
| Issue | Type | Points | Status | Since Done (bd) | PR State | Review State | Build | Lines |
|---|---|---|---|---|---|---|---|---|
| PAY-4812 | Story | 8 | Done | 14.5 | OPEN | CHANGES_REQUESTED | FAILURE | 1,240 |
| MOB-2290 | Story | 5 | Done | 11.0 | DRAFT | NONE | NONE | 860 |
| BILL-1733 | Bug | 3 | Resolved | 9.5 | OPEN | PENDING | SUCCESS | 310 |
| DATA-907 | Task | 5 | Done | 7.0 | OPEN | CHANGES_REQUESTED | SUCCESS | 540 |
| MOB-2311 | Story | 3 | Done | 4.5 | OPEN | PENDING | IN_PROGRESS | 220 |
| PAY-4840 | Bug | 2 | Done | 2.0 | OPEN | APPROVED | SUCCESS | 95 |
| CHK-6120 | Story | 5 | Closed | 1.0 | OPEN | APPROVED | FAILURE | 410 |
Key Insight: Seven issues counted as delivered still have code waiting. PAY-4812 was closed three weeks ago with changes requested and a failing build, and MOB-2290's pull request is still a draft. PAY-4840 just needs a merge; CHK-6120 needs a green build first. Either reopen these tickets or finish the code — but stop counting them as shipped.
Every number above comes from fields Keypup already imports from Jira and your Git platforms. It helps to be precise about what they are — and what they aren't.
Keypup links a pull request to a Jira issue when the pull request references the issue key — in its title, or in its body or a commit message after a closing keyword such as "fixes", "closes" or "resolves". Each issue then carries the list of its linked pull requests, a resolution state — in progress when at least one linked pull request is open, implemented when all of them are merged, none when they were all closed without merging — and the dates of the first and last merge among them. Pull requests that don't reference a key can't be linked, so the share of issues with linked pull requests is the first number to check: if it's low, start by agreeing on a pull request title convention.
An issue was closed ahead of its code when its closure date is earlier than the last merge of its linked pull requests, or when its resolution state isn't implemented. Keypup doesn't read your code to decide whether a ticket is "really" done: it compares when the ticket closed with when the code merged. A ticket closed because the work wasn't needed after all will appear here if its linked pull requests were closed without merging — which is a status worth correcting anyway.
Keypup imports each issue's workflow timeline and every workflow status change, including the status it moved from and the user who moved it. Status names are whatever your Jira workflows use, so a prompt that says "In Review" or "QA" needs to use the names your projects actually have.
Story points and sprints come from Jira's own fields. Each issue carries the sprint it is attached to, with that sprint's end date, the list of past sprints it went through, and the issue's story points. Projects that don't estimate in points or don't run sprints won't appear in the velocity and sprint-timing views; for them, count issues instead of points.
For each linked pull request, Keypup records its current state — open, draft, merged or closed — its review state, its latest build status and its lines changed. They describe the pull request today, not on the day the ticket closed.
Keypup's BUSINESS_DAYS function counts working time between two dates — Monday to Friday, 09:00 to 17:00 UTC by default — and accepts a different time zone, working hours and working days. It doesn't know about public holidays or vacations: Keypup doesn't import calendars.
Before Keypup MCP:
After Keypup MCP:
"Our dashboards weren't wrong, they were early. Showing the merged number next to the reported one ended the debate in one meeting — and it's the number we forecast with now."
Before Keypup MCP:
After Keypup MCP:
"The list of Done tickets with open pull requests is the first thing our release manager opens. It's short now. A year ago it was the reason our release notes were wrong."
Connect Jira and GitHub, GitLab, Bitbucket or Azure DevOps to Keypup. Issues, workflow history, sprints, pull requests, reviews and builds are imported automatically.
Every analysis here depends on links. Ask your assistant for the share of merged pull requests linked to an issue, by repository. Where it's low, agree on a convention — the issue key at the start of every pull request title is the easiest to enforce.
List the workflow statuses that mean Done, review and QA in each project, and reuse the same list in every prompt so numbers stay comparable across teams and over time.
Follow the MCP documentation to connect Keypup to Claude, ChatGPT, Cursor or any MCP-compatible assistant.
Run the health check and the velocity comparison to set a baseline. Then check the "Done with code in flight" list before every sprint review and release, review the team heatmap monthly, and show merged velocity next to reported velocity in every roadmap forecast.
Watermelon status is a project or ticket that looks green from the outside — reported as done or on track — while the underlying work is red. In engineering, it typically means Jira issues moved to Done before their code was merged.
Compare each issue's closure date with the merge dates of the pull requests linked to it. If a linked pull request merged later or is still open, or none of them merged, the ticket was closed ahead of its code. Keypup MCP does this from data it already imports, as long as pull requests reference the issue key.
Story points count when the ticket closes, not when the code ships. If tickets are closed before their pull requests merge — often on the last day of the sprint — reported velocity runs ahead of delivery. Comparing points closed with points whose code was merged by the sprint end shows the gap.
No. Workflow rules and automations can stop some shortcuts; Keypup MCP measures how often the board and the code still disagree — by team, sprint, status and ticket — so you know which rules to add and whether they work.
A Done column only tells you that someone moved a ticket. Keypup MCP shows how much of your "Done" has merged code behind it, and where it doesn't:
✅ Measuring how much "Done" was closed ahead of its code across every Jira project ✅ Comparing reported velocity with merged velocity, sprint by sprint ✅ Showing when tickets close ahead of their code, relative to the sprint end ✅ Finding which status tickets jump to Done from, and how often reviews and QA are skipped ✅ Comparing teams month by month to find the practices worth copying ✅ Checking whether high velocity is partly watermelon ✅ Listing "Done" tickets with code still in flight before the next review or release
Ready to see how much of your green is real? Connect the Keypup MCP Server and ask your AI assistant.
Join teams already using AI to make data-driven decisions faster than ever.
Software capitalization, client billing and R&D tax credits all run on Jira time logs that engineers fill in on Friday afternoon, from memory. Learn what engineering and finance leaders on Reddit say about time tracking nobody trusts, and how Keypup MCP compares Jira worklogs with linked pull requests, commits and merges to show when time is logged, how late it arrives, and which hours have code behind them.
Your pipelines got faster and your reviews got shorter, yet features still take months to reach customers. Learn what engineering leaders on Reddit say about work that waits weeks in Backlog, Ready for Development and To Do before anyone writes code, why delivery dashboards that start at the first commit miss it, and how Keypup MCP uses Jira workflow history, sprints and the commit and merge dates of linked pull requests to measure the queue in front of your code.
An approved pull request isn't always approved code. Learn what engineering leaders on Reddit say about commits pushed after approval, self-merges and bypassed branch protection at enterprise scale, and how Keypup MCP uses approval dates, last commit dates, approval counts, required approvals, mergers, target branches and build status to measure how much code reaches your protected branches without anyone reviewing what actually shipped.