One of the reasons user stories are used over a traditional requirements list is that they can become part of a persona for the users of the end product of the project. It helps the project manager, developers, and other members of the project and other stakeholders view things from the perspective of the user rather than from the perspective of the software itself. That leads me to my first user story tip -‘

1. Always Include representatives of the user stakeholder groups

It’s their story you are trying to tell, who is better to tell it than them? It is what they want to gain from your project that becomes important. A manager should represent the manager’s, an analyst should represent an analyst. Make them your subject matter experts (SME) and get them involved.

• Allow them to tell their story
• Ask clarifying questions when needed about the specifics of the story
• Ask questions to help make sure they didn’t leave parts of the story out and to get them thinking deeper
  • “do you always want widget A to behave this way, or are their conditions where it should do something else?”
  • “What should happen when something is non-standard?”
  • “Is it always this way?” “What happens when it’s not?”
  • And many other possibilities depending on the exact project
• Summarize their story hitting the major points
• Ask them to review the summary and work together to get it right

2. Remember the 3C’s – Clear, Concise, and Complete

It needs to be fairly obvious by reading the user story what is wanted and why it is important to have it included. Work to create the user story in as few words as possible, but still maintain a clear and complete message. (*Anybody who has read any blog post of mine, they probably realize that being concise is not something I am good at)

Additional Books on User Stories

• User Story Mapping: Discover the Whole Story, Build the Right Product
• User Stories Applied: For Agile Software Development
• Fifty Quick Ideas To Improve Your User Stories

3. Remember the 3W’s – Who, What, and Why

You want to make the story as simple as possible while hitting all the major points:

• Who wants/needs it?
• What do they want/need?
• Why do they want/need it?

4. Test it out on unsuspecting volunteers

I first learned this testing method with software applications, and it works for some user stories as well. You gather some user stories and have people who are not involved in the project, or at least not involved in the creation of the stories to be tested and let them read the stories. If they can explain what it is that is wanted/needed then the user story is probably pretty good.

Important things to consider, highly technical user stories may not be able to be explained by non-technical people. Now it is good practice to keep the stories as non-technical as possible, it can be easier said than done with some requirements.

5. Differentiate between “Want” and “Need” when possible

If something is needed, specify it in the user story. A need should be considered a potentially higher priority item than wanted items. This may not always be possible in the early stages. If it isn’t, default to a “Want” rather than a “Need” and work to decide on the need/want during prioritization.

As a user, I need my account information protected so someone cannot steal my banking information

As a user, I want to be able to use single sign-on so that I can save time by not having to type my username and password every day.

One is a need, a requirement for the project to be successful, the other is something that is nice to have and could certainly add value.

While we are on the subject of value, want, and need, consider why you want or need something. If you cannot figure out the “why” something is needed/wanted then perhaps it really isn’t needed or wanted.

6. Include a description and acceptance criteria outside of the user story

You have your user story, but how do you know when you met the goal stated in the user story? You do that by having your user story and including a list of elements that enhance the user story.

As a manager, I want to be able to total up sales at the end of the week so that I can produce my sales reports

Acceptance Criteria:

• Allow for a date range entry with a single button to grab reports between the specified dates
• Include sales related information for each employee under the manager logged in
• Include this feature for all sales managers only

Some teams, including how I learned it, use index or note cards. They place the user story on one side and the acceptance criteria on the other. That may work for co-located teams but is not practical for distributed teams.

7. Don’t be afraid of stories with a large scope of work or undefined set of acceptance criteria

The initial creation of many user stories may result in stories that are too large. This is okay. You may not always know all of the needed requirements and you may not know how to define things like “easy to use” user interface.

Think progressive elaboration. As time goes on, work to clarify the user story. Figure out what “easy to use” means through continued collaboration with SME’s and other project stakeholders. The more measurable you can make your requirements, the smoother things will go. For example, “easy to use” could mean that 80% of random testers took less than 5 minutes to figure out how to use the new software.

It is also okay to have user stories of various expected work sizes or scope. Some work items will just be larger or smaller. Find ways to break down user stories into more manageable chunks of work as you work on elaborating the stories and prioritizing them.

8. Compare user stories by creating a story map

Some elements can be related. Some user stories will have to have other things done before them in order to be done themselves. Some user stories will complement each other. Some user stories you thought were “Wants” may end up being needs because a “Need” relies on it. This process has the additional benefit of helping to break larger user stories down into smaller ones.

There are many ways to map. One common way is to use a grid system, like a scrum board. You place along the top the main groups or steps in your project and you group your stories under the group titles. Another similar method will use the index or note cards I discussed in tip #6 and place those on the boards in an attempt to figure out an order.

With the physical board method, I think it is harder to visualize the stories. Sometimes there can be a lot of interconnected stories that need to be broken down further, and often when you first begin you need to further elaborate on the stories to work out those links. Software methods that do this can be extremely difficult to figure out but are well worth the effort of learning.

As requirements become clearer, these stories can be broken down, sliced, and refined – but in the initial stages of the planning you may only end up with vague details and mapping can help you refine them.

9. Keep the Minimum Viable Product (MVP) in focus

It’s fine that you want to make a sales software application that also alerts users to the top salesman of the month. Should you be building that feature first?

Your user stories should become progressively elaborated, and that begins with those items that concern the MVP. It doesn’t help to spend hours planning and elaborating on stories that may never get used. Focus on what you need to move the project to a usable state. If you are replacing a process, the first step is to make the new process as effective as the old process. The new process may be able to give you numerous advantages that you can build in later but focus on the minimum usable state of the process first.

Reflection

View my tips on splitting user stories: How Do You Split User Stories?

I am sure lots of other tips exist from other people (I would love to hear them), these are just the ones I am familiar with and I found the most helpful.

The point of user stories collectively is to tell the story of what the product you are building will look like in an easy to understand format and language. The individual user stories should evolve to reflect small pieces of the product, and represent chunks of work.

Sources

Most images from pixabay.com