Hints for good User Stories

Posted on October 8, 2013 | Tagged as: , | 1 comment

User stories typically describe requirements to a software system. For the client, who puts the requirement, the story offers a concrete and valuable benefit. For the development team, the story states what must be implemented and integrated in the software system. Following these two aspects, a user story is an instrument of connecting client and developer.

Wording template

User stories should follow a wording template which urges the author of the story to state the requirement precisely in one sentence. A best practice for the template was created by Mike Cohn and has the following elements:
As [ROLE] I want [SOMETHING] so that [BENEFIT].
Role is replaced by the view the story is written of. Something describes the core of the requirement and the (optional) benefit outlines the motivation of the role for the goal.
This simple sentence answers three questions: Who wants something, What does he want and Why does he want this. And it brings the answers to these questions into one single sentence.

Domain specific languge

The wording itself must be that of the client or his domain. User stories for a banking software will sound differently from that ones of an online-shop. This requires, that all involved persons (developers, product owners, domain experts) must get into the domain and work with it.

Epics to stories

User stories usually evolve from high level goals and are not written out of the box at project start. You typically start by defining epics – or large user stories on a very high level – which are stated by a single word presenting a large topic (like “customer account”). Each epic can later be split up in several user stories, each describing a single aspect of the epic.

Open but detailed

In a traditional product development process, you usually gather all requiremetns in detail in front of the development. With user stories, you only break down the user stories coming to development in the near future. This means, that it’s not worth dealing with details if a story is not implemented yet. So how detailed should a story be? As not all information is present when writting a story, t’s a good choice to keep it open but write down all affecting issues as questions with the story. On the other hand, a story should represent a solvable requirement.

No engineering, no GUI

User stories should be free of technical language which means No use of information about non-functional aspects like programming language or configurations. These are constraints and should be handled seperately. Also, no assumptions about the GUI should be found in a story.

Characteristics of good user stories

Good user stories must follow the INVEST principle:

One Response to “Hints for good User Stories”

  1. Paul February 8th, 2014 at 23:16

    User stories are best practice in agile software development. But not only there, they are even a good way for documenting requirements for software systems.

Comments are closed

agile brand development interaction design leadership mobile persuasion product management requirements engineering search seo service design system design testing user experience user story