TL;DR — While it’s good to think big, we need to act small, especially when we iteratively measure value in a CI/CD software release setting.
When I think of a small Product Backlog Item (PBI), I’m thinking of one that is reduced enough that one or two developers can get the work done and deployed in a single sprint, and that delivers something whose value is measurable.
If we’re looking to contrast this against something, then perhaps there’s no better example in the extreme than those wretched IEEE 830–1998 Software Requirements Specifications that usually resulted in ‘Death Marches’ where at best only 15.125% of the features delivered are adopted.
Somewhere in between all this lie Epics and Feature Stories you’re likely dealing with, which also likely need to be decomposed into smaller PBIs of value that can be completed in a Sprint.
Regardless of how you cut’em, I’ve provided Y’all this handy-dandy visualization in the form of a very agile Goofus and Gallant comic that you should feel free to share with your friends and product managers:
Still, need more convincing on the importance of small product backlog items? Sure, no problem. Here are eight more reasons to atomize your stories:
- Developers will love you because they don’t have to boil the ocean;
- Quality Assurance will love you because the acceptance criteria are finite;
- Release managers will love you because there’s less risk during integration & deployment;
- Marketing and sales will love you because they’ll have a shiny new object;
- Customers will love you because you’re providing valuable stuff sooner & with greater frequency;
- Customer Success & Support will love you because they’ll be able to learn & turn things around faster;
- Upper management will love you as your estimates will likely be more accurate; and
- You’ll love yourself as you shorten the build-measure-learn cycle in your favor.
How you slice your stories into smaller units depends on multiple factors. Here are three tactical questions that quickly come to mind. Feel free to add your own in the comments:
- What is technically feasible for the developers?
- What is functionally useful to the customer?
- What is measurable so you can learn and build?
How to …
What are some process considerations that will put your organization in a better place to create small slices of valuable and measurable functionality? Here’s seven off the top of my head:
- Always understand the who and why behind the feature.
- Utilize feature flags, especially feature toggles coupled with group rights.
- Implement a modern release train that supports small branches, like GitFlow.
- Deploy continuous release tooling, like Bamboo, Jenkins, or TeamCity.
- Get into a regular cadence of “show me” events and instances.
- Employ test automation at all levels.
- Field an early adopter/private beta program.
- Add a simple enumeration of guardrails of what the individual story will address, and what won’t be addressed, or what might be addressed in the immediate sprints to follow based on feedback & discoveries.
BTW, it wouldn’t hurt to have some conversations along the above list of 7 optimizations with DevOps, release managers, and others who help define the sausage making process.
Still want to learn more about ‘what’ and ‘how’ smaller PBIs mean to your team delivering value? Perhaps these additional articles on the topic will help:
- Small Agile User Stories Reduce Variability, Increase Predictability
- 9 Reasons to Slice User Stories Better
- How to Split a User Story (includes a useful graph)
- Story Slicing, How Small is Enough?
Feel free to leave comments on your own approaches to slicing-n-dicing stories. Liking and sharing the story wouldn’t hurt. As always, feel free to disagree.
OH, and if I don’t get any claps, then you can forget about any more ‘Very Agile’ Goofus & Gallant comic strip shenanigans. You’ve been warned.