Forecasting and release planning

A forecast, and the one thing that is a commitment

Sprint Planning ends with a set of Product Backlog items in the Sprint Backlog, and those items are a forecast — the Developers' best reading of what they believe can be Done in the time available. The commitment is somewhere else. Every artefact in Scrum carries exactly one commitment, and the Sprint Backlog's is the Sprint Goal: a single objective the whole Scrum Team agreed, not a list of nine things. The Scrum Guide says of it that "Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it."

That split is not a technicality — it is the mechanism that lets a team learn inside a Sprint without failing it. On day eight the Developers discover the migration is three times the size they thought and two of the seven items will not make it. Because the promise was the objective and not the inventory, they collaborate with the Product Owner to renegotiate the scope of the Sprint Backlog, and the Sprint Goal stands untouched. Two things do not move: the length of the Sprint, and the Sprint Goal. Everything between them is negotiable as more is learned, and unfinished items return to the Product Backlog to be ordered against everything else rather than sliding automatically into the next Sprint. The Sprint Goal has exactly one exit, and it is not rewriting: if the goal becomes obsolete the Sprint may be cancelled, and only the Product Owner has that authority.

The convincing wrong answers here are the ones an ordinary organisation gives. A delivery manager writes the nine items down and calls them the team's commitment, borrowing the authority of Commitment as a Scrum Value — but that value describes how people apply themselves to the Sprint Goal, not a contract for a quantity of items. Others invent a step: the Product Owner accepting the selection at the end of Sprint Planning, or a velocity figure from the last three Sprints that supposedly converts a forecast into an obligation. Scrum has no acceptance step, and no measurement makes the future knowable. Extending the Sprint by three days to save the original list, and having the Scrum Master rewrite the Sprint Goal to match whatever is still achievable, are the same error from opposite ends — both protect the forecast by damaging the thing that was actually promised.

Who says how much, and on what evidence

The Developers select the items, through discussion with the Product Owner. The two accountabilities are answering different questions: the Product Owner decides what is most valuable and in what order it should be considered, and the Developers decide how much of that queue they can turn into a Done Increment. A customer date the Product Owner has already given is an input to the conversation, not a lever that moves the boundary. So a Product Owner insisting on eleven items, a Scrum Master splitting the difference at nine, a majority vote of the whole Scrum Team, and a capacity figure signed off by a delivery manager before the event are four versions of the same wrong answer: somebody outside the Developers setting the volume of work.

Scrum names the evidence that makes that judgement better, and every item on the list is something the Developers themselves hold. In the Guide's words, "the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts". Past performance because in a complex environment only finished work is evidence of anything. Upcoming capacity because leave, on-call duty and a new joiner change what the next two weeks can hold, and it is the most knowable variable a forecast has. The Definition of Done because it fixes how much work an item actually carries — a vague or shifting standard makes every estimate a different size than it looked. Notice what is not on the list: no estimation technique, no tool, and no other team's throughput.

Sizing is where folklore is thickest. A programme office announces that no item may be selected until it carries a story-point estimate agreed in a recurring refinement session, because that is supposedly how Scrum sizes work. Scrum names no unit, no meeting and no tool. What it does say is that refinement is an ongoing activity adding detail — a description, order and size — and that an item small and clear enough to be Done by the Scrum Team within one Sprint is thereby ready for selection. Readiness is a statement about size relative to a Sprint, not a number written on a card. The Developers who will do the work are responsible for the sizing; the Product Owner may influence them by helping them understand and select trade-offs, which is a different act from handing them figures. The opposite overcorrection fails too: sizing is not made unnecessary by having a Sprint Goal, since a forecast made in ignorance of size is not a forecast.

Forecasting further out than one Sprint

A finance director wanting a twelve-month plan with fixed scope and fixed dates is usually asking for two legitimate things: a stable objective, and a view of progress towards it. Scrum supplies both, in a different currency. The Product Goal is the long-term objective the Scrum Team plans against — a described future state of the product — and the Product Backlog is the ordered, emergent list of what will fulfil it. So the answer is to offer the Product Goal as the fixed point and re-forecast its likely delivery every Sprint from work that has actually been Done, showing each revision. What cannot be supplied is fixed scope, because freezing an emergent list is how a plan stops describing the product. Refusing any horizon beyond the current Sprint is the over-literal reader's mistake, and having a Scrum Master approve the plan on the team's behalf invents an authority Scrum does not contain.

One Product Goal is held at a time. When a board member arrives with a second objective and asks the Product Owner to run both, the answer is that the current one must be fulfilled or abandoned before the next is taken on — and abandoning it is a legitimate, deliberate decision rather than something that happens by quietly adding a rival goal beside it. Giving each goal its own section of the Product Backlog does not create focus, it divides it, and the constraint is not capacity: a backlog serving two futures can no longer be read as one route to one of them.

Charts are where the framework boundary gets misreported. Scrum has three artefacts — Product Backlog, Sprint Backlog, Increment — each with one commitment: the Product Goal, the Sprint Goal, the Definition of Done. Burn-downs, burn-ups and cumulative flows are named by the Guide as practices that exist to forecast progress and are often useful, and they are not artefacts of the framework. A programme office calling a burn-down mandatory because it is a Scrum artefact is wrong, and so is the more persuasive version of that error, which promotes the chart to being the Sprint Backlog in visible form: the Sprint Backlog is the Sprint Goal, the selected items and the Developers' plan for delivering them, and a burn-down is one optional picture of progress against that plan. A team concluding it must therefore stop drawing one has gone wrong in the other direction. Scrum is a framework other practices are deliberately layered on, and not being an artefact is not the same as being forbidden.

What those charts cannot do is turn the past into the future. When an analyst extrapolates a burn-up and tells a steering group that the remaining ninety items will take exactly eleven Sprints, so the dependent contracts can be signed, the soundest response accepts the evidence and refuses the certainty: the Scrum Guide states that "In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making." Measured data makes a projection honest about the past; it does not make the future knowable, because the work keeps changing what remains. The projection is re-inspected every Sprint, never signed. Asking the Developers to raise their velocity to meet the figure fails twice over — it converts a forecast into a target, and it puts the Scrum Master in charge of the team's pace, which is the fastest way to stop getting honest data. Sprint length is the real dial: shorter Sprints generate more learning cycles and limit the risk of cost and effort to a smaller time frame, so a team that has been badly wrong three Sprints running shortens the Sprint and caps how long the next mistake can run unseen. Shortening does not thin the Sprint out — every event still happens in every Sprint, which is where the extra learning actually comes from — and it is a choice about feedback and risk rather than a sanction imposed after a bad Sprint.

When Done work may actually go out

An Increment comes into existence the moment work meets the Definition of Done, which can happen many times in a Sprint — the Guide says plainly that multiple Increments may be created within one. Four separate pieces finished and deployed in a fortnight are four Increments, not a rule violation: each is additive to all the Increments before it and thoroughly verified, and the Sprint Review inspects what they add up to. Deployment is not what makes an Increment either — meeting the Definition of Done is, so the count would be the same had none of the four shipped. The Review is also not a release gate: an Increment may be delivered to stakeholders before the end of the Sprint, so a payment fix that is Done on day six can reach customers on day six. Presenting work and releasing it are separate acts, and the Sprint is a container for inspection and adaptation rather than an embargo on value.

Whether to release now is then a value judgement, and value judgements about the product belong to the Product Owner, who is accountable for maximising the value of the product resulting from the Scrum Team's work. Three Done Increments sitting behind a feature flag while the Developers want to ship tomorrow and marketing wants to wait three weeks for a campaign is exactly that judgement. The Developers decide how the work is built and whether it meets the Definition of Done — the closest miss in a question like this, because they do own a real decision here, just not that one. A Scrum Master picking the date has taken the Product Owner's accountability, and handing it to stakeholders at the Sprint Review replaces one answerable person with a committee.

The limit on that authority is the Definition of Done, and it runs in the other direction. A feature without the automated tests the Definition of Done requires is not almost releasable, it is not part of an Increment at all: the Guide says such an item "cannot be released or even presented at the Sprint Review", and it returns to the Product Backlog for future consideration. The Product Owner's accountability for value cannot make unfinished work releasable, because there is nothing there to release. Nor may the Developers relax the standard for one item — they are required to conform to it, and a standard suspended per item stops describing the product's quality at all — and logging the gap as an impediment is not a waiver, because a Scrum Master has no authority to certify anything as Done. Quality does not decrease during a Sprint.