11From refinement to commitment

Release planning happens a few times a year, so its mistakes are visible and get discussed. Sprint planning happens every two to four weeks. Its small mistakes become habits, and they accumulate. It is not the only place where Scrum teams are brittle, but it is one of the most important, for a reason that is easy to miss: the release forecast is built on sprint data. When sprint planning is careless, velocity stops meaning anything, and every forecast built on it inherits the error.

Good sprint planning is the end of a chain that starts well before the planning meeting.

Refinement comes first

Refinement is the ongoing work of preparing the backlog, a sprint or two ahead of need. The team and the Product Owner clarify stories, split them into vertical slices, write acceptance criteria, size them, and uncover dependencies. Where uncertainty is too high to estimate, they schedule a spike first. Earlier versions of the Scrum Guide suggested that refinement take up to about 10% of the team's capacity, a useful order of magnitude.

The outcome of refinement is a story that is ready: the team understands it, it is small enough to be finished within one sprint, and its acceptance criteria and dependencies are known. Some teams formalise this as a Definition of Ready. It is not part of Scrum. It helps as a shared checklist and harms as a gate, because a story is meant to be the start of a conversation, not a finished specification.

In the BECS example, "handle positive results" is far too large to plan as one story. Refining it before the sprint splits it into smaller ones: record a positive result, confirm it, publish the event, quarantine the components, defer the donor. It also reveals the dependencies on the Donation and Inventory teams, and the traceability requirements, before anyone commits to anything. Discovered in the middle of a sprint, the same facts would sink it.

The Definition of Done sets the price of "done"

The Definition of Done is the quality standard every increment must meet. Unlike the Definition of Ready, it is part of Scrum, and it is not negotiable from one sprint to the next. Three notions are often confused:

• Readiness: a story is clear enough to plan.
• Acceptance criteria: what this particular story must do.
• Definition of Done: what every increment must satisfy, whatever the story.

The Definition of Done matters for planning because it defines what "done" costs. Every story sized and selected must include all of it: tests, reviews, documentation and, in regulated software, traceability and verification evidence. When estimates leave that work out, velocity overstates the team's real speed, and the release forecast is wrong from the start.

For a BECS, the Definition of Done includes updated design documentation, traceability from requirement to test, verification records and an updated risk analysis. Done that way every sprint, the release is ready for the blood establishment's validation without a documentation catch-up phase. Skipped, it creates exactly the catch-up phase that makes release dates slip.

Compliance is everyone's work

Some products cannot be released when the team decides they are ready. A medical device must be cleared by a regulator before it reaches the market, and a blood establishment validates every new version of its BECS before using it. Banking and finance have their equivalents. In the European Union, the Digital Operational Resilience Act requires financial institutions to record, test, approve and verify changes to their information systems in a controlled way. In the United States, Sarbanes-Oxley audits cover the change controls on systems that support financial reporting. Whatever the sprint cadence, no version reaches users before those steps are complete. The release plan must therefore include them, with their lead times, like any other dependency.

Staying compliant is not a phase handed to a quality department at the end. It involves every party. The Product Owner orders regulatory work in the backlog and plans releases around submissions. Quality and regulatory specialists define the evidence the regulation requires. The Developers produce that evidence as they build, sprint after sprint. A Scrum team that treats compliance as someone else's job builds a product nobody is allowed to release.

Done includes what keeps the product alive

Long-lived products add a second reason to widen the Definition of Done. A BECS stays in service for many years, and the people who maintain it in ten years will rarely be the people who built it. Architecture decision records, up-to-date design descriptions and the reasons behind important choices are what keep it maintainable. Including them in the Definition of Done costs a little every sprint and saves a great deal over the life of the product.

The Sprint Goal gives the stories their meaning

Sprint planning starts with why. The Sprint Goal is an increment that makes business sense to the people who will use the product. The stories are the steps that build it. Completed together, they are the materialisation of the goal.

The goals form a chain: the product goal gives meaning to the release goal, the release goal to the Sprint Goal, and the Sprint Goal to the stories. Each level answers "why" for the one below it. A Sprint Goal that reads "finish stories 12, 15 and 18" breaks the chain: it describes activity, not an increment anyone could use.

During the walking skeleton, a Sprint Goal might be: "a collection nurse can register a first-time donor and record his whole blood donation". The stories behind it are register a donor, record the questionnaire, record the donation and assign the donation number. A nurse would recognise the goal as useful. Each story on its own would mean little to her.

"Makes business sense to users" does not mean "released to users". The increment is shown in the Sprint Review to people who represent the users, staff from a blood establishment in our example. It reaches customers only with the release.

Selecting the work and planning the how

With the goal set, the team selects the stories that serve it, within its real capacity: holidays, support duties and known meetings come off before any work goes in. Measured velocity sets the order of magnitude. The enablers and supplier commitments placed in the release plan are included without competing again with features: they were prioritised at the release level, for reasons of risk and dependency. The team then plans how it will do the work. That plan belongs to the team and is revised every day. It is not an assignment list.

Commit to the goal, forecast the stories

I believe the 2011 Scrum Guide replaced the word "commitment" with "forecast" for the selected stories, and the 2020 Guide made the Sprint Goal the team's commitment. The distinction is useful. The team commits to the goal and forecasts the stories. If, during the sprint, a story proves unnecessary or a different one is needed, the team and the Product Owner adjust the stories and keep the goal. A sprint succeeds when its goal is met, not when every selected story is ticked off.

Errors that accumulate

Each of these errors looks minor in a single sprint. Repeated every two weeks, each one feeds the next.

• Refining during planning. Planning becomes a long discovery meeting, and stories enter the sprint half understood.
• Planning to 100% of capacity. Holidays, support and the unexpected are ignored, so stories spill over, sprint after sprint.
• Silent carry-over. Unfinished stories roll into the next sprint without discussion. The next sprint starts with less capacity than it believes, and velocity loses its meaning.
• A weakened Definition of Done. "We'll write the tests next sprint." The undone work becomes hidden carry-over, worse than the visible kind because nobody counts it. Teams then schedule "hardening" sprints before a release, which is the debt being paid all at once.
• Stories that are too big, or split by technical layer. Nothing is finished until the last days of the sprint, and the sprint becomes all or nothing.
• No real Sprint Goal, or a goal that is only a list of stories.
• Dependencies discovered during the sprint rather than during refinement.
• Invisible technical work, squeezed out or hidden inside feature estimates.
• A Product Owner who selects alone. The developers do not own a plan they did not make.
• Filling everyone's calendar instead of aiming at a goal.

Signals worth watching

• How often Sprint Goals are met.
• The share of stories carried over from one sprint to the next.
• Stories added during the sprint.
• Stories reopened after being marked done, and any sprint devoted to "hardening".
• How long sprint planning takes. A long meeting usually means refinement was skipped.