What is a sprint?

It can — at a cost the discipline makes visible instead of hiding. Something of comparable size leaves the cycle, and repeated interruptions measurably reduce the velocity of every future one, because context switching is the most expensive operation in software work. Genuine emergencies such as a production outage or a legal deadline have agreed exceptions. For everything else, an orderly fortnight of waiting costs less than permanent disorganisation, and a history full of weekly emergencies is really a diagnosis of prioritisation happening too late.

Occasionally, that is normal: estimation is probabilistic, unfinished items return to the backlog and get replanned, and the retrospective looks for the cause. Systematically, it is a signal — either estimates are inflated by optimism, or the cycles are overloaded under pressure, or unplanned interruptions keep arriving. As the buyer, the right question is not why it was not finished but what the trend across the last four cycles says. A mature answer comes with numbers and an adjustment rather than an excuse.

The practical standard is two weeks, balancing enough time for meaningful delivery against feedback often enough to matter. One week suits intense discovery phases; three or four suit work with heavy inertia, rarely and at the price of thinner feedback. The team decides with the client, once, at the start, and then the length stays fixed, because regularity is itself valuable — planning, demonstrations and forecasts all settle onto it — and changing the duration often usually means something else is being adjusted badly.