Now look at all the scenarios you have. Does the product owner really want you to build the product to satisfy all of them? Can you cut any out and defer them as another story to build later? Can you drop any of them altogether? Get rid of as many as you can until the story is as small as you can make it.

Now count how many scenarios you have left, and write that number on the story card. At the end of the iteration, count up how many scenarios you’re managed to deliver in total across all the stories you’ve done, and start using that as your velocity metric. It’s much, much more accurate in my experience than estimated story points. What’s more, the process of exploring the scenarios means you can agree a clear scope for the story before you get started.

Teams who are doing this well are getting things done much more quickly than they did before. Not only do they build a suite of automated regression tests, but they waste a lot less time writing the wrong code because of misunderstood requirements.

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.