How To Create a Perfect User Story Step by Step Guide

Feb 18, 2018 10:51 · 1032 words · 5 minute read scrum user story requirements guide

Creating good user stories is vital to any scrum project. Here I try to come up with a simple approach to creating backlog items for those who have little experience with that. This article aims people who are new to user stories and need practical advice right now.

Example of what the user story should look like

User story Acceptance test/criteria
As a member, I want to access featured tests so that I can learn advanced English. A member can pass the test marked as featured

An admin can define featured tests via admin panel

Only members can see rankings of the featured tests

This alone already a good user story. Let’s see what is right about it:

  • It is lean and straightforward. Quick to read and not too technical.
  • It explains the purpose of adding this feature to the product.
  • It has some high-level details but still encourages discussion.
  • It looks easy to implement.
  • It has a definition of done.

There is a separate article on how to write requirements so please check it out too.

Note, the user story isn’t ready to do the coding right now, and it shouldn’t be. A user story aims to give a sense of the user needs. Technical details and detailed acceptance tests will emerge from discussions with the team on planning meetings.

Start with expressing value to the business

Typically, the template that user story built upon looks like this:

As a <user type>, I want to <function> so that <benefit> .

<user type> - should be well-known. The whole team should share the understanding of the user types, and it is a good idea to have a document outlining the terms and users in the system.

<function> - understandable English description of what the user should be able to do. Not too technical, not too detailed. Not too general as well.

<benefit> - arguably, the most important part. It is where it is explained why the function should be created in the first place. This is the product owner’s chance to communicate the business goals, values, and priorities to the team. Consider with identifying the benefit first, then a function.

Add more details

Now, it’s time to add more specifics and clarifications. This is a meat of the user story, something that defines what actually will be done. The acceptance test is what sets boundaries, and it is a responsibility of the owner to express all the critical aspects of the story. Make a comprehensive and detailed list of criteria to communicate the purpose of the story. Using bullet points is a good idea.

No matter how detailed the definition of done is, the conversation between the product owner and the team should take place. Acceptance criteria should be adjusted after discussions to make sure that the feedback is accommodated.

Don’t skip non-functional requirements such as environment where the system suppose to work, performance required and such.

Remember to keep the acceptance criteria simple and sound. Examples:

Too vague

  • A member can view featured tests

Too specific

  • A member can view bold title, greyed subtitle, description up to 25 words, date, number of questions, added date and level.
  • A member can click a blue button to go to the particular test page where the test starts automatically with the first section and the first question in it.

Just right

  • A member can view the featured tests in the site’s navigation
  • A member can view the list of tests with main fields on the listing page
  • A member can start a test on the listing page

Ask team for the feedback

Go to the team and ask them to provide their feedback. It might be a good idea to have a meeting to discuss a bunch of stories all at once even tho they might not be included in the next sprint. The team will suggest the ways to optimize the story and give you an idea of the complexity of the implementation.

Reiterate and adjust the story to reflect the results of the discussions. Repeat until done. By that time there will be a good understanding of the scope of work and efforts needed to complete it. Note, that the acceptance criteria will be formalized only during the sprint itself. QA engineers will outline specific tests they will be running against the system.

Assign a priority

First things first. Don’t go too far and don’t plan too much ahead. Plans will change inevitably. Once the story looks decent, give it a priority so that the team knows where the project is going. There is nothing tricky about priorities - just re-order the list of stories with the most important on top.

Common pitfalls

In order of frequency of occurrence:

  • No backlog at all. I see it way too often when it is virtually unknown what will happen after the current sprint. Product owner might be well aware of it in his head, but everyone else has no clue about these plans.
  • Not enough details. Too many things seem to be obvious while they aren’t. What evident to one person, might be a complete surprise for another. Make sure you explicitly outline the essential aspects no matter how trivial you think they are
  • Huge backlog with no priorities. It is tempting just to pile up items into the list and believe they will get organized automatically. An unordered backlog has little value. Make sure anyone in the team can look at the list and tell what the next development iteration is likely going to look like.
  • Technical tasks instead of the stories. Having too much of technical functions may result in having the software that either doesn’t work as you expect or not working software at all. Let the team decide on the technical aspects.

Conclusion

Just get started with the backlog and keep improving it from sprint to sprint. Gather feedback, analyze, adjust, repeat.

Creating good user stories is vital to any scrum project. Here I try to come up with a simple approach to creating backlog items for those who have little experience with that. This article aims people who are new to user stories and need practical advice right now.

We will notify you about new posts every few weeks