7 Tips to Write Better User Stories

It’s been awhile since we discussed the Requirements function on Agile projects, specifically upping your productivity using User Stories.

We have previously talked about documenting requirements as user stories. We have also discussed how User Stories help drive better tests through articulating requirements better. We went further by looking at Story Mapping in detail.

Today, we’re going to take a deeper look into making your User Stories work harder for you. I will share 7 tips to write better user stories, and how you can incorporate these into your Backlog Grooming efforts.

Whether you’re a Business Analyst, Developer or Tester, and especially if you are a Scrum Master, you need to learn how to improve your user stories to enable effective Agile project delivery.

With that, let’s jump right in!

#1 Keep it simple

User stories are meant to capture the smallest possible unit of a product feature. Therefore, look to break down the x smallest possible feature units that, when put together, make a product feature.

How do you do this?

Treat a user story as a conversation between two people with an expected outcome (Acceptance Criteria). You can make and stick to your own rules within the team.

As a thumb rule – every ‘Want’ becomes a User Story.

A user story should typically fit within one side of an index card. And the back of the card will contain the AC (Acceptance Criteria).

For example:

Front of the card:

• As a Premier member, I want to be able to cancel my hotel reservations at any time so that I can save on cancellation penalty.

Back of the card:

• AC1: Verify that a premier member can cancel without any penalty.
• AC2: Verify that the hotel is notified of cancellation request.
• AC3: Verify that the premier member receives a confirmation that their cancellation request is complete, and no penalty has been charged.

#2 Don’t be afraid to split large User Stories into smaller stories

Going from the previous point, your goal should be to document the smallest product feature units as individual user stories.

One of the biggest hurdles with Agile adoption is how teams struggle to break down user stories into bite-sized chunks that can be consumed within one sprint. This is what will make or break your Agile adoption efforts.

This challenge with right-sizing user stories is quite common in the industry.

“Good user stories should discuss the ‘what’, and not the ‘how’.”

Pro Tip: Do it right then and there, as you discuss the requirement with the Product Owner or the end user. This will help them internalise the stories as much as you, and will help during Backlog Grooming sessions. Being involved completely with the user stories drafting process will help the PO with backlog prioritisation. They’ll know which story is more important and hence needs to be built first..

#3 After Splitting, thinking slicing

Okay. So, we have created simple user stories.

With Agile adoption in practically every industry, the complexities may sometimes mean you have to go back to correlating User stories and understanding where they fall from within the product/requirement vertical. Bill Wake in 2003 came up with the vertical concept using the analogy of a cake, where in the focus is on all the layers in addition to the specifics. We need to be mindful that the customer at the end of the day is looking for the whole cake and not a specific layer of the cake.

Take an example of three User Stories below:

1. Create a user interface with user name and password; show errors upon encountering incorrect login credentials
2. Implement server side logic to track number of attempts and lock after 6 consecutive errors
3. System administrator should be able to view the number of login attempts

In the above scenario, the user stories are being created around different layers of the system (login entry) and delving into what may be architectural or system specifics in each user story. This is horizontal slicing. There may be situations where this may be necessary.

More often than not, however, you want to do vertical slicing, i.e., you want to build user stories around the login entry that covers all system layers and translates to real business value. Let’s rewrite the above example as vertical slicing:

1. As a User, I want to be able to login with a user id and password
2. As a User, I want to be prevented from logging with incorrect credentials
3. As a User, I want my account to be locked after 6 consecutive failed login attempts

As you can see, good user stories should discuss the ‘what‘, and not the ‘how’. The ‘how’ is the system logic, server logic, database logic that may not be useful in evaluating an end product. Horizontal slicing may end up with a list of user stories that are a bunch of how-to-do, yet not really an MVP.

Strive to have user stories that slice vertically, rather than horizontally. This technique will help you stay aware of what the customer exactly wants.

#4 Not all User Stories are created equal

Often as Developers and Testers, we look at the mammoth of user stories and start estimating into headcount months even before we could complete the formal requirements phase.

In my two decades and more with the IT industry, I have personally observed the applicability of Pareto’s principle, i.e., 80% of the value offered by a product typically resides in 20% of its features. Keeping in mind #1 (Keeping it Simple) and understanding that most of the value comes from the top 20% will help all the parties involved to chug along to finish requirements.

The point is to apply the Pareto principle to your Product Backlog, to focus on the most critical 20 percent (and evaluate if that leads to the 80 percent customer satisfaction). In my experience, identifying your top 20% features brings tremendous value to your efforts at optimisation and in shortlisting your MVP.

“A user story focuses on what the user really wants, and why”.

Of course, there are challenges in identifying the Top 20%. Your ability to do this depends on the hats you wear as a user, customer, scrum master or tester. I recommend that you start by looking at the current list of ‘done’ stories. You probably already have an MVP delivered to your customers. By measuring customer feedback and satisfaction, you can improve the value your product brings to your customers manifold.

So, go back to your product backlog, perform continuous grooming, look at your delivery pipeline, measure customer satisfaction and shortlist the top 20% features that contribute the most to your product success.

#5 Write User Stories, not tasks

As Developers and Testers, we are often obsessed with interpreting user stories into tasks (we can’t wait to build them into features). In such situations, you need a strong scrum master to hold the team back from filling up the backlog with tasks rather than stories.

A user story focuses on what the user really wants, and why.

A task explains how a scrum role (developer, tester etc.) will help deliver the user story.

Also note that a User story may involve many skillsets (from multiple teams) to meet its acceptance criteria (AC), whereas a task is often delivered by an individual or teams with a particular skillset.
So, write User Stories on your Product Backlog – the tasks can wait till you subscribe a story to a Sprint.

#6 Bump up your story mapping skills and focus on the MVP

You have your user stories all listed in front of you, often as post-its scattered across a white board. The PO starts prioritizing the critical requirements, and adds the rest to a backlog. Does this process work? Usually. Can you make it better? Of course!

1. Start with the highest ranked Feature or Epic.
2. Identify User stories on the Backlog that relate to this feature/epic. For example, if your goal is to build a solution to find a book in an online store, consider what avenues a user has to achieve this (hint: browse online catalogue).
3. What are the stories, sub-stories, tasks associated with each of these activities? The User may need to select a category, sort a list of books or use a search function to search for books in the catalogue. You suddenly have a bunch of epics, stories, sub-stories, tasks.
4. When you map it down to the task, your list of priorities for the Sprint, Release or Product iteration will become clearer.

Work with your Product Owner to identify your MVP, and with your Scrum team to agree a minimum viable solution to get the MVP to the end-user.

#7 Use the strength of your Testing team to refine your User Stories and Acceptance Criteria

When done right, Story Mapping can help visualise your product clearly, and early. And with an experienced testing team at your disposal, you can start drafting your test strategy around the story map.

Going back to the example of searching for a book in an online store, the test team can map out all the negative scenarios, e.g. when a user selects an incorrect category. Writing code to counter such negative scenarios will eventually help you build a quality product.

Your Development team gets a head start on building to pass Test Cases, and can help ensure that all the ACs are met. Furthermore, the testing team is well prepared, well ahead of time, to run the tests.

---

These tips are some of the ways you can bring your team together to deliver to customer needs in a collaborative manner. Remember, there’s always going to be more in your backlog to build than you have time or resources.

By using the right approach to writing better user stories will help focus your collective energies towards the most important requirements, and deliver customer delight!