Release Sprint
Imagine you are at the sprint review and the Sales Manager says “that looks good – I can sell the heck out of that – ship that puppy!” Now what? what do you need to do to get the system shipped, and how and when will you do it?
First of all, what does the Sales Manager mean when she says “ship that puppy!” anyway? Well, here is a list of things she might be expecting to see once the system is shipped:
- The product is available to users. It provides value, doesn’t break or blow up in their faces, meets performance requirements, and so on. 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, Google key words, and so on.
- Sales is able to sell the new version. The Sales System is updated to manage the sales, new sales forms exist, the website’s sales pages are updated, and so on.
How much of this is your team’s problem? What has your team done, what is it doing, and what must it do to make this happen? Good questions! In any case, It’s pretty likely that much (if not most) of this stuff has yet to be done, so let’s discuss how and when it might get done. To do this we need to understand the notion of “done” from a release’s perspective.
There are three definitions of “release done” that I’d like to discuss: ‘feature complete’, ‘code complete’, and ‘releasable’. We know that the Sales Manager believes that the system is feature complete; that is, it does what we want it to do in order to provide ROI. We’re not going to argue with that – she’s the boss!
What about code complete? Well, what does that mean? It means that not only does it do what we want it to do, but it doesn’t do what we don’t want it to do. The edge cases don’t blow up, and there are no surprises. It satisfies the “ilities” requirements, like security, performance and interoperability, and it just plain works.
And what about releasable? Well, in order to be releasable there is lots of other stuff we need: user documentation, training materials, sales and marketing materials, training and documentation for the help desk, and so on.
We need to move our system from feature complete to releasable, if it isn’t there already. If it is there, congratulations! You are one of the few, and truly special, teams, and need read no further. If it’s not there (like most of us), you need a Release Sprint. It is generally accepted guidance in the agile community that it should take no more than one Sprint to move from feature complete through code complete to releasable, and we call this sprint the Release Sprint.
The Release Sprint is at the end of the release to move the product from feature complete to releasable, and since most systems aren’t always in a releasable state, I am recommending it as a standard practice – at least for go-live releases. For alpha and beta releases we may release with lesser standards – we must determine that on a case-by-case basis. So, what sorts of things do we do in this release sprint? Let’s just look at the preceding paragraphs and make a list:
- Exploratory Testing to find what things need to be done – what holes need to be plugged – in order to assure that the system doesn’t blow up, the edge cases are handled, and there isn’t something else going on we don’t want it to do
- Performance testing (may need to be done in a test lab we don’t own) to find defects and holes to be plugged
- Interoperality testing (may need to be done in a test lab we don’t own) to find defects and holes to be plugged
- Plug those holes and fix those defects
- Finish User Documentation
- Finish Maintenance Documentation
- Finish Help Desk Documentation
- Finish Training Materials
- Support Marketing and Sales as they finish their documentation and materials
- Train the Help Desk to support the new system
- Other stuff – it’s up to you…
I’m pretty sure that this is more than one sprint’s worth of work for most teams, so you’ll have to actually be closer to releasible – at all times – than you really want to be, in order to be ONLY one sprint away from releasable (for example, it is my experience that teams that think they are ready are often 3-6 months away from being releasable). Of course, there is NO ROOM to defer additional work to this sprint – that way lies madness and sure failure! You and your team must realize that the “release” Sprint is NOT about adding functionality, it is not about doing work you deferred, it is only about coming to closure and making the product releasable once it is already feature complete!
Thanks, Dan ;-)
