Breaking Down Features to User Stories

In my recent post on root cause analysis and the 5-Why’s Lisa Crispin wondered if they could be used in breaking down user stories, too:

Are the 5 whys only for root cause analysis? Can they be used to find out the purpose of a new user story or theme?

There are many ways to break down user stories to discover their purpose. Three of the most useful are 5 Why’s, Given-When-Then, and Use Case Scenarios.

Let’s imagine we’ve gotten the following feature request from our business customer:

We need the system to handle multiple allocation requests

(Note: This is a scenario from a customer I was talking to this morning. They had a little more detail, but we’ll pretend we just have the barebones)

Let’s take a look at what happens to this feature using each of the methods.

5 Why’s

In the 5 Why’s scenario, we start asking why the customer needs this. It may not drive us to user stories at the end, but we will have a better understanding of what is going on, and we may find user stories along the way. Let’s watch.

Developer: Why do we need the system to handle multiple allocation requests?
Customer: Because some orders will need to be split up.
Developer: And why do they need to be split up?
Customer: Because not everything will fit onto one pallet.
Developer: Why won’t it all fit?
Customer: Because we can only put so many of an item onto a single pallet. There’s just only so much room available to stack stuff safely.
Developer: So why does that affect the system?
Customer: Because we don’t want customers to have to think about pallet splitting. We just want them to be able to place the order, and the system figure out how many pallets it needs to go onto.

We can see from that exchange that we learned a lot more about the system than we initially had:

• Pallets have an upper bound of how many items can fit onto it
• The system should know how much of an item a pallet can hold
• Customers will order more than one pallet’s worth of stuff in a single order
  • We’ll have to ship multiple pallets
  • We’ll have to track multiple pallets
  • We may have to handle returning multiple pallets of items
• Multiple pallets should still be considered a single order
• It isn’t clear if we can mix different items from the same order onto a pallet

We can then begin to turn these insights into user stories which capture what we need. But what if we tried just going straight into understanding what we would need from the system to make it work?

Given – When – Then

If you’ve seen the wonderful Ruby tool Cucumber then you are familiar with the syntax of Given-When-Then. It basically says that Given some preconditions, When an action happens in the system, Then post conditions should be met. We can apply that to our original feature and see what happens.

Developer: Ok, so you’ve said that the system should handle multiple allocations. At what point should it be able to handle those?
Customer: Well, when the customer places the order
Developer: Ok, so When the customer places an order…what should happen?
Customer: Well, it’s not just any order. When a customer places an order that doesn’t fit on a single pallet.
Developer: Ok, so Given we know how much can fit on a pallet, and Given that the customer has placed an order which is larger than a single pallet can handle, When they place an order, what should happen?
Customer: Well, the order should be split up among multiple pallets
Developer: Ok, and should those be treated as the same order, or should they be shipped as separate ones?
Customer: No, no, they need to all go out and be tracked as one order

So from this conversation we might be able to create a scenario like the following:

Given a pallet can hold 15 items
When a customer places an order for 45 items
Then the items should be split among three pallets
And all the pallets should have the same order number

We can then continue to create scenarios around the various things that will come up about the system. What about orders with different item types? What about orders which don’t fill up a pallet fully? What about returns? We can use the Given-When-Then syntax to come up with each of those.

Use Case Scenarios

When you start running into complex scenarios, a cautiously handy tool can be Use Cases. I say “cautiously handy” because Use Cases can tend to focus our thoughts away from communication and closer to the realm of documentation focus. We should always be thinking about the “Working Software over Comprehensive Documentation” line from the Agile Manifesto and use that to guide us on what our focus should be (and see Alistair Cockburn’s article Use cases, ten years later).

At their core, Use Cases define several flows, similar to what we saw in the Given-When-Then syntax. There is the normal flow, which is the “happy path” through the system. There are alternate flows which are different paths the user can take. And then there are exceptional paths, which define what happens when a user runs into a problem (for a more in-depth look, see Alistair’s Basic user case template).

Let’s go back to our developer and customer to see what happens:

Developer: Ok, explain to me how the user would see multiple allocation working
Customer: Well, they would start by placing an order on the entry screen which includes a quantity greater than a single pallet can hold. When they placed the order, the system would split the order up into sub-orders or something and put the correct number of items onto the multiple pallets necessary. The customer would only see one shipment with multiple pallets.
Developer: What if the order contained different types of items? (Alternate Case)
Customer: The system should pack the items in such a way that we use the minimum number of pallets.
Developer: So different types of items can be on the same pallet?
Customer: Sometimes, yes. Other times they should be on different pallets. We have an identification for each type of item which must be packed separately
Developer: So what should happen if the customer puts incompatible types into the same order? (Exceptional Flow)
Customer: Nothing, I suppose. They’ll just have more pallets. Well, actually, I think that we should notify them of the number of pallets it will take to process their order
Developer: Do they have the ability to cancel the order at that point? (Alternate Flow)
Customer: No, no. It’s informational only. Obviously it’s better for us if we minimize the number of pallets we have to use, but no one is going to not order because they have to be put on different pallets

When we work with teams who use the Use Case format, I explain that a Use Case is not a User Story. Instead, we take the different flows through the Use Case and generate stories from it. It actually works out quite well, since the Use Case document tends to capture a higher level vision of what is going on, and then we drive out that implementation using User Stories. At a minimum, the normal flow, the alternate flows and the exceptional flows will all have their own User Stories.

I hope that helps show some different ways you can approach the problem of breaking down user stories. Remember, the goal is not about following a process, but ensuring that you are focusing on how whatever it is you are doing is helping you communicate more effectively with your customers or business owners – and ultimately helping you build your software faster and better.