How to Develop Effective User Stories and Why You Should

User stories are the center of the agile universe.

One of the main features of agile project management is user stories. Scrum masters and product owners work with the team to determine what customers want and how they can get it.

Rather than following the waterfall method, where every feature is included in the development process, user stories are short bursts that help team break up the work into actionable chunks.

However, these actionable chunks can still confuse and overwhelm your team when they’re not done well. Follow this guide to implement user story creation into your agile project management process and improve its effectiveness within your team.

Part One: Creating User Stories

User stories are easy to create bu need a lot of analysis and planning to make them effective.

At face value, user stories aren’t difficult to create. What can be hard is adding all of the necessary information to make a story actionable without overwhelming your team.

Agile consultant Yvette Francino created a list of criteria for user stories to make sure they’re effective:

Stories should be written by someone who represents the users (usually the product owner).
They should briefly answer who, what, and why — but not how.
They should be small enough that they can be created within one sprint (roughly one to four weeks).

If any of these elements are missing, then your user story won’t be relevant, or it won’t solve an actual problem, or it will become too complex to finish within a reasonable time — all of which will limit your project’s effectiveness.

Additionally, there are other user story terms that your team needs to be familiar with before you can start running through scrum planning meetings. Maja Petricevic at CreITive does a great job of explaining the basics of user story creation. A few terms that will be useful for your team include:

Epics: these are user stories that cannot be completed in one sprint. They should be broken down into multiple user stories.
Themes: these are collections of user stories that have similar attributes. They are typically completed over multiple sprints.

It’s not uncommon for stories to become epics that the scrum leader then needs to break down. Here are three tactics your team can use when writing their user stories to avoid mistakes.

Role-Feature-Reason

Entrepreneur Alex Cowan shares the most prevalent user story approach, sometimes known as the Connextra Format or Role-Feature-Reason. This format has three parts to every user story, and agile product owners need to address each before they can move forward with planning and development. The three parts are addressed in a single sentence:

“As a [persona], I want to [do something], so that I can [reward].”

From there, you can ask questions that dig deeper. For example, you might ask how the persona will know that the process is working, or why they want to take action and receive the rewards. By working backwards, your team can come up with solutions that help customers instead of hoping your solutions solve imaginary problems.

The team at Yodiz created 25 user story examples to help agile leaders get into a groove with creating them. These examples don’t address the third part of the formula, so as a team, you can practice using this method by adding rewards to the end. This turns a list into an activity.

Three Cs

Three Cs approach proposed by Ron Jeffries in 2001 is more discussion based and can be used for brainstorming and development. Bill DeVoe recently explained how you can use the Cards, Conversations and Confirmation scaffolding during your scrum planning meetings:

Card: state the problem and goal on a 3x5 index card, using the Role-Feature-Reason method above.
Conversation: a developer reads the story on the card, discusses it with the writer to make sure everyone is on the same page regarding work done and future planning requirements.
Confirmation: this step answers what the system should do and how the team will know it is working correctly. These notes can go on the back of the card.

This process helps teams prioritize user stories by importance, with added communication ensuring the right product or process is created.

INVEST

The third process that teams can use when developing user stories is checking whether the idea is INVEST-able, meaning whether the benefits of the work will outweigh the cost of creating it. Abhilash Nair at Capgemini explained the acronym and how people can use it:

Independent - can the idea be developed now or does it need existing infrastructure?
Negotiable - can the team incorporate changes if needed?
Valuable - is there a clear benefit to the story?
Estimable - can the development team figure out the best way to execute the story?
Small - can the story be completed in one sprint?
Testable - can the story be tested for success?

If a user story isn’t independent, then it shouldn’t be touched until the next sprint when it is. If it is not as valuable as other stories, then it should be placed in the backlog until higher-priority items are completed. This process helps teams make sure the most important work is completed first and nothing gets held up because of a lack of prioritization.

Invest was a technique that was developed by Bill Wake.

Part Two: Mapping User Stories Into Actionable Sprints

While user stories might seem easy at first, they can quickly overwhelm teams who don’t know where to start once they have an idea of what they want to do. This is where story mapping comes in. This can either be done once you have your user stories, or as a collaborative way to create user stories without going overboard.

Story Mapping

Scrum planning meetings are highly visual and interactive. While you might not use 3x5 business cards, you can use project management tools or mapping software to make prioritizing easier.

Frances Place explains at a Girl’s Guide to Project Management how you can take your wall of user stories and prioritize them with story mapping. Activities and tasks are at the top to keep your goals clearly visible. Then you have three rows of user stories: versions one, two and three, with the most important tasks in version one.

Anything that doesn’t make the cut in these three versions is placed in the backlog. You can use this board during your scrum meetings and refresh it at the start of every sprint.

OOPSI Mapping

Agile consultant Jenny Martin says it’s easy for teams to feel overwhelmed by user stories, especially when complex projects have hundreds of stories that seem impossible to prioritize. To prevent this, she and Skills Matter technical product owner, Pete Buckney, developed the OOPSI model to keep the development process small and focused. OOPSI stands for:

Outcomes: what are the main goals your customers have?
Outputs: what deliverables and expectations come with the outcomes?
Process: what steps will customers take to achieve the outcomes?
Scenarios: what are some different situations might customers face?
Inputs: what are the preconditions for use and customer information that affects the process?

With OOPSI, you work backwards and then build out the process as it gets more complex. To explain the method, Martin uses the example of a customer wanting to withdraw funds from an ATM. What seems like an easy task quickly becomes a complex process.

Tips to Improve Your User Stories and Mapping

While the first few projects might focus on getting the hang of user stories and mapping, you can start to refine your process and improve your workflow as you get into the habit of creating them. Here are a few ways to improve your user stories and mapping meetings.

Ask Your Team to Develop Stories Before the Planning Meeting

One of the main benefits of the Three Cs and INVEST methods is that teams develop user stories before they ever sit down for a planning meeting.

Product ownership coach Ellen Gottesdiener [registration required] has seen teams arrive at the planning meeting without their user stories properly laid out. This slows the meeting to a crawl as teams try to create user stories and prioritize work. "They end up spending an hour or two on one story that may not be used in that iteration," she says.

In the same way that team members should plan for a brainstorming meeting, they should also come prepared with user stories and goals before the sprint planning meeting even begins.

Let Your Team Ask Questions About the Project

Your employees, contractors and team members don’t need to be kept away from the business side of the project. On the contrary, the more information they have, the better the results will likely be.

“When planning how to write user stories, implement a backlog grooming meeting to ask questions and understand the requirements of the functionality before sprint planning,” Eve Poeschl at MentorMate writes. “This gives the team the opportunity to communicate with the project leadership.”

This approach increases communication within your team and helps everyone create better user stories. You can’t expect people to plan for a scrum planning meeting without having the right information beforehand.

Take Time to Refine and Improve Your Stories

When user stories aren’t well thought out and discussed, the development team has no idea what to do with them. This is something that product management expert Roman Pichler sees time and again when working with teams trying to implement agile management.

“Instead of discussing and refining the stories together, they are handed off to the development team,” he writes. “To account for the missing conversation, the product manager or owner tries to write elaborate, detail-rich, and precise stories. This turns user stories into something they were not designed to be: formal requirements.”

The product owner has to write these stories, otherwise the developers (or in a non-technical case, the team members, workers and interns) have no idea what they should be doing.

Keep User Story Development Collaborative

While research is an integral part of user story development, there should also be a collaborative effort to create them.

“When user stories are not written collaboratively, the so-called lost in translation problem happens,” software developer and engineer Eric Camellini at Buildo writes. “Either missing details will be implicitly filled by developers or the underlying motivation will drown in an ocean of details.”

Ask team members to create user stories ahead of time, and then combine them or improve upon them together as a group. This solves the problem of a lack of refinement mentioned earlier as well.

Resources for First Time User Story Creators

Don’t feel overwhelmed by the number of mapping options and user stories available to you. The goal is to tailor user story development to your team to get the best results.

If you’re not ready to follow these methods for actual projects yet, you can start by creating agile use cases as a team to solve problems around the office — like keeping a microwave clean or finding an easier way to interview employees. Agile Gov Leadership has a 60-minute exercise you can do in a team meeting to help members get a feel for creating and sharing user stories.

An infographic at To The New is another valuable resource. You can share it with your team and review it at the start of your scrum planning meeting. When a user story is incomplete or too bulky, you can point to the graphic to explain where your coworker went wrong.

StoriesonBoard curated dozens of short videos, tools and articles related to user stories that your team can take advantage of. Share slideshares and other training materials to help your team enhance their knowledge of user stories and make the process easier.

Like most elements of agile project management, your best bet is to start small. Develop user stories for a small project or within one team so you can work out the kinks and then expand the modeling to the rest of your organization.