Thursday, November 19, 2009

Potentially Shippable product – A Myth or Reality ?



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.


  • 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

Thursday, November 12, 2009

Continuous Deployment – What is the limit ?

discrimination I have heard about project teams still coming upto speed on daily builds and many are still living with nightly builds. 

For many continuous integration is still a dream. It is a proven that practice like building and testing the code continuously helps to improve the ROI in the long run. 

What about Continuous Deployment ? How many times a can you deploy ?   Even though setting up build and continuous integration is one time effort, it is the discipline that makes the build and continuous integration process to work.  If you want to learn about such a disciplined system,  read how the continuous deployment is done fifty times a day at IMVU from here