Dushy had heard of Stabilization Sprints and wondered if they were norm in the Agile world. Stabilization sprints are an additional number of sprints added to the end of the normal development cycle before shipping the product. As the name suggests, they’re usually added to shake down the product one last time and drive the last of the bugs.
Ilja Preuss says that: “A stabilization sprint is a sign that your definition of done is incomplete or not followed.”
Sarath Kummamuru suggests that he sees some cases where stabilizations sprints are appropriate:
1. Taking care of technical debt that might have accrued due to the hurry to complete a sprint! (basically re-factoring existing code bases or may be improving unit test coverage, etc).
2. Take care of QA debt that the teams might have accrued because of lack of complete automation and regression every sprint. Very common with companies working on legacy code bases which do not have as much automation.
3. Testing and certification of the product that is being released on various platforms (say to certify it on different application servers, to certify that the product is working on different OS Platforms, etc).
4. If there is any packaging that needs to be done (say CDs to be released, etc) these are also typically done in these release/stabilization sprints.
This reporter noted that accepting stabilization sprints as necessary is akin to giving people a crutch and never helping them to walk again. It may take years to automate the testing of all the existing code but that’s no excuse to live with the current state of affairs. In addition, any code that doesn’t have automated acceptance and unit tests is of unknown quality. We don’t know if there are bugs hiding in there - effectively it's waste (from a lean point of view).
Edward Arunaj notes: “Typically if anything were pending then we are accruing debt. Many times you may need more than 1 sprint for stabilization and that can lead to unpredictability of the release. (stakeholders dislike unpredictability more than delay)”.
Mark Woyna gives an example where it's not currently economically viable to eliminate stabilization sprints. In this case the test environment has 800 servers (worth several million dollars), needs to perform 300,000 operations per second. Tests on these servers take 3-4 weeks to run as the teams need to simulate what happens as an upgrade is rolled out slowly across the servers. However Mark points out this is special case: “I agree with you that work performed during a stabilization sprint is simply work that wasn't done … If the software is defective, you'd rather find out earlier,
rather than later”
Finally, Steve Gordon says:
Fixing the root causes of this defective work is what will improve things. Yes, we also need to fix the immediate problem, but if that is all you do, the problems will recur and you will always be living with incomplete work and 'unexpected" defects.
Accepting "stabilization sprints" as a regular, normal practice is just fixing the immediate problem and accepting that the same kinds of problems will occur again.
Previously on InfoQ: Does "Done" Mean "Shippable"?