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
4 comments:
I think that stabilization periods really can't be avoided, especially if you take into account other things outside of core delivery necessary to productize a piece of software.
This includes things like change management and training, risk and liability, marketing, etc.
I don't think teams should be using stabilization as an excuse for things like defect fixing, performance testing, etc. Yes this will happen in reality, but it should be acknowledge as a temporary bad practice, not something that should be used over the long term.
Once agile starts taking a more holistic scope using things like lean then I would expect stabilization iterations to go away.
I fully agree with your views posted here and it's actually a realty that most of us are not fully following the SCRUM but instead try to adapt to our own needs.
For us also, the output of sprint is not a potentially shippable product but only the Tested Feature that doesn't include full testing like performance & acceptance which as you rightly stated are passed on to the stabilization sprints.
Another risk is that most of the defects are left open from each sprint taking in account that these can be anyways fixed during the stabilization, which I feel is really a bad practice as it accumulates the Quality Debt.
I really want to understand how we should move close to reality of Agile !!
Sonali,
Thanks for your feedback. Answering your question on how do we move close to reality of Agile, my answer would be, Agile is all about getting early feedback, continous learning and making adjustments. These simple rules can make a lot of difference.
My solution to this problem has always been to actively discourage back-to-back iterations, especially early on when everything is new and you have few stable bases.
I typically start a project with a three-week sprint pattern; two weeks developing stories and one week clean-ip (stabilisation). This seems to work well and after four or five Sprints, the need for stabilisation time tends to go down. Provided we have things like contiunous integration and automated regression set up, we can usually move to a two-week back-to-back pattern.
Try it.
Post a Comment