User Stories: Facts and Myths
A user story is usually written by a customer describing a small piece of system functionality, in a simple and easy to read sentence. A well-written user story will describe what the desired functionality is, who it is for, and why it is useful.
In other words, a user story is a very high-level requirement, containing just enough information for developers to produce a reasonable estimate to develop and implement it.
A typical user story follows this format "As a [user], I want [function], so that [value]”
This easy format allows anyone involved with the project to help write them.
Below are examples of user stories:
As a valued customer I want to receive 15% discount on all my orders so that I am rewarded for my prior orders.
As a photo uploader I want to be able to assign privacy levels to my photos so that I can control who I share my photos with.
When working with user stories, IT departments need to consider the following things:
Use simple tools - Try not to use sophisticated tools to document user stories. Stories handwritten on index cards are very easy to work with, easy to update and easy to maintain.
Customer writes story - Teach and encourage your customers/users to write the user stories themselves.
Estimate stories – Every story should include an estimate from the developers. There are various ways to estimate, pick the one which works best for your customer and your team.
Indicate priority – Once you start creating user stories, you will end up with more stories than your team can handle. Prioritising the stories while creating them will help the team later to focus on most important ones. This will also help with release planning.
Right Size - Make user stories the right size. Ease of implementation is more important than actual size, but if you find a user story too big, break it into smaller user stories. User stories that are too small could be combined into a bigger story.
Make them testable – If the story cannot be tested, it cannot be verified. Verification tells you if the customer received the value requested. Stories such as ‘As a customer service representative I want the screen to display information fast so that I can produce quotes quickly to my customers’ cannot be tested as ‘fast’ is too subjective.
You may hear the acronym INVEST being used when user stories are discussed. It stands for qualities a good user story should have:
Independent - The user story should be self-contained and not dependent on any other user story.
Negotiable - User stories should be able to be changed or rewritten right up until the development stage.
Valuable - A user story must always deliver value to the end user.
Estimable - If a story is not estimable it is not implementable.
Small - User stories should be small enough to be implementable in one release.
Testable - The user story should have enough information for verification.
Some myths about user stories include:
User stories can only be used in an agile environment.
User stories may not contain enough information for developers to implement.
User stories can only document functional requirements.
User stories can only be used on small scale projects.
User story writing is a huge topic, but I hope these tips will give you some direction and enough inspiration to start working with user stories.
This article originally appeared in the June issue of IT Brief.
