Story slicing 101

A repeating theme in agile transformations is: "Our stories are too large, and we can only deliver all or nothing - we have no idea how to slice them". The consequences? Teams can only do few, but large stories, variation and failure probability is high - predictability and flexibility are low. None of these are desirable from a business perspective - regardless of agility. Story slicing solves this.

Since we will be dealing with fairly abstract concepts, let us create a specific example to make the subject more tangible. Let us start with the "too big" story:

As a user of the platform, I want to have a response time of less than 2 seconds, so that I can spend more time actually making progress.

This is a typical case of nonfunctional requirement, phrased as a user story with clear success condition and clear indication of business value. Unfortunately, for large systems, this pretty much means rewriting the entire code base - there is no way to get this done in a few days!

Step 1 - Start asking questions

The above story leaves plenty of room for interpretation. The first misunderstanding is that "We have to do everything, otherwise it might not work". Teams end up creating seemingly endless to-Do lists for changes that all need to be made. But they don't really ask questions.
A good way is to break up the team in a Refinement session and let them actually build a model around the story to help them discover questions, independently.
Here is what the team might come up with:

Which type of users do we have?
Do admins have the same needs as application users?
Does it really hurt if user creation takes a bit longer?
Which function actually takes the longest?
Is 2.1 seconds a problem?
We could make transactions faster by splitting into multiple minor steps, but that has more clicks - would the users accept that?

Regardless of what questions come up, what you need is that these questions are written down explicitly, not a detailed discussion to answer these questions (yet).

Step 2 - Bring the questions together

Different sub-groups will probably discover different questions. There is no "right" or "wrong" at this time, only different models, resulting in different questions. All questions are good, because they reveal how people think. By having each group bring their questions to the board, we can start to cluster questions. Most likely we will have more than one cluster.
For example:

Users and their needs
Function specific boundaries
Worst-case scenarios

What you need now is not the similarities within the clusters, but the differences between the clusters.

Step 3 - Slice based on clusters

Slicing is best done across differences, but keep real user value in mind. None claim to solve the entire problem, all will contribute a meaningful partial solution. At the moment, let us "forget" about the overall problem we have and specifically focus on partial delivery.
Here are examples for extract user-relevant, deliverable stories from the basic story:

As a new user, I want to create a new account in less than 2 seconds.
As admin, I want to wipe a user account in less than 2 seconds.
As transaction user, I want to complete a transaction in the system in less than 2 seconds.

These stories are still quite different in size, but they are much easier to handle than the entire block. After we are "Done" on the first two stories, there is still a large amount of work to be done - but also a tangible result. Some of these stories might be discarded immediately, because the team realizes that this specific need is already met.

Step 4 - Drill in, Rinse + Repeat

Looking at our example, most of the work will probably be in the third sub-story. We can drill into this sub-story in exactly the same way we drilled into our initial story. Drill-in can be channeled by moderating the team to look for specific aspects.

Here is a small list of aspects to look for:

• Workflow: Steps, user goals, scenarios
• Transactions: activities, operations (CRUD)
• Users: personae (user types), roles, responsibilities
• Technology: configuration, context, data streams (& interfaces)
• Data: content, types, subsets

With this list, you could instruct one group to look for workflow aspects and another group might examine data.

Here is an example of what the "data" group might come up with:

• 60 second timeout when the database is down.
• Stuck in a "Waiting" dialog when the Internet connection is unstable.
• Mass update speed is proportional to amount of updates.

Step 5 - Verify & Engage

Depending on how far you take this, you can slice down any large topic to as many small topics as needed until the team arrives at the following two conclusions:

1. We have discovered relevant areas for change
2. We can resolve a few stories in a fairly short amount of time

Put the most important, workable stories high in your backlog, preferrably starting with the first stories right in the next sprint - and sort the remaining relevant items into the backlog at an appropriate place. If you want to, you can keep the "master story" in the product backlog, but it's priority will be lower than that of the lowest identified story.

After all known stories are closed, the master story will pop up again - at that time, the first question is: "Do we still have a relevant problem?"

Conclusion

World hunger stories are common. The most common problem teams encounter is that they dive into the solution space before working on the story definition. However, since the story with it's Acceptance Criteria defines "success", it is most important to have a realistic goal in mind. Otherwise, there is no way to succeed.
The next time you encounter a backlog item that is "too large to do in a Sprint", try asking tough questions and slicing along the differences between the questions.