Chances are you’ve been there. You’re planning a sprint with your team and you know the stories are too big to be completed within the sprint. You propose a way of breaking the stories down, only to be told your breakdown is no good because each story no longer has business value or customer benefit. Worse yet, you’re told the Product Owner is the final arbiter of determining if a story has value, regardless of the interests of everyone else in the product development community.
Or maybe less overtly, you’re writing stories using the ubiquitous “As a _, I can _, so that _” template. You’re told the “so that _” part of the template has to define business value or customer benefit. Again, that leads to stories you know are too big to be completed within the sprint.
Obviously, delivering products with business value and customer benefit is essential. But dogmatically applying a rule requiring every single story delivered in a sprint to have business value or customer benefit on its own can cause havoc for a product development community. Some of the possible resulting problems include:
- Carrying over incomplete stories from sprint to sprint, inhibiting your ability to measure progress and measure product learning.
- Building up a testing deficit and defect backlog.
- Delaying learning from user feedback.
- Missing out on the discovery that often comes from integration and testing.
- Adding risk by failing to validate architecture and design ideas until later in the delivery cycle.
Most of the time teams that are caught in the story size vs. value trap are overly focused on process. There are techniques available to help us create small stories while staying focused on delivering value for the product, without getting trapped in the dogma of blind adherence to process rules. I’ll be exploring these techniques including personas, journeys, story splitting, and incremental delivery of complex algorithms in the subsequent posts in this series.