Potentially Releasable Product Increment

Ship ItThe Potentially Releasable Product Increment – everything in scrum revolves around it.  The purpose of every scrum role, artifact and event is to maximize the value the business can realize from the increment.

There are three main issues that tend to come up when discussing Potentially Releasable Product.  The first is that the business doesn’t want to release every sprint.  Well that’s fine, the first word is potential – that means it doesn’t have to be released but the business will have the opportunity to decide every sprint whether it wants to release.  This makes releasing a purely business decision that the development teams don’t have to be involved in.  All the development team has to say is “this is what we’ve done, do you want to release it?”

The second issue is the debate over whether there is a difference between potentially shippable and shippable product. In the ideal situation there would be no difference as this would give the business the most flexibility and the greatest chance to deliver value sooner.  In reality a lot of businesses still have a ‘release sprint’ or beta process that occurs between achieving potentially shippable and actually releasing the software.  For these companies just achieving Potentially Shippable Increment by this definition can be a big enough challenge.  But once you have reached this goal I recommend that you continue to push boundaries and remove barriers to achieving true potentially shippable increments. I find it’s better to take this rigid approach because it encourages continual improvement over compromise.

The final argument made is that it’s inefficient to have Potentially Releasable Product every sprint.  The people who make this argument like to suggest that breaking work into sprint-length sections leads to double-handling and code having to be written and then refactored every sprint.  This can be true but I think in general these are actually benefits. Developing in this way tightens the feedback loop and allows the requirements to develop with the code instead of diverging completely.  Iterative development in general leads to more flexible code and means we can waste less time making something that isn’t wanted after all.

Finally the activities that are usually completed for a software release are tedious and repetitive and there is no better way to get something automated than to make someone repeat a tedious task often.  Thus in the long run we waste less time by making the release process more efficient.

Whatever you decide Potentially Releasable Product means for your company, the document where you will define this is the Definition of Done.  I find asking yourself “What do we need to have and what do we need to know about the software in order to release it?”  In general it’s best to focus on questions where there is a clear answer with no room for debate.  It needs to be obvious for each Definition of Done criteria what needs to be done in order to achieve it.  Don’t forget that this includes quality requirements too!


Related Books:

Software in 30 Days
Ken Schwaber
Jeff Sutherland
2012
User Stories Applied

Mike Cohn
2004
Discover to Deliver

Ellen Gottesdiener
2012
Converge
Bob W Lord
Ray Velez
2013


Categories: Artifacts

Tags: , , , , , , , , , , ,

1 reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: