Scrum defines that, at the end of each sprint potentially shippable product (PSP) should be ready.
Ken defines this product as
Sashimi, a thin slice of product which contains all aspects of the product
Let us closely watch the iterations/sprints happening around us and do you see a sashimi kind of product at the end of each sprint ?
I have not seen many …
Most of the times I have observed that the sprints end with all the features being coded but testing, defect fixing spilling over to next sprint. This results in not having a potentially shippable product. There could be many other reasons in addition to the above but time and again, Agile projects end up with incomplete sprints and that is the reality.
You might ask, if each sprint ends up with an incomplete work, when can we see a stable product ?
Answer is the work around invented by the thought leaders. It is called Stabilization sprints.
What are stabilization Sprints ?
These are sprints dedicated towards tasks such as
Defect fixing Fixing technical debts Completing any final rounds of testing Update or fix any architectural issues Getting ready for the release by completing release notes, etc
Stabilization sprints can be scheduled based on the need of the hour. There is no hard and fast rule around when it should be scheduled.
Many people call stabilization sprints with different names based on the specific activity being executed. Some names are, Testing Sprint, Technical Debt sprint, Analysis Sprint, etc
Is it a right approach to have stabilization sprints ?
Some people believe that Stabilization sprints are Scrum’s Anti Patterns. The suggestions given at various places to solve this anti pattern is to define Done properly. The product owner is expected to set the right expectation for the team during the planning meeting through Done.
Conclusion
- It needs a lot of discipline to deliver a potentially shippable product during each sprint.
- Even though stabilization sprints are not recommended, it seems to be the reality
