Slicing and dicing user stories

To really understand the effect that the Product Owner has on the success of Agile development, it is vital to understand the art of creating good user stories to deliver results.

As was mentioned in a previous post, a poorly chosen user story will make it tough for the team to deliver, wasting time and potentially effort with poor control over the investment. On the other hand, a well chosen user story will support the early delivery of valuable results.

The creation of good user stories depends on a technique called "Slicing", i.e. preparing user stories in a fashion that they become immediately useful once completed.

Horizontal slicing is bad

A poor approach to slicing is cutting a huge story into horizontal slices. Let us use our "World Hunger" example to explain this approach:

We may want to resolve World Hunger in the following manner:

1. Obtain enough food to feed the entire world
2. Gather enough volunteers to distribute this food in the entire world
3. Establish the logistics to accomplish the distribution process
4. Obtain political support (permission, visa, military/police protection) for the distribution

Let us just assume that we had successfully completed steps 1,2 and 3 - but we don't get permission!

We have everything in place, yet there's a bunch of nuts sitting in well-furnished offices who block results for whatever reason or maybe for no reason at all.

While we gind our teeth in frustration and our supplies spoil, people continue to starve. 

A whole lot of resources were wasted, a lot of time was spent - yet there is no visible result!

What happened? Dependent layers were built, and all activities on one layer depend on another layer for success. We can't even know whether our concept works until all layers have been completed, well - at least to some extent. But until all layers are achieved, there is always this looming sense of failure.

(When this happens in the corporate world, you would find some CxO closing divisions, cutting funding and whatnotever that is bad for your career.)

Delivering with vertical slices

As previously discussed, a vertical slice is intended to deliver fast, with limited scope.
"Feed one person for one day" is a limited task, it produces visible, measurable results and permits scaling.
The result from "feed 1 person for one day" is visible and can be subjected to Continous Improvement. Each day, each person contributes to success and regardless of how far we get, the feeling of accomplishment stays with us.

Once 1 person has been supplied, we can enlarge the process to feed 2, then 5, then 10.
All of a sudden, we will see that we are more efficient by centralizing the supply process, so we set up a user story like "As food distributor, I would like a central place where I can always pick up the food baskets so that I save time in getting food to the Needy."
Once we reach 100 people fed, we may get into stories like "As charity, we need media coverage, so that we can obtain funding to feed another 1000 people"
These stories are again, limited in scope, provide a good measure of success and can be completed in a limited amount of time.

Maybe we need to rework our former approach (by Refactoring) but maybe we can just continue doing things as before.

Summary

Lean identifies multiple types of "Waste". One of these types is producing stuff which we can not use yet ("Inventory"). Another type is producing stuff which may never be used ("Overproduction").

Well-sliced stories which resolve (or even better: eliminate) dependencies on other activities serve the team in reducing the risk of delivering features which are not useful for a long time in the future, or - potentially never.

Good Story slicing positively contributes to the visibility and value of results and negatively, eliminates waste.

Therefore, the Product Owner is a key player in enabling team success.