In the context of agile projects, so-called user stories are often used to describe requirements. To formulate these, teams often commit to a fixed scheme to be able to describe the following main aspects: WHO (1) demands WHAT (2) and WHY (3)?
One of the most used templates is as follows:
“As
The following are some examples of user stories:
– “As
– “As
– “As
As you can see, the format of user stories can be applied to both technical and non-technical systems.
Furthermore, user stories are usually extended to include other aspects such as Acceptance criteria added in order to specify this user story in more detail and to be able to accept it afterwards.
User stories offer the following advantages for requirements definition:
– They ensure that the desired requirement adds value to a specific role or persona, thus promoting customer-centric developments.
– They are easy for all stakeholder groups to understand and, because of the “story” format, encourage communication and discussion.
– They are solution-free and therefore offer implementers the opportunity to find the best possible solution.
– They promote understanding and transparency because the reason for the requirement is stored.
– They can be written quickly and can be followed step by step by bspw. Acceptance criteria to be refined,
In agile projects, the formulated user stories are recorded in a so-called “product backlog”. This thus represents a dynamic list in which all requirements are collected. Although the backlog must be continuously maintained, refined and prioritized, the overview is often lost in larger projects, and the macro level in particular suffers from this.
User Story Maps are an excellent tool to get a holistic overview and to visualize the user stories in a special form. Whereas a product backlog represents user stories in a one-dimensional list, a user story map represents them in a two-dimensional matrix. This offers the following advantages, among others:
- One gains a holistic and visual overview of the requirements catalog
- Dependencies between user stories can be better identified
- Release planning support
- Easy identification of requirement gaps
- The prioritization of user stories becomes easier to identify
- Understanding and communication are promoted
A user story map is usually read from top to bottom (coarse to fine requirements) and from left to right (chronological order) and thus contains the following components (these can also be expanded or reduced):
- Users/personas trying to achieve a specific goal along the user story map.
- The activities of the users, which in turn group various tasks under them.
- The activities and tasks are also referred to as the “back bone” of the user story map.
- This “backbone” is arranged from left to right in a temporal and narrative flow.
- Below the “backbone” are then the various user stories that belong to the relevant tasks and activities.
