Last week I shared what you ought to know about user stories. In that post, I shared an example of stories for creating a membership site.
George Dinwiddie called me out on my choice of using create, read, update, and delete stories as an example.
Ideally we want user stories to reflect what a user wants to accomplish with the product.
And when we identify the things customers want to do, those things are often (but not always) general enough that they need to be split into smaller chunks so that we can can shorten the feedback cycle.
Once you’ve identified your desired outcome, you’ll start populating your backlog with items representing the outputs you think will get you those outcomes. Those items will inevitably be fairly big chunks of work, and it’s why the idea of epics (as big user stories) came into being.
In order to learn whether the outputs you think will get you the right outcome will actually do that, you’ll find you frequently need to split those epics into smaller chunks – which in practice are generally referred to as user stories. You may even find you need to take those user stories and split them into even smaller user stories. That’s ok.
Epics represent the overall view of the output you believe will help you get your desired outcome. They also tend to be more meaningful to customers than the small user stories that teams use to shorten the feedback cycle.
Put another way – epics are for customers, user stories are for the team.
There’s also an aspect of context involved in determining whether CRUD type stories are helpful representation of user stories.
If you are creating a product that does not already exist, anytime you need to manage something – a profile, an order, an order item – you’ll find the people using that product want the ability to create that thing, read that that thing, update that thing and delete that thing.
CRUD, in that case, makes sense.
If your product already exists and you want to add additional capabilities – such as associate your photo with your posting, or get notification of replies – then you may be able to represent the work to accomplish that with a single backlog item. A user story.
When I used the example of Create Profile, Read Profile, Update Profile and Delete Profile in my previous post, the context was building a new product. You were building a membership site and you wanted your users to be able to manage their profile. I skipped the epic and immediately went to the split version of it.
Having a hierarchical backlog – consisting of big chunks split into smaller chunks (epics sliced into user stories) – helps you deal with these situations.
You want to avoid having too many levels of hierarchy (I’d argue any more than two) because otherwise you’ll find that you’ll spend more time arguing how to classify items than you do understanding what those items are.
It’s far better to identify big chunks on your backlog that directly tie to things your customer is trying to accomplish and then split that big chunk into smaller chunks as you get ready to start addressing that particular need.
Here are some resources about how to go from big chunks of work to smaller chunks in a way that still allows you to get meaningful and useful feedback in a quick manner.
Epics have taken on a variety of meanings in software development. Are they big user stories? Are they a different kind of backlog item? Does it really matter?
Agile Alliance Entry on Story Splitting
“Splitting” consists of breaking up one user story (or epic) into smaller ones, while preserving the property that each user story separately has measurable business value. That business value may be the learning that comes from quick feedback from people using the output produced as a result of that user story.
21 Story Splitting Patterns
I researched a wide array of blog posts and other resources on how to split user stories and identified 21 patterns that you can use to split user stories in a way that allow you to generally maintain INVEST criteria.
How to Split a User Story
Richard Lawrence’s How to Split a User Story poster provides a decision tree visualization of how to pick a proper approach to splitting a user story.
A story map is a visual representation of a backlog that provides additional context regarding how backlog items are related to each other and when the team is planning to deliver them. Story maps can give you a visual tool to guide conversations about what big chunks need to be sliced into which small chunks, and when.
Thanks again for subscribing to Inside Product Management.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.
Plus if you think someone else would get some value out of the newsletter, let them know they can sign up and get a free copy of Product Ownership in the Wild.
Talk to you next week,
Kent J. McDonald
Also published on Medium.