How to write great user stories

This post is for business people (non technical) who need to write a user story. Lets start with a few basic terms used, then move to my top tips.

 

Basic Terms

What's a user story?

User stories are probably the most effective way to capture what changes need to be done to a business system. It's also a super simple way for a business person to communicate to a software developer.  Writing a great user story is easy, and when you follow the simple rules listed below you'll create consistently great user stories.

 

What's an epic?

Very similar to the writing of books, an epic is a big story.  There is no secret formula that separates a user story to an epic, however if you can write some sub-stories out of it, you have an epic. Its just a label we apply to big stories.

 

What's a persona?

A persona is the kind of person interacting with the software system (sales person, sales manager, executive, marketing manager etc more on Personal here) and is a great way to capture your insights on them.

 

User Story Tips

 

1. Stick to a simple format

As a <type of user> I <want/can/am able to/need to/etc.> so that <some reason>.

Then as in step 6 below list the testing criteria.

 

2 Write from a point of view

As its name suggests, a user story describes how you as a user interact with the system. You should therefore write the stories from your perspective.  

You see business systems behave and look very different to different people based on their system access and permissions, so by starting with who you are you have said many things to a developer.

 

2. Start with Epics

As mentioned above, Epics are big user stories.  Starting with epics allows you to get the main idea out without committing to the details. 

 

3. Then get more detailed

Break your epics into smaller, detailed stories until they are ready. Everyone should have a shared understanding of the story’s meaning; the story should not too big, and there has to be an effective way to determine if the story is done.

 

4. Use personas if its not about you

If you are not writing a user story about yourself, then use the persona concept to help craft your user story.  The persona goals help you discover your stories. Describe what functionality the system has to provide to meet the goal of this persona?

 

5. Keep your stories simple

Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what’s important, and leave out non-essential information. Use the template listed in step 1 above when it is helpful.

 

6. How can someone know its done?

After each user story, add a description for the conditions that have to be fulfilled so that the story is done. This is called the Testing Criteria. The testing criteria enrich the story and make it more precise and testable, and they ensures that the story can released. Note that if the story is detailed make sure the testing criteria is equally detailed.  This is everyones quality control step.

 

7. Use White Board

Even if your stories are stored electronically, it is worthwhile to write them up on the wall when you write new stories.  Whiteboard facilitates collaboration, every one can grab a pen and jot down an idea.  Stories can also be easily grouped to check for consistency and completeness and to visualise dependencies. 

 

8. Write Stories locked in a room

I always lock the team in a room with a white board. A user story is not a specification, but an communication and collaboration tool.  Stories should never be handed off to the development team. They should rather be part of a conversation: The system owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories.

 

9. Keep your Stories Visible and Accessible

Stories want to communicate information. Don’t hide them on a network drive, the corporate intranet jungle, or a licensed tool. Make them visible instead, for instance, by putting them up on the wall. 

 

10. Do a final check

Run over your user stories and check that each one is clear, feasible, and testable. When the final check is done, congratulate yourself and the team,  you are now done on your user stories and ready to hand over to the system development team.