It is day seven of a ten-day Sprint and the team clearly will not finish everything. What do you do?

Say it today

The first failure is silence. A team that can see the shortfall on day seven and says nothing until the Review has spent the last three days of the Sprint on a plan the Product Owner would have changed, given the chance to. Raise it in the daily scrum, with the specific items at risk and what would have to change for each. There is no penalty in Scrum for a forecast turning out wrong; the penalty is for concealing it until the option to respond has expired.

The Sprint Goal is the commitment, the item list is not

This is the distinction the whole answer rests on. The Sprint Backlog is a forecast made with the information available at planning, and the Guide is explicit that the Developers and Product Owner may renegotiate scope within the Sprint as more is learnt. What may not quietly change is the Sprint Goal.

So ask whether the goal is still reachable with less. If the goal was "a customer can pay by card end to end", then the saved-cards feature and the receipt redesign are negotiable and their removal costs nothing against the goal. If the goal was a list of nine unrelated items dressed up as a sentence, you have no lever, and that is a planning problem to take to the retrospective rather than something to solve on day seven.

flowchart TD
  A[Shortfall visible on day 7] --> B{Sprint Goal still reachable}
  B -- yes --> C[Developers and PO cut scope to the goal]
  B -- no --> D{Goal now obsolete}
  D -- yes --> E[Product Owner cancels the Sprint]
  D -- no --> F[Keep the Sprint and land the largest coherent slice]
  C --> G[Unfinished items return to the Product Backlog]
  F --> G

The branch worth noticing is the one on the right: an unreachable goal is not by itself grounds for cancellation. Cancellation is for a goal that has stopped being worth pursuing at all.

Finish, do not spread

The reflex under time pressure is to have everyone push on everything so that the maximum number of items look close. That is the worst available move, because five items at eighty per cent deliver nothing and two items at a hundred per cent deliver two. Order the remaining work by what completes soonest and what serves the goal, put two people on one item if that is what finishes it, and stop starting anything new. If a large story has a genuinely shippable part, split it now so the finished half can meet the Definition of Done rather than travelling into the next Sprint as a lump.

What you do not do

You do not extend the Sprint. The length is fixed, and a Sprint that stretches to fit its contents destroys the only regular cadence the team has and makes every future forecast meaningless — you can no longer compare one Sprint's throughput with another's if the denominator moves.

You do not add people mid-Sprint and expect a return this week; onboarding cost lands now and the benefit lands later.

You do not ask for evenings and the weekend. It buys a few days once, at the cost of the sustainable pace, and it teaches the organisation that estimates are elastic if enough pressure is applied, which guarantees the same conversation next Sprint.

And you do not relax the Definition of Done to declare things finished. That converts a visible shortfall into invisible undone work, which is the version of this problem that surfaces two months later attached to a release date nobody can explain.

Afterwards, and why the cause matters more than the miss

Unfinished items go back to the Product Backlog, and the Product Owner reorders them against everything else. Do not treat carryover as automatically pre-committed for the next Sprint; a week of new information may have changed what matters.

Then work out which of three things happened, because the responses differ entirely. The team was optimistic at planning, in which case use throughput rather than optimism next time. Unplanned work arrived — an incident, a support escalation, a request accepted outside the Sprint — in which case the fix is capacity allowance and a route for interruptions, not better estimating. Or the work turned out to be different from what anyone understood, which is discovery, is normal, and is best answered by smaller slices and earlier integration rather than by more analysis up front. A candidate who reaches for "we will estimate more carefully" regardless of which of the three it was has answered the wrong question.