How to write a good User Story?

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 or no experience with that. This article is aimed at people who are new to user stories and need practical advice right now.

Example of what the user story should look like

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

• It is lean and straightforward. It is a quick read and not too technical. It explains the main 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” - i.e. It sets up a clear definition for success.

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> .

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

- understandable English description of what the user should be able to do. Not too technical, not too detailed. Not too general either.

- 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 the function.

Add more details

Now, it’s time to add more specifics and clarifications. This is the meat of the user story, something that defines what will actually be done. The acceptance test is what sets boundaries, and it is the owner’s responsibility to express all 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 in which the system is supposed to work, the performance required and so on. 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 though they might not be included in the next sprint. The team will suggest 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 the nature of effort required 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 far ahead. Plans will inevitably change. 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 may be self-evident to one person, might be a total surprise for another. Make sure you explicitly outline the essential aspects no matter how trivial you think they are

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 many technical functions may result in having software that either doesn’t work as you expect it to, or worse, doesn’t work at all. Let the team take the final call on 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 or no experience with that. This article is aimed at people who are new to user stories and need practical advice right now.