The Scrum guide does not mention User Stories. Still, all the Scrum teams I worked with use them. Many Scrum teams apply User Stories to a fault: User Stories may not be the right tool for the job.
According to the Scrum guide, few attributes are mandatory for Product Backlog items:
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.
As you can see, User Stories are not mentioned anywhere. They are also not mentioned in the rest of the Scrum guide. Why are User Stories so popular if Scrum teams are under no obligation to use them?
There are three reasons for User Stories being so popular:
- User Stories are easy to understand and to get started with. A lot of information is available on User Stories. With a quick search you can find documentation, books and courses to learn more about User Stories.
- User Stories are versatile. You can use them for discovery. You can use them for delivery. It is easy to split User Stories up in smaller ones. It is hard to go wrong, when you choose to write a User Story.
- People are unfamiliar with alternatives and when to best use them. It is easy to do what you did before.
For the last reason, I am writing this article. I want to help spread knowledge about alternatives to User Stories. It pays off to know the right time to use each template for your Product Backlog items and you will get a better result by doing so.
I will discuss 5 alternatives to User Stories together with their pro’s and con’s.
- Initiatives
- Job Stories
- Problem Stories
- Improvement Stories
- Feature-Driven Development features
Initiative: Super-Epic for grouping Epics together
Initiatives allow teams to work together on functionality that spans across multiple teams. Let’s say you want to deliver a functionality that requires collaboration by four different teams. You start by creating an initiative that is shared by the four teams. It is then up to the teams to split their work up in one or more Epics. These Epics will then need to be refined and split up further.
Pros:
- Initiatives help manage uncertainty and unclarity across different teams. It is up to the different teams to coordinate and split the work up in Epics and even smaller backlog items
Cons:
- No well-defined template for initiatives.
- Initiatives have a tendency to become high-level and far removed from the actual work. All teams need to have same understanding what the initiative will contribute to before breaking it down in Epics.
Job Stories: what is the context and causality of your feature?
Job stories are rooted in jobs-to-be done and have the following template:
When < situation>, I want < motivation > so that < expected outcome>
Pros:
- Job Stories are great for discovery. You really need to understand the context of your user and the job they want to perform in order to write a good Job Story.
- Job Stories do not introduce implicit assumptions about the user. You need to make the situation of the user, their motivation and the progress they are looking for in their lives explicit. This means everybody will be on the same page.
- Can easily be split up in smaller Product Backlog items by using User Stories or Problem Stories.
Cons:
- Job Stories are hard to split up in smaller Product Backlog items by using Job Stories. The situation, motivation and expected outcome often remain the same for the overall feature. So Job Stories work best on Epic level.
- Job Stories may introduce confusion in delivery, because they are really geared toward the problem domain. In delivery, you need to understand the problem but you need to describe the solution really well. Job Stories provide a poor template conveying the specific solution you came up with.
Problem Stories: what is the problem you are trying to solve and how do you intend to solve it?
A Problem Story has the following template:
In order to < solve problem >, we will <build solution >
The solution is added by the team after discussing the issue at refinement.
Pros:
- Problem Stories make it easy to separate the problem and solution space.
- Easy to create and understand.
- Works great for more technical features. Sometimes it is really hard to write a User Story, because there isn’t just one user affected it is unclear who is affected.
- Easy to split up in smaller Problem Stories.
Cons:
- You need to understand the problem you want to solve really well before you create a Problem Story. Discovery is necessary prior to creating a problem story.
- Lacks context of the user. Dangerous to use when the context of the user matters, because you lose this information and you may build the wrong solution. So beware!
Improvement Stories: what is the current situation and the desired situation you want to have?
An Improvement Story has the following template:
We have<current situation>, we want to have <desired situation>
Pros:
- Easy to create and understand.
- Works really well for incremental improvements, where using a User Story or Problem Story would take effort without adding value. Especially if you have User Story it relates to where the context is already adequately described.
- Great if you want to prevent the whole ‘Is it a bug or not?’ discussion. Who cares if it is a bug or not, just as long as someone picks it up.
- Prevent duplication of effort by complementing User Stories. You can link to existing User Stories that already describe the context of the user really well.
Cons:
- Improvement Stories focus on the solution, so not good for discovery. To be used when you have a simple solution and it is obvious why it needs to happen.
- Not very versatile. To be used in specific circumstances.
Feature-Driven Development features: great for picking up technical work
FDD features have the following format:
<action> the <result><by|for|of|to|in><object>
This may sound quite cryptic, so here are some concrete examples:
- Generate unique identifier for uploaded images
- Send advance shipping notice to the warehouse
- Reduce stock levels of sold items
This template works great for technical tasks, where what you need to do is far removed from users.
Pros:
- Easy to use and understand.
- Easy to split up in smaller chunks.
- Work great when what you are building things that are far removed from users. Should be used when writing a User Story feels silly and convoluted.
Cons:
- Context of both the user and the problem are missing. You need to be extremely confident what you are building is the right thing.
- Focused on the solution, so poor for discovery.
Different backlog item types serve a different purpose: pick the right one for your situation
It is easy to keep on using User Stories and Epics. It is safe to do, as you have done many times before. However, there are clear situations where it may pay off to try something new. Each backlog item type serves a specific purpose and picking the right one makes your life easier.
Building something big that requires frequent collaboration between multiple teams? An initiative will help start the discussion and provides a good platform for breaking down work in multiple Epics.
Building a new product and busy with discovery? Job stories are better suited than User Stories for figuring out how to make the lives of your users better.
Have a list of small improvements that build upon something you’ve released? Improvement Stories will save you a lot of time and easier to understand than User Stories.
Have a clear problem you need to solve that affects multiple users or the type of user does not really matter? Try a problem story. More signal and less noise.
Busy writing a user story that feels silly and convoluted because it is far removed from the end users? Use the Feature-Driven Development Feature template.
Mistakes Product Managers Make When Writing User Stories
While developers and project managers are familiar with their target audiences in broad strokes, that familiarity often remains surface-level. Whether you work in a startup or in a large corporation with multiple teams coordinating on the project, user stories can help guide your process. User stories represent a simple yet effective way to steer the direction of your development project (whether app or website) to resonate with its audience.
However, due to the nature of software development and product management as a whole, writing user stories can sometimes feel like an unnecessary bother. This inevitably leads to mistakes and misconceptions which can reflect on the final product’s quality and overall performance on the market. Thus, let’s take a look at a true product manager role to resolve several crucial mistakes that product managers make in regards to user stories and how you can benefit from them.
User Stories Writing Mistakes
- User Stories are Too Complex
The first and most common complaint software developers have in regards to user stories is related to their complexity. Rather, user stories should be as short and informative as possible instead of taking up several sentences or an entire paragraph.
Single-sentence user stories can also be accompanied by 1 to 3-word titles which can be used to quickly scan through different references during development. Product managers should aim to eliminate fluff in user stories they write before presenting them to the team for further development.
2. User Stories Lack Personality
The goal of using user stories in development is to give your team members a beacon to follow in regards to UX personalization. However, writing a user story and referring to your product’s user as “user”, will likely fail to achieve that effect.
You can personalize your user stories by creating simple yet creative personalities during a team-building meeting as a group exercise. That way, a “user” will become “Simon the Architect” or “Rebecca the Lawyer” instead of a non-individual, blank slate for developers to use as a reference.
3. User Stories are out of Sight
Product development will rarely be successful if there is no trust or communication between team members 24/7. Once user stories are used in active development, they should be present throughout the process without excuse.
Whiteboards, sticky notes, and other physical reference points can be utilized to ensure that user stories are clearly visible at any moment. This will ensure that everyone on the team has the same user story writing in front of them and help the team avoid miscommunication.
4. User Stories are Too Technical
When it comes to writing user stories, it’s best to focus on the benefits and practicalities of using your product rather than its technical specifications. Even though your team of developers might be familiar with industry-specific terminology, user stories should represent the way stakeholders interact with the final product.
User stories that are open-ended will give developers more freedom to experiment and present new ideas to the team before implementing the right ones. Keep your user stories grounded in day-to-day lingo and avoid vague or niche terminology to ensure no confusion happens during development.
5. User Stories are One-Sided
The difference between a product manager and a software developer should, in practice, be in the title alone. Product managers should treat their team members as equals and coworkers with their own ideas, feedback and thoughts on where the product can go next.
The same applies to user stories, as they should be created in a group and not simply passed down from the manager onto the team. This will enable developers to identify with and own the stories you write, just as the users are supposed to identify with the final product.
User Story Template to Follow
A common misconception attributed to user stories is that they are too difficult or complex to write effectively — quite the contrary in fact. A user story has to include three basic elements to serve its purpose in guiding your project: a user, a goal, and a need. Let’s take a look at a user story that follows this flow of information. In our case, we are developing a software app centered on email marketing.
“As a graphic designer, I want to inform my clients of new design trends often, so that I can build my reputation.”
As we can see, this user story informs us that a designer might want to send emails regularly to his clients. This would inform our developers to pay close attention to email automation and mail list management features in the software application. You can rely on such writing tools as Trust My Paper, Evernote, or Best Essay Education to write and format your user story templates more efficiently. Introducing various user story templates to your project early on will allow different team members to ideate and come up with user stories independently.
Advantages of Writing Proper User Stories
By following a standardized template, you will allow the development team to quickly jump between tasks and contribute to the project more meaningfully. Now that we have an idea of which mistakes to avoid in regards to writing user stories, why should we use them at all?
Nigel Timothy, a Content Writing Specialist at Supreme Dissertations, spoke on the topic recently: “User stories represent the most direct way to empathize with our stakeholders. Whether it’s UI writing, programming, or customer support, the development of each of these processes requires identification with the end-users’ wants and needs. Failing to write user stories for a development cycle can severely hinder the product’s overall appeal, leading to the dissonance between your team and user base.”
Presenting your team with user stories that reflect the final user adequately will improve the development time and UX of your product significantly. Apart from that, some of the most concrete benefits your development process will experience include:
- Creativity and brainstorming as cornerstones of the development process
- Objective, identifiable goals and milestones for developers to follow
- Higher emphasis on internal team communication, feedback and problem-solving
- Ability to prioritize tasks and develop product features based on individual user stories
- Higher user satisfaction, brand advocacy, and ROI post-launch
Adopt and Adapt (Conclusion)
The crux of user story writing mistakes happens because of miscommunication and lack of teamwork during the development process. User stories are not wise to be passed down from product manager to developer — they are a form of narrative goal-setting methodology.
Treating user stories as an extension of KPIs and milestones you’ve created to guide the project forward will ensure their usefulness in the process. Adopt the ideas presented by your team and adapt them into user stories you can all be proud of as a group — the results will speak for themselves.
Replacing The User Story With The Job Story
I’ve written about the problem with user stories before. At the time, I found it better to just have the team talk over proposed changes to the product. This worked great when the team had gelled and the product is very mature; however, now I’m working with a new team and building a product from scratch. In this case, because our canvas is blank, we are having trouble getting on the same page when it comes to customer motivations, events and expectations. But today, things have turned around. I’ve come across a great way to use the jobs to be done philosophy to help define features.
I call them Job Stories.
Where It Comes From
The idea comes from the really smart people at intercom. Here is what is they say:
We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome:
When _____ , I want to _____ , so I can _____ .
For example: When an important new customer signs up, I want to be notified, so I can start a conversation with them.
It’s not referred to as a Job Story in the article, but I’ll call it that so I can easily reference it in the future.
The article doesn’t spend a whole lot of time with the concept, so I’ll talk about why I like it and why it’s better than User Stories.
The Problem (Again) With User Stories
Summed up, the problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there’s no room to ask ‘why’ — you’re essentially locked into a particular sequence with no context.
Here’s how I see the format:
The first problem is that we start with a Persona, which is a very bad idea, and then plop in an action which we think should be taken in order to achieve the expected outcome. As I’ve marked in the above image, there’s really a disconnect between the action and persona.
Here, let’s look at some existing User Stories:
In the above chart, when someone reads moderator or estimator is that really adding anything? If anything it’s adding ambiguity to the flow. You and I are going to attach our own interpretation of what a moderator is or why they are in these particular contexts.
Here, try this. Chop off the whole As a / an segment and see if you’re really losing anything. Compare these two:
As a moderator I want to create a new game by entering a name and an optional description
VS.
I want to create a new game by entering a name and an optional description
Did the sky fall?
The Job Story : All About Context and Causality
Update: 2015–03–03: Based on even more usage & feedback, I use a slightly different explanation now. See these tweets of how I suggest framing it now. An update of this article will come in the future…
Check out the image above. Now we’re cookin’!
All of the information above is critical and very informative because we’re focusing on causality. Each job story should provide as much context as possible and focus on motivation… instead of just implementation.
[update June 4th 2014] After working with Job Stories for a while now, I’ve changed ‘Motivations’ to ‘Motivations and Forces’. Look to 5 Tips For Writing A Job Story which touches on this. Also learn more about the forces via this podcast and this short article.
Let’s rewrite some examples from the user story chart above as a Job Story and add motivation and context to each one.
User Story:
As a moderator, I want to create a new game by entering a name and an optional description, so that I can start inviting estimators.
Job Story:
When I’m ready to have estimators bid on my game, I want to create a game in a format estimators can understand, so that the estimators can find my game and know what they are about to bid on.
User Story:
As an estimator, I want to see the item we’re estimating, so that I know what I’m giving an estimate for.
Job Story:
When I find an item I want to set an estimate for, I want to be able to see it, so that I can confirm that the item I’m estimating is actually the correct one.
User Story:
As a moderator, I want to select an item to be estimated or re-estimated, the team sees the item and can estimate it.
Job Story:
When an item does not have an estimate or has an estimate I’m not happy with, I want to be able to restart the estimation process and notify everyone, so that the team knows a particular item needs to be estimated upon.
What About Multiple Roles & Events?
*Added July 28th 2014
As I get great feedback regarding Job Stories and as I continue to work with Job stories, I’ve found that sometimes it’s helpful to include Roles, or Characters, as part of the When_ clause.
Products With Multiple Roles
Roles / Characters are most helpful when the product has multiple roles, e.g. an IT product ( Admin, Manager, Contributor….) or in a marketplace product product ( Buyer, Seller ). The reason is just to clarify who we’re talking about.
Using eBay as an example:
When a Buyer has already made a bid on an item, they are anxious about missing a counter bid and want to immediately receive counter bid notifications, so they can have enough time to evaluate and update their own bid.
Roles With Cause & Effect
Sometimes, there are situations when a Job Story effects multiple roles at once — setting up a cause and effect scenario.
Using eBay, again, as an example:
When a Seller isn’t happy with the bids they are getting and takes their product off the market, Buyers who have already submitted bids, want to be immediately notified that the product has been pulled, so that Buyers know they no longer need to keep tabs on the product and should look for a different, similar product instead.
Using Events Instead Of Roles
Sometimes, however, there might be a situation when an event effects all the roles or groups of roles: such as needing to get a password reminder. In this case there’s no reason to have a specific role, rather, try to keep it event based and general by using terms like customer or someone (but not user):
When a customer is on their mobile device and forgets their password, they want to get their password in a way that makes it easy to reclaim it via their mobile device, so they can continue to log in and access their news feed.
Why not user? User feels very lifeless and sterile, instead, customer reminds us that we have people who need to be served and respected.
Define Motivations, Don’t Define Implementation
Job Stories are great because it makes you think about motivation and context and de-emphasizes adding any particular implementation. Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.