Mid-Sprint Scope Insertion on a Payments Team
A payments team of six runs two-week sprints and averages 42 completed story points. On day 4 of the current sprint, the product owner adds an "urgent, tiny" card-not-present fraud banner, estimated at 8 points, saying compliance needs it in three weeks. The team's definition of done does not include automated tests or a security review; both are handled by a separate QA group after the sprint ends. One of the two testers is pulled into production support two days a week, and the last three sprints carried over 55-60% of committed points. At retrospective, developers say estimates get "attacked" in refinement and admit they now pad. The engineering manager has told the Scrum Master to "just add the banner, drop the documentation, and show leadership a healthy burn-down." Daily standup has drifted to 30 minutes of status reporting to the manager.
1. Should the team pull the 8-point banner into the current sprint? What should the Scrum Master actually do?
Read the worked answer
No - not by unilateral addition. The Scrum Master's job is to make the trade-off visible and let the product owner decide scope, not to absorb work silently or to refuse on principle.
Reasoning from the numbers:
- 8 points is about 19% of the 42-point average, and recent sprints completed only 40-45% of committed work. The team has no spare capacity; adding the banner guarantees a fourth consecutive carryover and pushes the sprint goal out.
- The Scrum Master does not own the sprint backlog. The team decides how much work it takes on; the product owner orders it. The correct move is a conversation, not an instruction.
What to do:
- Present the arithmetic to the product owner: current remaining work versus capacity, tester availability, and the carryover trend.
- Offer real options: swap out equal-sized committed items; descope the banner to a smaller slice that satisfies compliance for the first release; or treat it as an expedite with an explicit, documented cost to the sprint goal.
- Escalate the trade-off, not the refusal. If compliance truly cannot move, the product owner should state that the sprint goal is abandoned - visibly, to stakeholders.
- Never let the manager dictate a burn-down. A fabricated chart converts a capacity problem into a trust problem.
Abnormal sprint termination is a legitimate option if the sprint goal is genuinely invalidated, but it must be visible and deliberate, not a quiet reset.
2. Diagnose the 55-60% carryover. Which changes to definition of done and capacity planning would you make first?
Read the worked answer
Carryover at 55-60% for three sprints is a systemic forecasting and definition-of-done failure, not a motivation problem.
Contributing causes visible in the setup:
- Capacity is overstated. One of two testers is unavailable 40% of the time for production support. That is a recurring, known loss, yet planning appears to ignore it.
- "Done" excludes testing and security review. Work is counted as complete when it is not shippable, so the QA group absorbs the tail after the sprint. That tail reappears as carryover or as escaped defects.
- Estimates are inflated deliberately because refinement feels adversarial. Padding then breaks relative sizing, which degrades velocity as a forecasting tool.
First changes:
- Plan from measured capacity, not from the 42-point average. Apply an availability factor for the known support rotation and publish a forecast range (for example 26-34 points), not a single commitment number.
- Amend the definition of done to require automated tests, a security checklist item, and a passing pipeline before an item counts as complete. This temporarily lowers velocity and is the point: the number becomes honest.
- Stop attacking estimates in refinement. Refine with relative sizing and questions, not cross-examination; the Scrum Master facilitates and calls out the behavior.
- Slice stories smaller so partial progress is visible and carryover is incremental rather than monolithic.
Fix the definition of done before touching velocity-based targets - otherwise the team is optimizing a number that does not mean done.
3. The manager wants a "healthy" burn-down. How should the Scrum Master respond, and which measures are more useful for leadership?
Read the worked answer
Refuse the framing, offer a better one.
Why not: a burn-down is the team's own instrument for asking "are we going to meet the sprint goal?" It is only useful if it is truthful. A chart drawn to look healthy hides the exact signal leadership needs - that commitments exceed capacity - and it will be discovered later as missed dates and escaped defects. Presenting false data also destroys the psychological safety the retrospective already shows is fragile.
What to do instead:
- Be transparent about the current sprint: show committed versus completed, carryover by item, and blocked time from the support rotation. Explain the trend in one paragraph.
- Publish a run chart of completed points over 6-8 sprints with a forecast range. Leadership gets predictability; the team keeps a working tool.
- Report sprint goal success rate, cycle time per story, escaped defects, and definition-of-done compliance rate. These answer "is delivery improving?" far better than a smoothed line.
- Track carryover percentage explicitly as a health metric - it is currently the most honest number the team has.
On standup: 30 minutes of status reporting to a manager is a daily coordination meeting masquerading as Scrum. Reset it to a 15-minute conversation about progress toward the sprint goal and impediments, and route status to the board or an async update. The manager is welcome to observe, not to chair.
The Scrum Master's loyalty here is to transparency, which ultimately protects the manager from a much worse surprise.