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.
TL;DR: Sprint planning decides what goes into the sprint, but at enterprise scale a lot of work comes in through the backdoor afterwards. In a typical organization, 22% of sprint issues are created after their sprint has started, the share keeps rising, and 40% of that work arrives in the second week, when it mostly turns into carryover. Fewer than half of these issues are urgent bugs: 62% are Medium or Low priority, and 42% belong to no epic at all. Projects that take in more than 35% of their work mid-sprint close only 52% of their planned story points on time, against 84% for disciplined ones. The Keypup MCP Server reads each Jira issue's creation date, sprint with its start and end dates, earlier sprints, type, priority, story points, parent epic, status and resolution date, and for its linked pull requests, the commits, review dates, approvals, size and recommended next action. Your AI assistant can then measure how much work skips planning, what it is, when it arrives, what it displaces, and what to send back to the backlog in the current sprint.
It's Tuesday of the second week. The Claims Platform team planned 68 story points nine days ago, and the plan looked realistic. Since then, a production bug came in on day 2, a sales-led "quick change" on day 4, two follow-ups from a stakeholder demo, and a handful of tasks raised in Slack and turned into tickets by the product owner. Nobody decided to break the plan. Each addition seemed small and reasonable. On Friday, the sprint review will show a third of the planned work carried over, and the retrospective will talk about estimation.
Sprint planning is the front door: the team looks at its capacity, agrees on a scope and commits to it. At enterprise scale, the backdoor stays open for structural reasons:
The result: a sprint commitment that the team is judged on, and a sprint scope that the team doesn't control.
Every point added mid-sprint is a point of planned work that has to wait. Planned work slips into the next sprint, roadmap dates move, and leadership sees a team that "can't hit its commitments", when it hit a different set of commitments it never agreed to.
Most mid-sprint work is unestimated and often not attached to any epic. It consumes real capacity without appearing in velocity, roadmap progress or investment reports. When leadership asks where the capacity went, nobody can answer.
Work that arrives mid-sprint is urgent by definition, so it skips the queue: it gets started at once, reviewed quickly and merged under pressure, sometimes with no approval and sometimes with no pull request linked to the ticket at all.
"Stuff keeps getting added to the sprint", "our sprint goal is a suggestion" and "why plan if the plan changes on day two?" come up again and again wherever engineering managers, Scrum Masters and tech leads compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/scrum, r/agile and r/EngineeringManagers.
"We commit to 60 points, and by the end of the sprint there are 20 more points of tickets in there that nobody planned. Then leadership asks why we only finished 70% of the commitment. We finished more than 100% of the work, just not the work we said we'd do."
"Half the stuff added mid-sprint isn't even urgent. It's 'can you just quickly...' from someone senior. Each one is small, nobody estimates it, and together they eat the second week."
"Our velocity chart looks stable, our roadmap keeps slipping, and nobody connects the two. The capacity is going into tickets that have no epic and no points, so they don't show up anywhere leadership looks."
The pattern holds: organizations plan sprints carefully and report on commitments, but nobody measures how much of the sprint comes through the backdoor, or what it pushes out.
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 creation date, its current sprint with its start date, end date and state, and the earlier sprints it went through, along with its type, priority, story points, parent epic, workflow status and resolution date. For the pull requests linked to it, Keypup provides the first commit, review request, first review, approvals, merge date, lines changed and, for open ones, a recommended next action.
One convention makes the analysis possible. An issue is added mid-sprint when it was created after the start date of the first sprint it went through. Keypup doesn't record when an existing backlog issue was dragged into a running sprint, so the figures below measure new work raised during the sprint, the largest and most visible part of the backdoor. All figures cover issues whose first two-week sprint closed in the last 12 full months, November 2025 to October 2026, for an organization of around 1,000 engineers across 72 Scrum teams, each with its own Jira project. Epics are excluded.
The first question: what share of sprint work never went through sprint planning, and is it growing?
MCP Prompt:
For Jira issues whose first sprint closed in the last 12 full months, count those created after that sprint's start date. Show KPI cards for the total, the share added mid-sprint, their share of story points and the trend, then a monthly stacked bar chart of planned versus added issues with the share as a line.
Output: How Much Sprint Work Enters After Planning?
Key Insight: More than one sprint issue in five never went through sprint planning. 22% of sprint issues were created after their sprint started, and the share rose every quarter, from 17% to 26%. They only hold 15% of the story points because 38% of them are never estimated: velocity charts barely register them.
"Unplanned" is often read as "urgent". Issue type and Jira priority show whether it is.
MCP Prompt:
Break down the issues added after their first sprint started by issue type, and within each type by Jira priority, as 100% stacked bars. Add the work planned at sprint start as a comparison bar.
Output: What Comes Through the Backdoor?
Key Insight: The backdoor isn't only for emergencies. Bugs make up 46% of mid-sprint work, and 41% of those bugs are Highest or High priority. But 62% of everything added mid-sprint is Medium or Low priority by its own Jira field: work that could have waited for the next planning session.
Work added on day 2 and work added on day 9 don't have the same chance of being finished. The sprint day of creation shows how late the additions arrive, and what happens to them.
MCP Prompt:
For issues created after their first sprint started, show a histogram of the sprint business day they were created on (day 1 to 10), and as a line, the share of each day's issues that were closed before that sprint's end date.
Output: When Does the Backdoor Open?
Key Insight: Work keeps arriving until the last day, and the later it arrives, the less of it gets done. 40% of mid-sprint issues are created in the second week. 78% of those added on day 1 are closed within the sprint, but only 33% of those added on day 9 and 21% on day 10: late additions mostly become carryover, without ever being planned.
Capacity spent on mid-sprint work is only visible in roadmap reports if that work belongs to an epic. The parent epic shows how much of it does.
MCP Prompt:
Show the issues added after their first sprint started as a treemap by parent epic, with the issues that have no parent epic as their own block. Add KPI cards for the share without an epic and the number of epics receiving mid-sprint work.
Output: Which Roadmap Does Mid-Sprint Work Belong To?
Key Insight: Nearly half of the work that skips planning also skips the roadmap. 42% of mid-sprint issues have no parent epic, more than twice the rate of planned work, and another 14% land in a standing "Production Support" epic. That capacity shows up in no roadmap report, yet it was spent.
The real cost of the backdoor is the planned work it pushes out. Grouping projects by how much work they take in mid-sprint shows whether it does.
MCP Prompt:
Group Jira projects by their share of sprint issues added after the sprint started: under 10%, 10–20%, 20–35% and over 35%. For each group, show the share of planned story points closed before the end of their first sprint, with one dot per project.
Output: Does Mid-Sprint Work Displace the Plan?
Key Insight: Every point that comes in through the backdoor pushes a planned one out. Projects that add under 10% of their sprint work mid-sprint close 84% of their planned story points on time. Above 35%, it's 52%. The plan wasn't wrong: the sprint was simply used for something else.
Urgent work jumps the queue. Comparing its flow with planned work shows what that costs in review and traceability.
MCP Prompt:
Compare planned and mid-sprint issues: median business days from creation to first commit, median business hours from review request to first review, median lines changed, share merged with no approving review, and share closed with no linked pull request. Show it as a dumbbell chart.
Output: How Is Mid-Sprint Work Built and Reviewed?
Key Insight: Mid-sprint work jumps every queue. It gets its first commit within 0.6 business days instead of 3.9, and its first review three times faster. It's smaller, but three times as likely to merge with no approval, and 31% of it is closed with no linked pull request at all. Some of it is genuinely code-free, but for the rest, the code can't be traced back to the ticket.
The last step turns the analysis into a mid-sprint check: in the active sprint, what has come through the backdoor so far, how far behind is the plan, and what can be sent back today?
MCP Prompt:
For the active sprint of the Claims Platform project, show the sprint day, the issues and story points created since the sprint started, the share of planned story points closed against this project's usual share at the same sprint day, then list the issues added mid-sprint with type, priority, points, sprint day created, Jira status, linked pull request and next action.
Output: What Has Entered This Sprint Since Planning?
| Issue | Type | Priority | Points | Created | Jira status | Linked pull request | Next action |
|---|---|---|---|---|---|---|---|
| CLM-2291 | Bug | Highest | 3 | Day 2 | Done | Merged · approved | None |
| CLM-2304 | Bug | High | – | Day 3 | In Review | Open · approved · conflicting | Rebase |
| CLM-2310 | Task | Medium | 5 | Day 4 | In Progress | Open · no reviewer requested | Assign reviewer |
| CLM-2312 | Story | Medium | 8 | Day 4 | In Progress | Draft | Wait for implementation |
| CLM-2318 | Bug | High | 2 | Day 5 | In Review | Open · build failing | Fix build |
| CLM-2322 | Task | Low | – | Day 6 | To Do | None | Implement |
| CLM-2325 | Story | Medium | – | Day 6 | To Do | None | Implement |
Key Insight: On day 6, Claims Platform has taken on 34% more story points than it planned, and it shows. Planned work is 12 points behind its usual pace. CLM-2291 was a genuine emergency, and it's done. But CLM-2322 and CLM-2325 are Low and Medium priority, unestimated and not started: moving them to the next sprint today leaves the four remaining days to the plan.
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 creation date, its current sprint with its name, state, start date and end date, and the list of earlier closed sprints it went through, with their dates. Comparing the creation date with the start date of the issue's first sprint is what separates planned from mid-sprint work, and the sprint end date is what defines "closed within the sprint". This requires your teams to use Jira sprints with start and end dates that match the real cadence.
Keypup doesn't record the moment an existing issue was added to a sprint. An old backlog issue dragged into a running sprint therefore counts as planned work, and the analysis measures new issues raised during the sprint. In most enterprises that's the bulk of the backdoor, but if your teams often pull existing backlog items into running sprints, the real figure is higher than the one shown. Bulk-created issues, such as tickets cloned for a release, also count as mid-sprint if they're created after the start: exclude them with a label or an issue type in your prompt.
Issue type, story points and the parent epic are standard Jira fields that Keypup imports. Priority is imported as a Jira field that Keypup exposes alongside custom fields, so its values are your own: if your teams don't set priorities, the priority breakdown won't be meaningful. Story point totals depend on your teams estimating: unestimated issues count as zero points, which is why the article also counts issues.
Everything about commits and review 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 first commit, review request, first review, approval count, merge date and lines changed of its linked pull requests, and for open ones, their state, build status, mergeability and a recommended next action such as assign a reviewer, fix the build or rebase. An issue closed with no linked pull request may be genuinely code-free, or its code may not reference the key: check your linking practice before reading that share.
Keypup doesn't import your sprint goal, your sprint planning meeting or who asked for a piece of work outside Jira. It can show who created each issue in Jira, but not whether a request came from sales, support or a manager unless your teams record it, for example with a label or a component. Keypup also can't judge whether an addition was justified: the data shows what came in, when, and what it displaced, and the team decides what to do about it.
Before Keypup MCP:
After Keypup MCP:
"For two years we trained teams to estimate better. The data showed the estimates were fine: a quarter of every sprint was being added after planning. Once that was on the same slide as the commitment rate, the conversation with the business changed completely."
Before Keypup MCP:
After Keypup MCP:
"We didn't stop the interruptions, and we shouldn't. We stopped pretending they weren't there. Now we plan 80% of capacity, and the roadmap has held for two quarters in a row."
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 dates that match the actual start of work, and close each sprint in Jira when it ends. A sprint started a day late in Jira makes day-1 tickets look planned.
Ask your assistant for the share of sprint issues with a priority, story points and a parent epic, by project. Where these fields are mostly empty, use issue counts instead of points, and treat the epic breakdown as a measure of your tagging practice.
Write down what counts as "mid-sprint" for your teams (created after the first sprint's start date), which labels or issue types to exclude, and your business days. You'll paste them into your prompts so that every team reads the same numbers.
Connect the MCP server to your AI assistant using the MCP documentation, run the active sprint check on day 5 or 6 of every sprint, and review the share of mid-sprint work and the planned points it displaced at each retrospective.
It's work added to a sprint after sprint planning, while the sprint is running: production bugs, stakeholder requests, follow-ups and small tasks that never went through planning or estimation. It consumes the sprint's capacity, so the planned work that the team committed to gets pushed out.
A simple, reliable measure is the share of a sprint's issues that were created after the sprint's start date. Compare it over time and by project, and look at their issue type, priority, story points and parent epic to see what the work is and whether it shows up in velocity and roadmap reports.
There's no universal target: a platform team on call will always take in more than a feature team. What matters is that the share is measured, planned for as reserved capacity, and stable. A share that rises every quarter, or a large share of Medium and Low priority additions, means the backdoor is being used for work that could wait.
Reserve explicit capacity for genuine interruptions, send non-urgent additions to the next sprint by default, require a planned item to be swapped out when something is added, and review the share of mid-sprint work at every retrospective so the team and its stakeholders see the trade-off.
A sprint commitment only means something if the sprint's scope stays close to what was planned. When more than a fifth of the work comes in through the backdoor, missed commitments, slipping roadmaps and rushed reviews are the predictable result, not an estimation problem. Keypup MCP makes the backdoor visible:
✅ Measuring how much work skips planning, and whether it's growing ✅ Finding out what comes through the backdoor, by type and priority ✅ Seeing when the backdoor opens, and how late additions turn into carryover ✅ Tracing mid-sprint work back to the roadmap, epic by epic ✅ Measuring what mid-sprint work displaces in planned story points ✅ Comparing how mid-sprint work is built and reviewed ✅ Checking what has entered the current sprint, issue by issue, with the next action
Ready to see what really goes into your sprints? 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 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.
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.