Photo by Max Delsid on Unsplash
What is User Story Slicing
Slicing stories properly is critical to keeping your project agile. In my article about Epic User Stories I discuss the idea of story decomposition, this is what slicing is all about. User Story slicing is the process of decomposing large stories into small stories. The word “slicing” is very apt for this exercise. Properly decomposing stories means ensuring that the smaller stories continue to deliver value - end user value, not just technical value. Like slicing bread, no matter how thickly or thinly I slice it, I should still be able to make a sandwich.
DO NOT decompose a story into stories based on the tasks, and avoid creating ‘foundational’ stories. If you do this you are not working in an agile manner, you cannot get user feedback on this work, you cannot deliver direct business value with it and you are avoiding steps in the end to end process. There are other, better ways to slice your stories.
Horizontal and Vertical Slicing
Horizontal slicing is base on the traditional way that systems were build using waterfall project management. Starting with the requirements written into a functional specification signed off by the customer. Then a big, up front design is create based on the design and the build follows the same pattern starting with foundational pieces like infrastructure, databases, application servers and the application client (which is what the users interact with). Finally, this all goes to the Quality Assurance testers who then create test cases, and test the system. Once the system is stable enough it is deployed to production, taken over by operations and the project is complete.
Construction projects, and many other types of hardware projects work like this. It’s a very logical and comforting approach, easy to comprehend and leaves nothing to judgement. It’s also very efficient (or should be if you get everything right the first time).
However, all the functionality of the system is delivered at the end, leaving no room for iteration and change. We know this is NOT an agile approach. Yet I see many backlogs sliced in this way. I think it’s just really hard to escape horizontal thinking because horizontal slicing is how we do most things in life.
For example, when I prepare a meal, I figure out what I want to serve, get all the ingredients, prepare, cook and serve the meal. When I buy a car, I determine my needs and budget, do the research, test drive vehicles and buy the car I want at the lowest price I can get. We don’t live life iteratively, or if we do it’s project by project. If my meal doesn’t work out, I choose a new recipe. If my car is a poor choice, I sell it and choose something else and I go through the whole project process again.
Agile doesn’t work with horizontal slicing, so we use vertical slicing. Be warned - per my examples above, vertical slicing requires unorthodox thinking. The vertical slicing versions of my examples above would look something like this. If I was preparing a meal like steak and salad, I would cut a small section of the steak, say an ounce of meat, and I would mix an eight of my salad ingredients and combine a mini version of my dressing. I create a mini meal, only a few mouthfuls, but enough to get an idea of the taste. I reflect on this attempt and come up with possible improvements and I create another mini meal with the improvements until I can’t improve it anymore or I lose patience and declare my recipe ‘good enough’ (this is know as ‘Minimum Viable Product’).
For the car example I would need to be able to borrow or rent a car for some small amount of time, learn from it and choose another car that I think might be an improvement until I find the one that works best. Very unorthodox, what dealership would put up with this! But this is what agile thinking demands of us.
Applying vertical slicing and the agile approach to life is pretty awkward and un-natural. To make matters worse iterating is also very inefficient! Going through the same actions over and over instead of just getting it right the first time adds a lot of overhead. Cooking an 8 eight ounce steak all at once is much more efficient than cooking 8, 1 ounce steaks one at a time. Mentally, we fight the vertical slicing approach. So why does agile work this way? Because although it is less efficient, it is much more effective and far less risky. The end result is better, much better.
To describe vertical slicing for software systems, I’ve created this diagram.
Techniques for Slicing
Every story should have some business value, some benefit to a customer of your system. There should something a customer can see and comprehend. A database table, or a network diagram is probably not tangible enough for a customer to comprehend. A UI mockup might be understood by a customer but it doesn’t have realizable business value. Its value won’t be realized until it is implemented into a functional application.
There should be a list of acceptance criteria as part of a story. These are things like user input validations, UI functionality like fading, sliding, popups and hover states. Happy path and exception path scenarios and handling and other ‘mini’ functionality are also part of the acceptance criteria. In my post on Agile Epics I use an example Epic for a search function. The acceptance criteria includes auto-complete and search filtering. I consider these things to be mini functionality.
The story meets the I.N.V.E.S.T. criteria. This is:
- Independent - If other stories need this one, slicing it up may break these dependencies
- Negotiable - If you can’t negotiate it, you can’t slice it
- Valuable - We covered this already
- Estimable - You are probably slicing because the story has been estimated a large
- Small - This is why we are slicing
- Testable - If the story has value to end users and acceptance criteria that ensures this value, it is likely testable
Slicing by Acceptance Criteria
A User story should have a core of business value essence. Let’s go with the web site search story
As a User looking for specific site content
I want to browse a list of pages that contain content relevant to my search term
So that I find the specific content I need
The first acceptance criteria should describe this core. For the search example, the core might be
When I enter a search term in the search box,
Then display a list of page titles with words in the page content that contain that term
Note the extreme focus of this acceptance criteria for my search story. This criteria does not mention partial search terms or synonyms. What if the user doesn’t enter a search term, but they press the search button? As a Product Owner I would add a separate acceptance criteria for this scenario, the core criteria can stick with the default behavior.
When I enter an empty search term and attempt to run the search
Then the search does not run
And a message is displayed indicating that a search term is missing
Oh, and we want the list of results to be ranked by relevancy, and this will simply mean pages where the search term appears more often should appear higher on the list.
When a matching result page has more words matching the search term
Then that page is listed ahead of pages with fewer matching terms
And pages with a tied number of matches are sub ranked by the page publish date, newer pages higher
For the sake of the example, let’s stop with this.
So we have a User Story here with 3 acceptance criteria. You can see that the acceptance criteria is functionality too. It can quite naturally be extracted into its own story.
As a search user in a hurry
I want the search to prevent me from accidentally attempting to run the search without a term
So that I don’t waste my time looking at empty search pages
We have sliced the search story into 2 stories, both stories have value, but are now smaller, easier to estimate, build, test and deliver.
Decomposing Acceptance Criteria
In the search example there are some acceptance criteria with And statements. The and statements were added because a scenario came to mind and an expected behavior was needed. No, after the fact, these And statements provide an opportunity for further slicing.
Let’s pull the And statement out of the results relevancy sort into its own acceptance criteria
Given results are sorted by relevancy
When there is a tie
Then the page with the most recent publish date is listed first
This now gives us an opportunity to extract the 2 acceptance criteria into new stories, further decomposing the search story smaller.
Simplification through deeper understanding
Slicing acceptance criteria is pretty straightforward and I would start with this approach. But you might take this as far as you can and still have a large story to deal with. For example, the most basic of functionality may still require a lot of effort to deliver.
This is where creativity is required and a deep understanding of user needs.
Let’s say our core search function is too big. Does it need to be this sophisticated. What if we know that there is one term that users are going to look for most? What if we ask some of the site customer and they say they would search for the “On Sale” items.
We can create a new story -
As a user looking for On Sale Items
I want a clearly visible link to the list of on sale items
So that I can browse the list of current on sale items
Now our search is starting to look more like a navigation, but that’s fine because we are focused on achieving a result not on implementing a search.
Overcoming Mental Hurdles
The search story has been significantly decomposed, each story describes a very specific scenario yet still preserves some usefulness
Understand that stories shouldn’t describe a complete user experience or cover every scenario. You most likely can’t deliver a single story to a customer. But does a single story have business value? Yes. Yes it does. And I think this is another place where story writers get hung up, they get stuck trying to make sure a story covers all scenarios.
Try to avoid fixating on solutions. Instead, fixate on results. In my search example, through deeper understanding of the customer needs we de-prioritized the search and instead created a simpler story that met the majority of the customer need. While I was writing up that example I could imagine hearing a partially involved manager asking if the search is done yet and when we expect that to be finished, and then having to explain that 80% of the result that the search would deliver HAS been implemented and that it cost far less. This is a huge win for the project, make sure you explain it this way.
Slicing stories starts with a good understanding of story writing. Understanding that stories aren’t tasks. Tasks are just the actions needed to implement a solution. Stories describe a result for a customer, why that result is valuable, and stories suggest a proposed solution to achieve that result.
Sliced stories describe one tiny piece of the whole, but still stand on their own, they still include a piece of the end to end functionality. Every horizontal layer of the delivery is included. These layers make up your Definition of Done.
When slicing, keep the principle of customer business value in mind and don’t get hung up on completeness or perfection. Completeness comes iteratively, sprint by sprint. Agile is about effectiveness and achieving great results while reducing risk.
Photo by Max Delsid on Unsplash