Stop Drooling Over User Stories
And Here's 5 New Templates to Drool Over
I recently gave a Beyond User Stories Workshop at the Product Owner.nl event in Rotterdam. By facilitating the workshop I learned three surprising things:
Few Product Managers and Product Owners were aware of formats other than User Stories.
There was nobody who did not use User Stories at all.
Many companies force the User Story format, even in cases when it doesn’t make sense.
I believe all these three things are problematic, because:
If you use User Stories for everything, you’re applying them incorrectly.
If you use User Stories to describe solutions, then you’re only making things more difficult for yourself.
You don’t need to use User Stories—ever. It’s a choice, and there are many alternatives out there. IMO, the best thing you can learn is how to be agnostic by playing around with the different formats.
It’s time to stop drooling over User Stories and consider the many existing alternatives.
If you’re forcing everyone to always use User Stories, then it’s time to send Jules from Pulp Fiction your way 👇to make you reconsider:
Together, we will explore the following questions for User Stories and the 5 alternatives that are out there:
What are the advantages of the format?
What are the disadvantages of the format?
When should you absolutely NOT use it?
When does it make sense to use it?
But before we get started, let’s remind ourselves of the things we should always do.
What To Consider Regardless of Format
The most important thing regardless of format is the conversation that follows. That’s because sharing anything in a written format isn’t good enough. What you write down doesn’t mean you’ve established common understanding.
Whenever you try to apply a template, please ask yourself the question: is this template meant to aid with Discovery, Delivery or Validation? Some templates suck for Discovery, others are terrible for Delivery, and some are awesome for Validation.
That being said, let’s get started by discussing the format we’re all familiar with: User Stories.
User Story Format
Here’s the User Story Format we’re all familiar with:
The key thing when using User Stories is that you use them to describe an actual problem of the User. That’s why it’s called a User Story. You’re trying to use the format to capture a real story of the User.
The problems start when we also use User Stories to describe solutions. User Stories are ill-suited for expressing solutions, because they make things convoluted quickly. They are too wordy for that purpose, and force you to provide information that unnecessary for describing how a feature is supposed to work.
If you’ve decided to build a feature, and then you shoehorn how the feature works into User Stories, then you’re missing the point. Instead of doing User Stories, you’re busy doing User Fairytales. You’re busy reverse engineering and making up stories from features you’ve already decided to build.
This is extremely dangerous because you now actually have two flavors of User Stories:
User Stories that are rooted in the real world and represent the actual desires and struggles of users.
User Stories that are fabricated and do not represent any actual desires or struggles of users. But since they’re in the same User Story format as the stories rooted in the real world, there’s no way of telling if it’s real or fabricated.
In short, if you mix User Stories and User Fairytales, you have no way of telling which stories are real and which are B.S., and it’s very likely you’ll be building suboptimal solutions based on stories you’ve made up and don’t actually represent user desires or struggles.
Let’s summarize the pros and cons of using User Stories.
Advantages:
Great for capturing real stories you’ve discovered by talking to your users.
Offers the option of reframing the problem if you use them to capture actual needs and struggles of your users.
Easy to understand and use.
Disadvantages:
User Stories don’t add value if you’ve already decided to build a feature without talking to users and then you decide to reverse engineer the User Stories from your feature.
Watch out when splitting up User Stories into more User Stories because then there’s a good chance you’ll be reverse engineering User Stories from how the feature is supposed to work. Just link the solution to the original User Story and save yourself the time.
When to use:
When the specific user (persona) matters, and it’s rooted in some real world evidence of what the user needs or struggles with.
When to not use:
User Stories help with Discovery but quickly become convoluted and meaningless if you try to use them for Delivery.
Don’t split up User Stories into more User Stories. It’s a waste of time, and you’ll introduce unnecessary noise (User Fairytales).
When the specific type of user doesn’t really matter, or if it affects multiple user types.
1. Job Story Format
This is probably the most popular format after the User Story and it was created by people at Intercom. However, many companies misapply this format, just like with User Stories. Why does this happen?
Let’s dive in.
Job Stories consist of three parts (example from Intercom):
Situation. “When car sales people and their customers interact with each other via the product.”
Motivation. “Customers are going to want to feel like they can trust the organization, process, and the salesperson. Salespeople are going to want to be confident that their process makes their customers feel comfortable.”
Expected outcome. So that clients will feel safe entering their financial information into a process.”
Job Stories are meant to capture the Jobs-To-Be-Done (JTBD). Just because you put something in this format doesn’t mean you’ve discovered a JTBD. The way to discover a JTBD is by doing JTBD interviewing. Unfortunately, many companies don’t do this heavy lifting and then make up JTBD without having sufficient understanding or evidence that these are actual JTBD.
By doing JTBD interviewing, you can discover the Progress-Making Forces and Progress-Blocking Forces that influence why someone chooses to adopt a new solution, or they decide to stick with the status quo. You can fill in the diagram below to see what forces influence choosing to hire your solution:
Advantages:
Great for capturing JTBD you’ve discovered by JTBD interviewing.
Allows reframing of the problem, which is extremely powerful.
Disadvantages:
You really need to do the legwork of doing JTBD interviewing to sufficiently understand their situation, motivation and expected outcome. This takes time, and it’s worth it, but if you don’t put in that effort, you shouldn’t be using Job Stories, as you’ll be making shit up to fit the format. That does nothing but waste time and add noise.
When to use:
When you have an evidence-based understanding of the context, motivation, and JTBD of the user.
When to not use:
It's horrible for splitting up work. You can use it to split up a job into smaller jobs, but they might still be too big. You must also watch out that they’re real jobs, not things you invent to describe your solution, like with the User Stories.
Don’t use it for small features and improvements, as the JTBD likely is on a much higher level, so you should have it already or you have to focus on discovering it on a higher level
2. Goal Problem Solution (GPS) Format
Chris Fenning created the Goal Problem Solution (GPS) format, which I discovered through Joerg Palluch.
The GPS format consists of three parts (definition from Chris Fenning):
Goal. The goal we’re trying to achieve.
Problem. The problem that’s preventing you from reaching your goal.
Solution. What I/we/you will do to solve the problem.
What I really like about the GPS format is that it forces you to provide intent: What are we trying to achieve, and why does it matter? Because you have intent, it becomes possible to reframe the problem and adjust the solution.
What’s really important is that you don’t have to fill in the whole template when you start. Maybe you begin with discovery first and gradually start filling in the details as you go along. You don’t need to provide all three parts before even starting.
Advantages:
Great for decoupling what we’re trying to achieve to how we intend to achieve it.
Allows for reframing the original problem, as maybe there’s a different problem that makes more sense to solve.
It can be used for Discovery, Delivery, and Validation because we can validate whether we’ve solved the problem.
Disadvantages:
Not suitable for breaking down work in smaller, sprint-sized tasks.
When to use:
Only makes sense if you’re doing Discovery, as otherwise you’ll be fabricating details to comply to the format.
When to not use:
Don’t use if you’re not doing Discovery and don’t use the GPS format to break it down further in smaller tasks.
3. Improvement Story Format
I invented the Improvement Story Format. It’s a simple format with a very specific use case. It can make your life much easier and save you a lot of time. It will also prevent you from introducing noise and waste.
Imagine you’ve delivered a new feature, but the format you’ve used doesn’t really matter, and you’ve done a great job of describing it. After release, you want to make minor adjustments to your delivered features.
Instead of describing all the things you already know, you just describe two things:
Current situation. What’s the current situation?
Desired situation. What would the desired situation be?
Then, you link to the original Problem Story, Job Story, User Story, or whatever you used for additional context. This way, you don’t have to repeat yourself and save lots of time without introducing additional noise.
This is an excellent format for adding finishing touches. It’s not meant for big things. It’s only meant for polishing stuff you’ve already delivered and when there’s much more context available.
Advantages:
Easy to use.
Prevents duplication of context and information. If you’ve described it brilliantly elsewhere, provide a link to it.
Disadvantages:
Narrow scope where it adds value.
If you misapply the format, you’ll pick up work without enough context to succeed.
When to Use:
Only for minor improvements and polishing existing work.
When to Not Use:
Don’t use it for completely new features or improvements, and definitely do not use it for any large body of work.
4. Problem Story Format
I discovered the Problem Story format through Adrian Kerry, who stumbled upon it in a presentation by David Evans.
It’s a stripped-down version of the GPS format that doesn’t include the goal. That’s why I won’t explain much more, as we’ve already covered it in detail in the GPS format section.
Advantages:
Allows for reframing the original problem, as maybe there’s a different problem that makes more sense to solve.
It can be used for Discovery, Delivery, and Validation because we can validate whether we’ve solved the problem.
Disadvantages:
Lacks intent: what are we trying to achieve, and why does it matter? Unless the problem describes the full scope, it’s crucial to understand the goal of what we’re doing.
Not suitable for breaking down work in smaller, sprint-sized tasks.
When to use:
This only makes sense if you’re doing Discovery, as otherwise, you’ll be fabricating details to comply with the format.
When to not use:
Don’t use if you’re not doing Discovery, or if you need Intent (the ultimate goal) of what we’re trying to achieve.
5. Feature-Driven Development (FDD) Format
Originally invented by Jeff De Luca, FDD is a great format for breaking down work.
Basically, let’s say you’ve decided you want to build a solution and break it down, and that’s where FDD can come in handy. The FDD format consists of three parts:
Action Verb. What we’re doing or the system is doing.
Result. The result of the Action Verb.
Object. The object in the system that’s affected.
A good example would be:
Generate the thumbnail of an uploaded image.
As you can see, the FDD format is excellent for smaller, more solution-oriented work. You can’t use it for Discovery or Delivery, you need to do that at a higher level.
Any templates present in this article, can be broken down in FDD smaller chunks of work.
Advantages:
Great for breaking down bigger chunks of work into smaller pieces of work.
Disadvantages:
It was only meant to describe technical solutions, not meant for Discovery and Validation.
When to use:
To break down any solution into smaller pieces of work. Link it to the original backlog item, whatever way it is expressed.
When to not use:
Don’t use it for bigger pieces of work where the understanding of the context and the problem matters.
Now that we’ve covered five different alternatives to User Stories let’s end with the most important part of this article: go experiment!
Go Play Around With These Different Formats
All of these different templates all come with their unique weaknesses and strenghts. Don’t take my word for it. Go and experience it yourself!
All these templates are ultimately a crutch. They make life easier for people. However, if you apply them in the wrong situation, they can make your life infinitely harder. The most important thing is to learn how to best express what’s required for your specific situation, and you don’t need to follow any templates to do that successfully.
These templates can help you to discover what works best in different kinds of situations. That’s why I highly recommend playing around with these different formats, but the end goal, just like the pianist who practices different scales, isn’t to master scales but to become a better pianist - to get better at expressing Product Backlog Items.
The goal isn’t to master the template but to learn what information is necessary and most helpful, depending on the situation.
In the end, effectively and concisely expressing backlog items is highly situational. You should aim to become agnostic and provide the right information for the right situation: to take bits and pieces and make them your own so you’re more fluid and expressive than any template can ever be.
I am responsible for maintaining two backlogs for multiple 'products' (internal web applications). The developers expect me to write all the details we need to implement solutions within the tickets (JIRA). We start with the need, expectations, personas and then build out the acceptance criteria. To 'estimate' more accurately, we then add to that the technical details (what will this take to implement). I like the FDD format here. What are your thoughts on such an approach? We only use JIRA and Confluence for our documentation...
Solid!