Article

Learning at Work Week #1 – What makes a good User Story?

16 May 2016 | Gary Cheung | About a 6 minute read
Tags: Academy, Agile, agile methodologies, Learning at Work Week, Product Analysts, Product Owners, Scrum, Scrum Master, User Stories


I’m sure you are reading this to find out “what makes the perfect user story?” and hoping to come out with a cookbook formula which gives step-by-step instructions on how to do this.

The result of this reading this won’t provide you with the above, but the idea of this post is more to highlight what makes a “user story” a user story. Fab!

Let’s get started….

What is a User Story?

A “user story” can be thought of as tool which helps describe a software feature which is to be delivered to an end user. It describes the behaviour and functionality of the feature to the reader and the developer.

The idea behind it is so that a developer can look at the user story, see the requirements, constraints and expected behaviour so that they are able to provide an estimate of effort against it. AKA Story Points.

It’s also used by QA testers and UAT testers so that they are able to write test cases and by management so that they are able to understand the behaviour of the feature and ensure that it’s following the business requirements of the overarching project/epic.

Consistent Structure

If you’re a Product Analyst, there’s no doubt you’ll be writing more than one user story during your life time. With this in mind, it’s important that you keep the base structure of your stories similar. If there’s a house style which is currently in use, it’s important that you should adopt this to avoid confusion. This doesn’t mean that if you spot something which could be improved, that you should ignore it. Bring it up with the relevant people and propose the improvements that could be implemented.

When creating a story in JIRA, there are different formatting tools which allow the author of the story to easily maintain a consistent structure. Please find the link to my template which I use to create user stories here.

Defined Goal

The idea of a goal is to provide context to the reader as to why this user story needs to be created and highlight the benefits to the user when it’s delivered

We all know this as the following;

As a [Role]

I want to [Feature]

So that [Benefit]

This is a simple but effective way to describe the feature. To some it may be obvious why the user story needs to be delivered, but including the goal within the user story avoids any awkward questions down the line such as; “why are we doing this?” or “what benefit does the user get from this?”.

Acceptance Criteria

The acceptance criteria should be seen as the conditions the user story must meet in order for it classed as “done”. Presenting these as a clear bulleted statement which can be categorised as “pass/fail” allows developers and readers to easily identify what exactly needs to be built.

The story should be written before any development for that feature has started. Otherwise the story becomes verifying the functionality that has been implemented, rather than the verifying that the functionality meets the users needs and expectation.

They should use simple language that the customer would use and avoid jargon/acronyms where possible. This enables testers of the user story to easily understand what needs to be delivered so that they are able to transform the acceptance criteria into test cases.

It is also worth highlighting that the acceptance criteria should state the scope of the user story and any constraints which might be present. This is to ensure that wasted effort and time is minimised.

Ultimately the idea is to get the feature into production, so why hinder that by hiding critical information within a huge block of text as opposed to simple sentences.

In summary, the acceptance criteria (in my opinion) should be;

  • Simple bulleted pointed list
  • Each point can be marked as “Pass/Fail”
  • Use simple language and Avoiding jargon if possible
  • Include links to screenshots/documentation which provide supporting information

 

Acceptance Tests

Now we come to the point where we are able to provide more context to the acceptance criteria which we have already defined. These are sometimes referred to as user scenarios.

I personally think of user scenarios as examples of the acceptance criteria. This helps QA and UAT testers to identify the behaviour of the feature. It provides them with any assumptions which have been made in order to test the functionality.

The format which is typically used can be found below;

Scenario #1: [Basic description of scenario]

Given [Some precondition]

When [Some action]

Then [Expected result]

A good rule of thumb would be to try and include most of the acceptance criteria within at least one user scenario. Of course this is not a strict rule and should be used based on good judgement.

To only have user scenarios as acceptance criteria does not fully describe the design or the UX constraints of a feature. The same can be said vice versa where having only acceptance criteria as bullet points does not provide context to a person who has no idea about the behaviour of the feature.

I believe that the two should co-exist to provide a holistic understanding of the feature.

Attachments

This section I wouldn’t say is mandatory, but I would recommend including information here where possible. Having this will provide more context to the user story and help readers and developers understand what exactly needs to be done.

Things to include could be;

  • Screenshots
  • Wireframe designs
  • Copy text
  • Links to documentation

Summary

These are just some of the key points which I wanted to highlight as to what forms the basis of a “good” user story. There are of course many other factors to consider, but in the interest of not creating a dissertation, I have boiled it down into the following:

The end goal of a user story should be that;

  • It has consistent formatting to avoid confusion
  • It captures the necessary business requirements
  • It documents the scope and expected behaviour of the feature
  • It contains enough information for developers to estimate the effort of work
  • It can be understood by someone who has little/no context by using simple language
  • It contains user scenarios where appropriate to provide further context
  • It contains the necessary attachments to provide further understanding

A final point I would like to mention would be when writing the stories, write them in a way where it can be fully delivered. If the story involves having to create an API link between the front end and database, that should be part of a single story. That way when the issue is delivered, it provides tangible value and other similar tasks part of the same epic, can be delivered in a more efficient manner.

Any questions or comments? Let me know what you think in the comments section below!

 

Read More From This Author

Share this blog post

Related Articles

Careers

We’re looking for bright, dynamic people to join our team!

Discover More Roles