Slicing User Stories. Make the Customer Happy — The Good and the Bad Way

Introduction

In one of my last posts, I wrote about estimating the Sub-Tasks of User Stories to billing external suppliers. In this post, I'll write about slicing resp. splitting User Stories.

Actually, this post results from a follow-up conversation of the Sub-task estimation discussion I had in my Scrum Master community at the client site. I suggested as an alternative to point-based billing instead to bill the Full-time equivalents engaged in implementing the relevant User Stories. And I pointed out, that the User Stories should be sliced to a size that fits into the Sprint in question. For User Stories having multiple slices, all slices should be prioritized, and each slice can be sold resp. billed as "further enhancement". — And surprise, surprise, one of the benefits of agile, explorational work, after receiving some enhancements the customer may say: "We had 5 enhancements planned, but I'm happy with the 3 rd one. Let's cancel the others!"

To my proposal, one of my colleagues replied: "Yes, our guideline is always to split Story/bug/defect to one or multiple tasks, so we get those tasks easily estimated, and preferably closed in one Sprint."

Suddenly I cringed. I realized that although we all are Agile and Scrum elaborate people, we had in our discussions no commonly defined or agreed understanding of even our basic technical vocabulary.

This happens often in human conversation, we simply assumed that each of us understands the same thing by the terms used.
Regarding User Story Slicing, when I understand User Story Slicing as splitting vertically into multiple functionalities, others don't apply the same concept that I used. Instead, they prefer a totally different point of view by understanding Story Slicing as splitting into multiple activities.

What’s the Problem in Slicing User Stories?

Ok. I confess I find activity-based User Story splitting problematic. Let me explain why. But I have to go into more detail.

The Sprint cadence is one of the major characteristics of Scrum. Each Sprint should always have at its end a usable result, the so-called increment. This can be a piece of executable software, a research paper, or an architectural design drawing. Important is, that the Sprint result can be used directly by the customer if she wants to.

To have an executable result implies not only finishing the implementation, it includes finishing all testing and quality assurance activities as well. If the result isn't tested at the Sprint end, it is unfinished! — Un-complete work, half-finished or finished to x% is not acceptable as Sprint result.

A Scrum Team gets no Story Points charged for an incomplete User Story. For a Story estimated at 16 Story Points and completed by 70% at Sprint end, there is nothing to present in the Sprint Review and nothing is charged to the team for its work effort spent.
And bad, the complete Story, all results reached and all remaining open parts are carried over to the next Sprint as a kind of legacy. As long as the Story isn't completed, it is moved to the next Sprint(s). The Sprint finally finishing the Story gets all the merits, all 16 Story Points. I know, there is a vivid discussion in the Agile Community about whether to account for partially done work. You only need to start an internet research on this topic.

Important in this context is as well the independence of all User Stories in the Sprint. No Story should depend on other stories in a Sprint.

Why do I mention this all? The reason is, this built-in Scrum policy ensures a kind of guaranteed delivery schedule. The customer is ensured to have cadenced progress.

At Sprint start a mature Scrum Team plans so many stories into the Sprint only as it could finish getting an executable Sprint result by its current capacity. The customer is ensured to receive at each Sprint a potentially usable result fitting her needs better. There is no putting off "I'm almost done".

Here comes my argument. When we slice a User Story by all its activities identified to finish it, we may run into the risk to bundle activities fitting into the Sprint without having a holistic view of the overall functionality. With this component thinking, we cut the Story horizontally.

Take the featured image of this post showing a piece of cake. If we split User Stories by activities the following metaphor yields. For example, in Sprint 1 we bundle all activities needed to prepare the case base. In Sprint 2 we bundle all activities needed to prepare the cream, cherries and blackberries. In Sprint 3 we bundle all activities needed to combine the base with the cream, and in Sprint 4 we place the fruits into the cream layer. And so on. We may consider some variants, for example: doing in multiple Sprints all the work for the case base, doing in multiple Sprints all the fruits, and in the final Sprint we assembling altogether.
Nevertheless, we don't get a tasty piece of cake (executable increment) in the first Sprint. Actually, we do Agile in an iterative way. Over a long time, we create and assemble parts of our product to finish it with a Big Bang. That's not Agile, that's waterfall-ish.

Never slicing/splitting User Stories by activities only.

How to Solve It

Please don’t understand me wrong. What I described is the worst-case scenario of splitting User Stories into activities. A much better way to split User Stories activity-wise is to identify patterns of activities and use these patterns for Story splitting. Working with activity patterns is an incremental development that slices the product into fully working slices which are known as Sprint Increments.

So, here is my recommendation on how to slice User Stories detailed into different aspects:

1. Never, ever slice User Stories horizontally.
2. To get full-stack functionality always slice User Stories vertically.
3. Slicing User Stories by activities leads to the risk of not getting executable Sprint Results.
4. For an executable increment identify patterns of functionality and slice them vertically.

To put it short, we shouldn't split the work needed into activity chunks small enough to fit into a Sprint. Instead, to get a potentially usable result we should identify activity patterns to be split only.

Instead of slicing/splitting User Stories by activities search for activity patterns.

Fortunately, the discussion in the Agile community about splitting user stories leads to an open-source published User Story Splitting Flowchart.

The recommendation is to split User Stories vertically by Patterns only:

• Workflow Pattern: Focus on the start, middle, and end parts of the workflow. Don't slice it step-by-step in total.
• Operations Pattern: Identity IT systems operations (e.g. CRUD) to split.
• Business Rule Variations Pattern: Identify different business rules to split.
• Variations in Data Pattern: Reduce complexity by identifying variations in data.
• Data Entry Methods Pattern: Split a complex user interface to start with the simplest possible UI to more complex ones.
• Major Effort Pattern: Split the Story into several parts where most of the effort will go towards implementing the first one.
• Simple/Complex Pattern: Differentiate into easy vs difficult work.
• Defer Performance Pattern: in the case of Performance aspects, start with the proof of concept first, then increase performance.
• Break Out a Spike Pattern: Do a time-boxed Spike first to resolve uncertainty around the implementation intended.

For more details see the Further Reading section.

Further Reading

• The Humanizing Work Guide to Splitting User Stories