Agile Development: How To Write Effective User Stories

A user story is a short and simple description of the customer’s need. It is usually told from the perspective of those who are requesting the new feature or requirement. A user story is short and sweet, but prompts the developer to get a handle on what is required. It makes it easier for the developer to produce an on-target feature of superior quality, and allows them to understand the goals and needs of the customer more quickly. It is normal to write a user story on Post-its or index cards.

Usually, user stories have a specific format, such as the following:

“As a [persona],
I want to [do something],
so that I can [realise a reward].”

This is a sample from my training course where we ask students to use Lego to build features

The user story prompts the user to ask questions, and suggests, for instance, specifying not just any cow, but a cow that can be milked.
Using lego to plan creation of stories

Use the acronym INVEST to get to the best user stories.

So a user story should be all of the following:

Independent (I): A user story should not depend on another one. Dependent user stories are difficult to estimate and prioritise, and removing a dependent user story often causes problems in others.

Negotiable (N): A user story is not just a text detailing the features that the product owner expects, or a piece of functionality that will be implemented. Look on a user story as a starting point for a conversation, or an opening problem for the team to suggest solutions to.

Valuable (V): We cannot just create fun user stories. We must describe the value that the customer will get from this user story.

Estimable (E): There must be enough information to allow the team to make an estimate about the user story, otherwise it cannot be started.

Small (S): A user story cannot take more than one sprint to complete. Any user story larger than this will be impossible to plan or estimate safely. If it’s too big, create an epic and split it into smaller user stories.

Testable (T): If you cannot test a user story, you cannot know whether it’s worked. If a specific user story cannot be tested for lack of information, do not put it in your backlog.
Use themes and epics when necessary.

If you use the INVEST concept to create user stories, and can keep to it, you’ll have good quality stories. In some situations you will see the need to separate them into themes or epics.

Themes: A theme is a group of user stories that share attributes in common. Often, multiple user stories will have similar goals, or be related in an obvious way. All of them are directed together to a single path; however, they do not need to encapsulate a specific feature or necessarily be delivered together. So a theme may contain several epics or several user stories.

Epics: An epic is a great user story that cannot be completed in a single sprint, resembling a theme being built with multiple stories. Although the stories that make up an epic are completed independently, their value to the business may not be delivered until the entire epic is complete. This means that it does not make sense to deliver an epic until all the stories tied to it are complete.

Althris provide Scrum Master Training in Dublin and Cork, check out our PSM sample exam papers.