Shipping the release: from accepted work to customers

The Sprint Review went well. Stakeholders liked what they saw, the Product Owner accepted every story, and then nothing reached a user for six weeks because nobody owned the step between "accepted" and "live". Releasing is its own piece of work, with its own risks, and it deserves a name and an owner.

Done, accepted, released

Three words describe three different states, and mixing them is the source of most release confusion.

• Done. The work meets the Definition of Done. In the Scrum Guide, that is the moment an Increment is born.
• Accepted. In the SBOK, the Product Owner has reviewed the story against its acceptance criteria and approved it.
• Released. The work is in the hands of the people it is for.

The Scrum Guide is explicit that these are separate. An Increment may be delivered to stakeholders before the end of the Sprint, and the Sprint Review should never be considered a gate to releasing value. The decision to release belongs to the Product Owner, whose accountability is the value of the product. Our post on the Increment draws the line between making and releasing.

The SBOK® Guide's Ship Deliverables process picks up where acceptance ends. All deliverables from accepted user stories in the completed Sprints are delivered or transitioned to the relevant business stakeholders, and a formal Working Deliverables Agreement documents the successful completion of the release.

What a release needs

The SBOK lists the things that make a release more than a deployment.

• Accepted deliverables. Only what has passed acceptance is shipped. Work that did not meet the criteria stays on the Product Backlog.
• The release plan. The schedule from release planning says what is shipped and to whom.
• An organisational deployment method. The SBOK observes that deployment normally carries real risk, so organisations have established processes, which may include sign-offs by named managers, user approval and rules about minimum functionality. Follow yours, and if you do not have one, write a short one.
• A communications plan. Who is told what, and when, and who does the telling.
• Release content and release notes. Information that helps the customer support team and says what is being delivered. The SBOK describes release notes as external or market-facing shipping criteria.
• A pilot, where it matters. The SBOK mentions a pilot plan that sets out the scope, the target users, the schedule, the transition arrangements, user preparation and the criteria for judging the pilot.

You do not need all of it for every release. A weekly deployment of a small web feature needs far less than a first launch to paying customers. The checklist is the thing to keep, not the paperwork.

The formal acceptance

The Working Deliverables Agreement is the SBOK's output for formal business sign-off by the customer or sponsor. The SBOK says that obtaining formal acceptance for each working deliverable is essential for revenue recognition, for accepting the project results and for fulfilling the project's objectives.

For a team working inside a contract, or selling to a client who pays on acceptance, this is a practical necessity. The Scrum Guide says nothing about it, because it describes the team's work and not the commercial arrangements around it. If your organisation requires a signature, ask for it, and make it quick: a short document that lists what was delivered against what was agreed is better than a long one.

Why pilot first

A pilot is a limited release to a small, friendly audience. It lets real users meet the product while the cost of changing it is low. The SBOK's pilot plan is the structured version, but you can do a light one:

1. Choose a small group who will tell you the truth.
2. Say what you are testing and what would count as success.
3. Set a short period and a way to collect feedback.
4. Decide beforehand what would make you stop or roll back.
5. Review the findings at the next Sprint Review.

A pilot also helps the people on the receiving side. They find the gaps in their own preparation, such as training, support scripts and access, before everyone is affected.

After the release

Shipping is not the end of the work. In the first days after a release the team watches what actually happens: errors, support questions, how people use the new thing and what they do not use. That evidence is some of the best the team will get, and it belongs in the backlog. The Scrum Guide's emphasis on inspection and adaptation applies here as much as inside the Sprint. The next Sprint Review is a natural place to report what the release taught, and the Product Owner can reorder the backlog accordingly. A team that ships and moves on without looking has skipped the part of the loop that makes releasing worth doing.

A worked example

An invented case. A library network has a booking system accepted at the end of the fourth Sprint. The Product Owner decides to release it to one branch first.

• Before. The team writes brief release notes, a one-page guide for front-desk staff and a rollback plan. The communications plan names who tells the branch, and when.
• Pilot. For two weeks, one branch uses the system. Staff report that the confirmation message is easy to miss, and two bookings overlapped because of a time-zone setting.
• Fix. Both are small. The team fixes them in the next Sprint and tells the branch.
• Release. The Product Owner releases to the other branches, with the release notes updated. The sponsor signs the delivery agreement.

Nothing went wrong in a way that mattered, because the places it could go wrong were small.

Common mistakes

• No owner for releasing. If everybody assumes someone else is doing it, nobody is.
• Using the Sprint Review as the go decision. The Guide separates them on purpose.
• Releasing without telling the support team. They will learn about the change from a customer.
• No way back. Decide the rollback before you ship.
• Shipping everything at once. A big bang combines all the risk in one moment. Smaller releases spread it.
• Skipping acceptance in a contract setting. The commercial cost of a disputed delivery can exceed the delay.
• Treating the release as the end. The team learns the most after real users arrive.

The Agile Manifesto principle to deliver working software frequently, with a preference for the shorter timescale, is the argument for releasing small and often.

How to practise it

In the simulator, the fifth phase ends with a cutover: the Product Owner authorises the release and the Sponsor accepts the deliverables. The cutover cannot be undone, so the decision to execute it is a real one.