In a typical two-week sprint, 49% of the work gets its final merge on the last two days, reviews shrink to 1.6 hours and over a quarter of last-minute "Done" has no merged code. Learn what engineering leaders on Reddit say about the end-of-sprint merge rush at enterprise scale, and how Keypup MCP measures the curve, its cost and the work about to pile up.
TL;DR: Plot when sprint work actually merges and most enterprise teams don't get a flat line. They get a hockey stick: little merged code for eight days, then about half of the sprint's work merged on the last two days. Reviews in that window arrive five times faster on changes twice the size, nearly three times as many issues merge with no approval, and more than a quarter of the issues marked Done on the last two days have no merged code behind them at the sprint review. Teams with the steepest curve also carry over the most work. The Keypup MCP Server reads each Jira issue's sprint, with its start and end dates and its earlier sprints, its type, story points, status and resolution date, and for the pull requests linked to it, their first and last commit, review request, first review, approvals, merge date, size, state, build status and mergeability. Your AI assistant can then draw your merge curve, track it over time, measure what happens to review in the rush, find the teams that rush and spill, and list the work that will pile up at the end of the current sprint while there is still time to act.
It's Thursday afternoon on day 9 of the sprint. The review queue has 40 pull requests in it, most opened since Tuesday. The senior engineer who reviews the payments code has approved eleven of them since lunch, the largest one 1,200 lines long, in under ten minutes. Tomorrow at 15:00 is the sprint review, and everything has to be "Done" by then. On Monday, the bug reports start coming in, and on Wednesday the retrospective concludes, again, that "we need to finish things earlier in the sprint".
The sprint is meant to be a steady flow of small, finished increments. At enterprise scale, it rarely is, for structural reasons:
The result: a sprint that looks like a two-week cadence on the Jira board, and behaves like a two-day crunch in Git.
Rushed reviews are shallow reviews. When large pull requests are approved in minutes, or merged with no approval at all, defects that review would have caught go straight to the main branch, often on a Friday afternoon.
A sprint where most work merges in the last two days gives no early warning. On day 7 the burndown chart looks the same whether the sprint will land or not, so carryover is discovered at the sprint review instead of being managed during the sprint.
The rush has a human cost: evening merges, reviewers who spend the end of every sprint approving under pressure, and engineers whose work sits idle for a week waiting for its turn in the queue. It repeats every two weeks.
"Everything lands on the last day", "our burndown is a cliff, not a slope" and "reviews on sprint day 10 are just a formality" come up again and again wherever engineering managers, tech leads and agile coaches compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/agile, r/scrum and r/EngineeringManagers.
"Our burndown is flat for eight days and then falls off a cliff. Every retro we agree to merge earlier, and every sprint the same thing happens. I can't tell on day 7 whether we're on track or not."
"The last two days of the sprint I'm basically a rubber stamp. Thirty PRs land Thursday, everybody needs them merged for the demo, and nobody wants to be the person who blocked the sprint goal. That's when the bugs get in."
"Half the tickets that get moved to Done on the last afternoon still have an open PR, or no PR at all. The velocity looks great and the code shows up the following week."
The pattern holds: organizations plan, report and review work in two-week sprints, but nobody measures when inside the sprint the code actually merges, or what the rush does to it.
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 that each Jira issue carries its current sprint, with its start date, end date and state, and the earlier sprints it went through, along with its type, story points, workflow status, resolution date and assignee. For the pull requests linked to it, Keypup provides the first and last commit dates, review request date, first review, last approval, approval count, whether changes were requested, merge date and lines changed, and for open ones, their state, review state, build status and mergeability.
Two conventions make the analysis possible. The sprint day is the number of business days between the sprint's start date and the moment of interest, so a two-week sprint runs from day 1 to day 10. An issue's merge date is the date its last linked pull request merged. All figures cover issues in two-week sprints closed in the last 12 full months, November 2025 to October 2026, for an organization of around 900 engineers across 64 Scrum teams, each with its own Jira project.
The first question: across all sprints, on which sprint day does work actually get merged?
MCP Prompt:
For Jira issues in sprints closed in the last 12 full months, take the date the last linked pull request merged and count the issues by business day of the sprint (day 1 to day 10). Show it as a histogram against an even pace, with KPI cards for the total, the share merged in the last two days, the median sprint day of the first commit and the share of issues already carried over from an earlier sprint.
Output: When Does Sprint Work Actually Merge?
Key Insight: Half the sprint merges in its last fifth. 49% of sprint issues got their final merge on day 9 or 10, against 20% at an even pace, and the median issue had no commit until day 3.8. The sprint isn't a two-week flow of work: it's a week and a half of work in progress followed by a merge rush.
One year of totals can hide a trend. A monthly view shows whether the rush is a stable habit or a growing problem.
MCP Prompt:
By month of sprint end date over the last 12 full months, show as bars the number of sprint issues merged, and as lines the share whose last linked pull request merged on sprint day 9 or 10, and among those, the share whose pull request merged with no approving review.
Output: Is the Merge Rush Getting Worse?
Key Insight: The curve is getting steeper, and the safeguards thinner. The share of sprint work merged in the last two days rose from 43% to 55% in a year, while volume grew 19%. Among those last-minute merges, the share with no approving review more than doubled, from 5% to 11%.
The rush only matters if it changes how code is reviewed. Comparing work merged in the last two days with the rest of the sprint shows whether it does.
MCP Prompt:
For issues in sprints closed in the last 12 full months, compare those whose last linked pull request merged on sprint days 1–8 with those merged on days 9–10: median business hours from review request to first review, median lines changed, share merged with no approval, share with a commit after the last approval, and share where a reviewer requested changes.
Output: What Happens to Code Review in the Rush?
Key Insight: Reviews get five times faster and half as critical, on changes twice the size. In the last two days, the first review arrives in 1.6 business hours instead of 7.8, changes are requested half as often, 22% of issues get new commits after their approval, and 8% merge with no approval at all, nearly three times the rate of the rest of the sprint. That isn't faster review. It's less of it.
Not every team has the same curve. Plotting each team shows whether the rush actually rescues the sprint, or predicts that it will slip.
MCP Prompt:
Plot each Jira project as a bubble: share of its sprint issues whose last linked pull request merged on sprint day 9 or 10 on the x axis, share of its sprint issues already carried over from an earlier sprint on the y axis, bubble size by issues merged. Compare the average carryover of projects under 35%, 35–60% and over 60%.
Output: Do Teams That Rush Also Carry Over More?
Key Insight: The rush doesn't save the sprint, it predicts the spill. The 18 projects that merge more than 60% of their work in the last two days carry over 26% of their issues, against 10% for projects under 35%. A late merge curve and missed commitments are the same problem seen from two sides.
Knowing that the rush is on days 9 and 10 is useful. Knowing it's on the last afternoon, and in the evening, tells you how much pressure it puts on people.
MCP Prompt:
Show a heatmap of the sprint issues from the last 12 full months by sprint day (1 to 10) and hour band of the last linked merge, converted to Central European Time, as a share of all sprint issues. Add the share merged after 18:00 on days 1–8 and on days 9–10.
Output: When, Exactly, Does the Rush Happen?
Key Insight: The last afternoon of the sprint is the busiest three hours of the fortnight. 8.6% of all sprint merges land between 15:00 and 18:00 on day 10, and on the last two days one merge in six happens after 18:00, almost twice the rate of the rest of the sprint. That's the work the sprint review depends on, merged by tired people with little time left to review it. One caveat: Keypup stores timestamps in UTC, so the assistant shifts them to the time zone you name in the prompt, here without daylight saving time.
The rush has a second outcome: issues moved to Done for the sprint review before their code is merged. Comparing resolution dates with merge dates shows how often.
MCP Prompt:
For issues moved to Done on sprint day 9 or 10 of sprints closed in the last 12 full months, show as a donut how many had their linked code merged before they were resolved, merged only after the sprint ended, still open, or had no linked pull request. Break it down by issue type as stacked bars.
Output: How Much of the Last-Minute "Done" Is Done on Paper?
Key Insight: More than one in four last-minute "Done" issues has no merged code behind it at the sprint review. 11% were closed in Jira and merged after the sprint ended, 3% still have an open pull request, and 13% have no linked pull request at all. For Tasks, that last share reaches 19%: some are legitimately code-free, but every one of them counts in the velocity chart.
The last step turns the analysis into a mid-sprint check: on day 7, what is still unmerged, and what does each item need now, before it joins the rush?
MCP Prompt:
For the active sprint of the Payments project, show how many business days are left, the share of story points already merged compared with this project's usual share at the same sprint day, then list the largest issues whose code isn't merged, with type, story points, Jira status, the state, review state, build status and mergeability of the linked pull request, the next action and the assignee.
Output: What Will Pile Up at the End of This Sprint?
| Issue | Type | Points | Jira status | Linked pull request | Next action | Assignee |
|---|---|---|---|---|---|---|
| PAY-4412 | Story | 8 | In Review | Open · changes requested · 1,240 lines | Fix code | m.novak |
| PAY-4398 | Story | 5 | In Review | Open · no reviewer requested | Assign reviewer | j.alvarez |
| PAY-4431 | Bug | 3 | In Review | Open · approved · build failing | Fix build | t.okafor |
| PAY-4405 | Story | 5 | In Review | Open · approved · conflicting | Rebase | e.lindqvist |
| PAY-4420 | Task | 3 | In Progress | Draft | Wait for implementation | k.sato |
| PAY-4387 | Story | 8 | In Progress | None | Implement | r.haddad |
| PAY-4440 | Story | 5 | To Do | None | Implement | Unassigned |
Key Insight: At day 7, Payments is on its usual curve, and that's the problem: 47 points are lined up for the last three days. PAY-4405 only needs a rebase and PAY-4398 a reviewer, today. PAY-4412 is a 1,240-line pull request with changes requested: it will be the one rubber-stamped on Friday afternoon unless it's split now. PAY-4440 has no code and no owner, and belongs in the next sprint.
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 depend on.
Keypup imports each issue's current sprint, with its name, state, start date, end date and closure date, and the list of earlier closed sprints the issue went through. That's what defines the sprint days and identifies carried-over issues. It requires your teams to use Jira sprints: Kanban boards without sprints have no sprint day to measure. The sprint dates are the ones set in Jira, so a sprint started late or ended early in Jira shifts the curve with it.
Everything about code relies on pull requests being linked to the issue, which Keypup does when the Jira key appears in the pull request title, or in its description or a commit message after a closing keyword such as "fixes". For each issue, Keypup provides the earliest and latest merge date of its linked pull requests, and combines their review dates, approvals and size. If your teams don't reference Jira keys consistently, linked work shows up as "no linked pull request" and drops out of the merge curve. Check the share of sprint issues with a linked pull request before reading the results.
Keypup imports, for each pull request, when review was requested, when the first review was submitted, when it was last approved or had changes requested, its approval count, its first and last commit and its lines changed. That's what measures review speed, merges with no approval and commits pushed after approval. Review approvals reflect what your Git platform records: if your teams approve outside the pull request, Keypup can't see it.
For each open pull request, Keypup imports its state, review state, build status and mergeability, and computes a recommended next action such as assign a reviewer, fix the code, fix the build, rebase or merge. Together with story points and the sprint's end date, that's what lets the assistant list what each unmerged issue needs before the sprint ends. Story points come from Jira's story points field: if a team doesn't estimate, ask for the share of issues merged instead. A project's "usual share at the same sprint day" is computed from its own closed sprints of the last 12 months.
Keypup doesn't import deployment events, the sprint review itself or your burndown chart as such. "Merged" means the code reached the pull request's target branch; it doesn't prove it was deployed. Timestamps are stored in UTC, and the assistant converts them to the time zone you give in the prompt. Keypup can't tell why a team rushes: the data shows the curve and its consequences, and the retrospective has to find the cause.
Before Keypup MCP:
After Keypup MCP:
"We'd been saying 'merge earlier' in retros for two years. Once each team could see its own curve, it actually started to flatten. The incidents that used to follow every sprint review mostly went away."
Before Keypup MCP:
After Keypup MCP:
"Our velocity was a number we negotiated on Friday afternoon. Now Done means merged, the curve is flatter, and our seniors get to review code instead of stamping it."
Connect Jira and GitHub, GitLab, Bitbucket or Azure DevOps to Keypup. Issues, sprints, pull requests and reviews are imported automatically.
Make sure your teams use Jira sprints with start and end dates that match the real cadence, and close each sprint in Jira when it ends.
Ask your assistant for the share of sprint issues with a linked pull request, by project. Where it's low, the merge curve describes your linking practice as much as your sprints: fix that first by asking teams to put the Jira key in pull request titles.
Write down your business days, your time zone and what counts as "the last two days" for your sprint length. You'll paste them into your prompts so that every team reads the same curve.
Connect the MCP server to your AI assistant using the MCP documentation, run the readiness check on day 6 or 7 of every sprint, and review the merge curve and the "Done on paper" check in each retrospective.
It's the pattern where most of a sprint's code is merged in its last one or two days, instead of steadily across the sprint. Plotted by sprint day, merges form a hockey-stick curve: flat for most of the sprint, then a sharp rise just before the sprint review.
Because teams start all their sprint issues in parallel, open large pull requests late, and treat the sprint review as the deadline. Review capacity doesn't grow to match, so the queue builds up and is cleared in a rush on the last days.
Link pull requests to Jira issues through the issue key, then count, for each issue in a closed sprint, the business days between the sprint start date and the merge of its last linked pull request. The share merged on the last two days is a simple measure of how steep the curve is.
Start fewer issues in parallel, open smaller pull requests earlier, run a mid-sprint check of what isn't merged and what it needs, and only count issues as Done once their code is merged. Measure the curve every sprint so the team can see whether it's working.
A two-week sprint that delivers in two days hides its risk until the sprint review: rushed reviews, unapproved merges, evening work, "Done" without code and work that spills into the next sprint. Keypup MCP makes the curve visible:
✅ Drawing the sprint's merge curve, day by day ✅ Tracking whether it's getting steeper month over month ✅ Measuring what happens to code review in the rush ✅ Finding the teams that rush and spill ✅ Pinpointing when, exactly, the rush happens ✅ Checking how much last-minute "Done" is done on paper ✅ Listing what will pile up at the end of the current sprint, issue by issue
Ready to see what your sprints really look like? Connect the Keypup MCP Server and ask your AI assistant.
Join teams already using AI to make data-driven decisions faster than ever.
In a typical enterprise, more than one sprint issue in five is created after the sprint has started, and projects that take in the most of it close as little as half of their planned story points. Learn what engineering leaders on Reddit say about mid-sprint scope injection, and how Keypup MCP measures what comes through the sprint backdoor, what it displaces and what to push back today.
Compare the 6 best engineering metrics software for fast setup in 2026 — Keypup, LinearB, Swarmia, Jellyfish, Faros and Harness SEI — across setup speed, integration overhead, dashboard flexibility, delivery metrics coverage, AI capabilities and data security. Find out which platform gets a mid-market engineering team from connecting Git and Jira to actionable delivery metrics in minutes, not months.
Your release notes list 9,860 changes. Only 71% had merged code by the release date, and a quarter of the merged code is listed nowhere. Learn what engineering leaders on Reddit say about Jira Fix Versions, release scope and untracked changes at enterprise scale, and how Keypup MCP reconciles each version's scope with linked, merged pull requests.