08Ranges, buffers and fixed dates

A release goal says what. The forecast says roughly when. The two meet in the most common planning situation of all: a date someone cannot move.

From size and speed to a range

Suppose the Blood tests team's part of release 2 is sized at 240 points, and the team's velocity over recent sprints has ranged from 25 to 35 points per two-week sprint. (The numbers are illustrative.)

• At 35 points per sprint: 240 ÷ 35 ≈ 6.9, so 7 sprints, or 14 weeks.
• At 25 points per sprint: 240 ÷ 25 = 9.6, so 10 sprints, or 20 weeks.

The honest forecast is "between 14 and 20 weeks". With several teams, each produces its own range, and the release can be no earlier than the latest of them. That is one more reason to keep each team's scope balanced from release to release.

When the date is fixed

Now suppose the date is fixed. A blood establishment has booked its validation team for a given period, and the new version must be ready at the start. Sixteen weeks, eight sprints, are available. The question changes from "when?" to "what can we be confident of delivering?". At 25 to 35 points per sprint, eight sprints give between 200 and 280 points of capacity.

The ordered backlog answers the question directly. Work above the 200-point line is very likely to be delivered. Work between 200 and 280 is possible. Work below is out unless something changes. This is the conversation to have at the start of the release, not in its last sprint.

Feature buffers: decide what gives way

The most practical protection for a fixed date is a feature buffer. Mandatory work fills only part of the expected capacity, and the rest is filled with work that is valuable but can be dropped. In release 2, handling positive results is mandatory: it is a safety rule, and the release goal depends on it. Some additional inventory cases are desirable but could move to the next release. If things go well, everything ships. If not, the optional work absorbs the shortfall and the date holds. The DSDM method formalises this with its MoSCoW categories (must, should, could and won't have), and recommends keeping "must have" items to a minority of the effort, commonly cited at around 60%.

Schedule buffers: one shared margin, not hidden padding

When the scope cannot flex either, the remaining protection is time. The common mistake is to pad every estimate. Each padded estimate is then quietly consumed, and the total margin disappears without anyone deciding it should. A better approach estimates each item twice, a likely size and a safe size, and adds one visible buffer to the release as a whole:

buffer = √Σ_i (safe_i − likely_i)²

The formula reflects the fact that not every item will hit its worst case at once. For three items estimated at 3 and 5, 5 and 8, and 8 and 13 points, the differences are 2, 3 and 5, the buffer is the square root of 38, about 6 points, and the plan is 16 + 6 = 22 points instead of 26 if every item were padded. The plan is tighter and more honest, and the buffer is visible to everyone who might be tempted to use it.