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.
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.
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.
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.
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.
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.
Good user stories must follow the INVEST principle:
One Response to “Hints for good User Stories”
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