Imagine you are the Team’s Product Owner at the Product Review and the Sales Manager says, ‘That looks good! I can sell the heck out of that. Give it to me NOW! Ship that puppy!’
Now what? Are you going to say: ‘I’m sorry, we’re not planning to deliver this System for ten more weeks.’ Of course not! You’re in the value-delivering business. You’ve got to figure out what you need to do to get the system shipped.
This is a tough situation. What do you (the Product Owner) do? You have a Done Increment consisting of Clean Code (like you do at the end of every Sprint), and your Stakeholders think it’s feature complete and want to get it released and out the door.
Problem solved. Since this thing is Done, and you need to ship it, you just put a ‘Ship It’ Story in the next Sprint. Right? Or maybe you step outside the Scrum Framework and ship it before the next Sprint.
Hold up. Your Scrum sense is tingling. Maybe you’d better step back for a minute.
What does the Sales Manager mean when she says ‘Ship that puppy!’ You realize there are many things she might be expecting to see once the system is shipped:
- The product is available to users – it moves from the Development Environment to the Production Environment. It provides value, doesn’t break or blow up in users’ faces and meets performance requirements. It has accurate documentation, and the Help Desk is prepared to answer questions about the new version.
- Marketing has new materials, and the marketing plan is implemented, including advertisements, YouTube videos, and Google keywords.
- Sales can sell the new version. The Sales System is updated, new sales forms exist, and the website’s sales pages are updated.
The ‘Ship It’ Story in the next Sprint might not be so simple, maybe it’s an Epic, maybe it’s even bigger than that. To get this thing shipped in the next Sprint, you decide that the Goal of the next Sprint will be: ‘Get this puppy in the hands of users this Sprint!’
Voila! A Release Sprint is born.
Introducing the Release Sprint
A Sprint with the goal of releasing product is called a Release Sprint. A Release Sprint is different from other Sprints in a couple of ways:
- The System is already believed to be feature complete, so there is no additional functionality that we know we need.
- Anything we discover during the Sprint that is necessary for Release must also be done within the Sprint. This is risky, as we don’t know what we’ll find.
- Since we’ll be Releasing during the Sprint, there will be no Product Review before we release it. The work done in the Sprint should be low risk and have frequent reviews (from SMEs) during the Sprint.
What does the Team actually do in the Release Sprint?
To understand what needs to be done, we need to understand the notion of Done for a Release, which is different from the Definition of Done for a Story or Sprint. For a Story or Sprint, Doneness means the Team has done its due diligence. The product meets its Acceptance Criteria and Definition of Done. There are high-quality Results and Clean Code.
Releasing something is not a Scrum ceremony; it’s done with Stories within a Sprint. Consequently, the definition of Done for a Release might not be clear, and you (the Product Owner) need to negotiate it with your Stakeholders.
Identify the Undone Work
The product is feature complete and code complete. But, is it actually Releasable? Meaning, is it fit for use as it stands? No. It is unlikely that the Help Desk is prepared to support it, that Marketing has materials that reflect the latest and greatest features, or that Sales can manage the new Product.
The difference between being Done and being actually Releasable is often called Undone Work – work that was not done, but maybe should have been.
Populate the Release Sprint Backlog with Undone Work
You review the list of expectations from the Sales Manager and put these Items in the Release Sprint Backlog:
- Complete testing in a test lab that the Team doesn’t control.
- Exploratory Testing to find what things need to be Done.
- Performance Testing to find defects and holes to plug.
- Interoperability Testing to find defects and holes to plug.
- Plug holes and fix defects.
- Finish User Documentation.
- Finish Maintenance Documentation.
- Finish Training Materials.
- Support Marketing and Sales as they finish their documentation and materials.
- Train the Help Desk to support the new system and finish any documentation they may need.
- Move the System from Development to Production.
- Other stuff that the Team identifies.
This Backlog is potentially a lot of work. If you want it to complete it in a single Sprint, the Team shouldn’t wait until the last minute to start this work. The Release Sprint occurs when the Team does the last bit of this work before the Release.
To be (predictably) able to release the Product one Sprint after the Business has said it’s good enough, the Team needs to practice Releasing. By doing release activities early on, the Team reduces surprises and creates reasonable expectations. This practice prepares the Team to understand how much of each of these Release Activities it can defer to the Release Sprint, and how close to actually releasable they need to be at all times.
Release practicing may take a whole Sprint, and most Organizations and Teams don’t want to waste a non-Release Sprint practicing Releasing. This is a reasonable decision because the ROI of spending a Sprint to practice Releasing may be seen to be less than the ROI of using that Sprint to add new features to the Product. However, it has been my experience that Teams that think they are only one Sprint away from Release are often actually three to six Sprints away. The only way to know the truth is to do it and see.
It may be a tough call for a Product Owner (and the Business) to make. But it is part of the Product Owner’s due diligence to have the Team practice to become predictable. The more practice a Team has going from feature complete to released and out the door in a single Release Sprint, the better.
Want more tried-and-true insight for your Release Sprints?
We’ve got training for that.
As Always, Stay Agile.