The Art of Writing a Good User Story

September 2, 2020

The goal of a good User Story is to provide a valuable and useful experience to your users and should aim towards continuous deployment to production. The important components of a User Story are the technical layers involved from presenting the UI’s information to persisting it (and everything in between middleware, infra, endpoints, and more). The sum of these components should provide functional value to your users (except core teams’ stories, where they would serve other internal teams).

A User Story that is written properly will help make substantial steps towards an Agile organization’s ultimate goal, which is to become predictable. For that to happen, you will need to provide Scrum Teams with self-contained pieces of work to do that can be relatively estimated considering risk, uncertainty, impact, and effort. Those self-contained pieces of work to-do should come in the form of a User Story. Anyone in the organization should be able to create a User Story while Product Owners approve, mature, and prioritize them for teams to complete.
[adinserter name=”Software-Development-eBook-Offer”]

What is a User Story?

A User Story is a short, simple, clear description that answers the following fundamental questions:

Who is going to benefit from this effort?
Why are we dedicating time to this effort?
What is it that we are doing?

This simple description is just a conversation starter that should evolve into a complete description of also HOW do you implement WHAT you need to implement. The definition of HOW needs to come from the Scrum team, never from the Product Owner or anyone else.

Sharing that conversation starter with the Scrum team without restrictions as to HOW to accomplish the goal, assists in generating Domain Knowledge within your Scrum teams and eventually helps them evolve into Product teams that are focused not only on output but also on the outcome.

By allowing the team to define the HOW, with guidance from your Architecture team, you can enable creativity, continuous improvement, and a clear understanding of purpose.

If a member of the Scrum team cannot answer WHY they are doing what they are doing, then they should make a hard stop and assess a better User Story definition.

A Template for a Good User Story

To keep the description simple at the initial state, it is advisable to make use of the template defined by Mike Cohn, a founding member of Scrum Alliance.

As a <user persona>, I want <some goal> so that

Where:

User persona: WHO
Some goal: WHAT
Some reason: WHY

Now that you have defined the initial state of your User Story, it is time to start conversations to mature the User Story. An easy to remember approach to mature user stories is to use the 3C’s.

The Three C’s

The 3C’s is a mnemonic to easily remind your team what needs to occur in order to evolve a story to a state that can be accepted by a Scrum team to work on it (Definition of Ready).

The 3 C’s refer to Card, Conversations, and Confirmation. Let’s explore the meaning of each of them:

Card

The card is the starting point of a User Story. It has to be a clear, simple statement that at its initial state can fit onto a card (post-it). A good approach is to write that statement using Mike Cohn’s template mentioned above.

Conversations

Once you have defined the initial statement, it is time to have conversations

These conversations should occur with stakeholders. Stakeholders are everyone that has an interest in the product. These stakeholders can provide context on the problems you want to solve to validate pervasiveness, feasibility, priority, and more importantly, the solution that addresses most of the issues for most users

The conversations should also include the Scrum Team, ideally in the form of grooming sessions. There are two primary goals of these conversations; to tailor the scope of the User Story, based on the team’s domain knowledge, and to define HOW the user story should be implemented, as well as provide an estimate of the effort required.

Confirmation

Once the story has a clear statement of the WHY, WHAT, WHO, and HOW; it is now time to confirm that you know how to call this story Done. In order to do that, you need to define a robust Acceptance Criteria, which will be the final confirmation of a User Story.

Acceptance Criteria

Defining Acceptance Criteria is one of the essential actions to do while writing a good user story. It is an objective way to validate that a story provides the required value. The best way to define an Acceptance Criteria is in the form of a checklist, asking questions that require a Yes/No answer.

The Product Owner, Scrum Team, Design, and especially QA should be involved in defining that Acceptance Criteria approved by the Product Owner. To better understand the importance of QA on Acceptance Criteria, please take a look at ATDD (Acceptance Test Driven Development).

If you can define a binary list of items (Yes/No) for an Acceptance Criteria, that same list becomes the main milestones or validations our QA team member will translate into Test Cases (Pass/Fail) to ensure the purpose is being met. While defining Acceptance Criteria, it is important to ensure all parties involved clearly understand the difference between an Acceptance Criteria and a Definition of Done:

Acceptance Criteria: Binary statements unique to each user story to certify a user story’s purpose have been met. E.g., User can post comments on a forum
Definition of Done: A standard set of technical requirements for a Scrum team to call a story Done. E.g. Code coverage > 80%, All PRs with approval, Code merged using agreed branching strategy, ECMAScript Coding Standards met.

Another valuable checkpoint to have for the team is a Definition of Ready (DoR), which is the opposite of the Definition of Done (DoD). A User Story that meets the Definition of Ready means that the story is immediately actionable and the team can start working on it without known impediments. A solid Definition of Ready should apply to any story, and it should come in the form of a checklist so the team can validate if it meets the DoR criteria to be a candidate for a Sprint backlog.

Having a DoR serves as a “gate” for the team to accept a story. Having a DoD serves as a “gate” for the team to complete a story.

INVEST

Now that you are able to generate a User Story that addresses the WHY, WHO, and the WHAT, you need to make sure the team can work it. An excellent framework to accomplish this is INVEST. INVEST is a simple mnemonic used to validate if you have written a good user story. Additional details on the INVEST criteria are provided below:

I – Independent. If you cannot remove dependencies look for those to be downstream, not upstream and identify them in advance
N – Negotiable. A story is not a contract; it can mutate over time. It is a co-creation between several parties
V – Valuable. A story should provide value by itself and ideally be a Potentially Shippable Increment
E – Estimable. A good user story can be estimated by a Scrum team, meaning it has all the required information for the team to provide a reliable relative estimation
S – Small. Small enough to be consumed within a single Sprint or iteration
T – Testable. If you generate a potentially shippable increment that is vertically sliced, it can be tested end to end, that is the ultimate goal of a story in terms of QA.

Vertical Slicing

A bad practice commonly employed by Scrum teams is to horizontally slice their user stories. This results in poorly formed user stories that do not fulfill the criteria of INVEST as outlined above. The consequence of this are isolated user stories that don’t provide value by themselves and require downstream dependencies to be able to be deployed.

To avoid this, it is important to ensure that stories are sliced vertically. This means not having backend only or front end only stories (there will be situations where this cannot happen, especially if you are building a complete service that will be used from x different clients). The main goal is to produce those mentioned Potentially Shippable increments.

Let’s consider the following scenario: Your User Researcher identified that subscribers want to have a way to interact with the community while browsing your platform.

A good example of splitting user stories vertically would be:

As a Subscriber, I want to be able to post comments so that I can start conversations with the community
As a Subscriber, I want to be able to reply to a post so that I can provide my opinion to someone else in the community
As a Subscriber, I want to be able to rate a post so that others can locate content that was useful/not useful for me

A bad example of splitting user stories horizontally would be (with the exception of core teams or full services implementation):

As a Scrum team member I want to generate an endpoint to that I can persist Subscribers comments
As a component, I want to receive information from backend so that I can display Subscribers’ comments
As a Service, I want to generate a composer for mobile so that I can be used on apps

Conclusion

User Stories are a blank canvas. A substrate upon which to create your Product. You just need to make sure that those User stores are sliced properly, INVESTed, and possess clear Acceptance Criteria. To that end, you need to allow and promote conversations with stakeholders, learners, and engineering. The sum of those conversations will act as the underdrawing for your masterpiece.

‘Would you tell me, please, which way I ought to go from here?’
‘That depends a good deal on where you want to get to,’ said the Cat.
‘I don’t much care where -’ said Alice.
‘Then it doesn’t matter which way you go,’ said the Cat.

Lewis Carrol – Alice in Wonderland