Where Scrum Gets Dangerous: Potentially Shippable? Make Sure You Mean It

Scrum tells you to build ‘potentially shippable’ changes to your product (let’s call them ‘User Stores’) in fixed-length iterations. By estimating the relative complexity of delivering each of these changes using arbitrary units (let’s call them ‘Story Points’) you can measure how much estimated complexity was turned into ‘potentially shippable’ software over a fixed duration.

So far, so good. Where could it possibly go wrong?

One thing you may miss here, is how long changing ‘potentially shippable’ into ‘actually shipped’ might take. Building code and deploying it to a system test or user test environment where the business users can play with your changes might feel potentially shippable, but in the cold hard light of day, it still may be far from truly shippable, let alone shipped the fuck out. At this stage, the work you have done may seem to have some limited value to your customer in that they may poke around in it to help validate the work you’re doing, but until the day they can actually start using it to make their lives happier and more productive, that value is negligible.

You may choose to put stories into your backlog to cover off deliverables like ‘Deploy to Live Environment’, and ‘Hardening Sprint’ but these are high risk stories whose delivery tasks are very different to normal development work, and hence their velocity is hard to predict. Danger lurks here.

Better to make deployment to your live environment (or if that’s not possible, something very similar to it) part of your definition of ‘done’. If you decide to start doing this half way through your project, embrace your plummeting velocity, for it is your true velocity, and it is much less likely to make wildly optimistic predictions about your schedule.