What Makes a Good User Story?

To understand what makes a good user story, we first have to define what a user story is and why we should bother with it.

What are User Stories?

User stories are artifacts of the agile methodology that are short descriptions of a functionality focused on the benefit to the user. Users stories help direct the conversation towards the usefulness of the functionality to the user – instead of focusing on the documentation of that functionality.

Watch the video on this topic or skip it and read on…

\

What makes a good user story?

Well, a good user story is one that allows the team to develop the right functionality within the sprint in the most effective and efficient way .

This is done by writing user stories with clear descriptions that facilitate the discussion around the benefit to the user, adding acceptance criteria and using the right level of detail. Below we will explore each of these areas in more detail.

How to write good  user stories

Good user stories generally have the following pattern:

As a <user type> I want <functionality> so that <benefit>.

For example: As an admin user I want the ability to view the ACH Batch report so that I can reconcile the ACH transactions.

Mike Cohn, a well respected leader in agile methodologies, in his article User Stories and User Stories Examples says that users stories “strongly shift the focus from writing about features to discussing them.” That is indeed true and the entire focus of the agile methodology itself: it’s about discussion over documentation.

More User Story Examples

• As a branch user, I want to be able to create a new loan application by entering the member ID of an existing member, so that I do not have to re-key the member’s personal information.
• As a logged in user, I want to see my data usage statistics when I access my account, so that I can know how much data I have left for the billing period.
• As a friend user, I want to view the map pins for all the travel sites my friend has tagged in the TravelTogetherApp, so that I can see all the places my friend has been.

Using Acceptance Criteria  in your user stories

User stories are to be accompanied by acceptance criteria. Acceptance criteria are high level acceptance tests that must be true when the user story is completed. This is different from a user acceptance test as it does not go into granular details of multiple test scenarios.

The acceptance criteria is to add detail to the user story and help the developers understand what conditions must be present for the user story to be considered done.

Let’s revisit the user story above:

As an admin user I want the ability to view the ACH Batch report so that I can reconcile the ACH transactions.

Acceptance criteria for this user story:

1. Given that the admin user is on the admin console screen, when the Reports button is clicked, then display the ACH reports page
2. By default, the ACH report must show the ACH transactions for the last 30 days
3. All account numbers and PII (Personally Identifiable Information) information  must be masked in the ACH report.

What’s the right  level of detail for a user story?

A good user story has the right level of detail to make it doable within the sprint. This is highly subjective area however and not an exact science. The right level of detail will depend on the skills of the team and the length of the sprint.

Generally, you do not want one huge story with a lot of complexity. Smaller stories that address one small piece of functionality at a time is preferable. That being said, you may find that the functionalities are so intertwined that it makes sense to keep them together.

There is no set rule, but you can gauge how complex your user stories are by asking the following questions:

Is your Acceptance Criteria too long?

By looking at the length of the acceptance criteria you can determine complexity. If the acceptance criteria is very long and wordy, you might need to break the story up into smaller pieces

Are the estimates huge?

If your team comes back with a large estimate -that’s a dead giveaway! Time to make the user story smaller and more manageable.

Are you explaining a lot in the sprint planning meeting?

If you find yourself explaining a lot on one user story in the sprint planning, then that’s a good indication that the story is too complex. Especially if the team is knowledgeable in the domain and you still have to explain a lot. This means your user story needs to be broken down to the right level of detail or you haven’t written it clearly enough.

Conclusion

In summary,  what makes a good user story is one that facilitates the collaboration and discussion with the team around the benefit of the functionality to the user. A good user story is well written and at the right level of detail. Finally, a good user story includes an acceptance criteria to determine the conditions under which the user story is complete.

For more on how to write the acceptance criteria watch this video: https://youtu.be/G1BSQVZNzvM

Watch this video for more on Business Analyst Documentation Skills

For more great reads on business analysis and requirements, check out this article on Should the Business Analyst Write System Requirements