Agile teams create user stories in order to be able to control and realize customer needs, such as requirements for software or other services, in a project-related manner. In addition to a fundamentally simple structure, which defines what exactly and why the customer wants a certain business solution, user stories have the great advantage that they can be expanded in great detail or combined with other methods of target customer analysis.
In (online) marketing, the customer has long occupied a very central position. Those who optimally serve the group of people to whom their own goods or services are primarily directed in blog articles, product descriptions, advertising copy, etc., generally increase their chances of success enormously. Today, personas and customer journey mapping have a permanent place on the marketing agenda of many companies that really want to understand customer wishes or user needs. However, the approach of user stories is still uncharted territory for many.
What are User Stories?
According to the definition, user stories as part of the Agile Work are concrete user scenarios that are formulated in everyday language and in particular provide insights into specific requirements (for software, web design, marketing, etc.).
Basically, user stories are written from the perspective of likely users or customers and capture the"who wants what, why?" regarding a specific application or issue, process, etc. Using such stories, agile teams can easily determine customer needs and not least customer problems in a very clear way.
The principle originates from agile software development, but has long been used in other areas of agile teamwork as well. In accordance with its agile background, the user story is sometimes also referred to as the agile story.
The user story should not be confused with a use case. The latter also represents requirements in natural language and in the context of specific users, but here success and failure scenarios of a formulated technical problem are represented. Thus, the use case approach includes several scenarios. The user story, on the other hand, is limited to one concrete scenario.
How do you create/write user stories?
When generating user stories, there are a few things to keep in mind - despite the basic simplicity of the approach. First of all, such stories should always be aligned with a specific implementation template so that they are really effective. In addition, you as a user should be able to estimate the effort and know what user story splitting, the INVEST principle and dependencies between user stories are all about.
A user story should always be written in the shortest possible sentences and in simple words. This ensures that all colleagues involved can understand it, even without expert knowledge. The formulation is always done from the perspective of the customer or user. It is important to name a real benefit.
In particular, the story should highlight who wants what and why. The cornerstones of the question "who", "what", and "why" are to be relatively freely assigned a concrete user or role (who), a fact or function (what), and a reason or value (why) according to the respective context. This results in the following basic sentence structure when writing a user story: As (user), I want (function) to achieve (value). In this context, important terms are Epic Agile and Story Mapping Agile. User stories are collected in agile epics. These collections describe requirements in higher levels of abstraction. The user stories here form the individual steps that users or customers go through until they complete an Epic. To create an agile user story mapping, rough process and work steps are recorded individually in epics and presented in a visual user story template. Using such a visualized user story mapping, the specific requirements can be worked through very clearly. The planning of tasks with regard to the achievement of the respective goal can thus be better estimated and precisely compared at any time of the development using the map. Deviations can be detected as quickly as possible and a prompt, targeted response can be made.
An important question when creating user stories is: How do you correctly estimate the corresponding effort? The short answer is: in person days or with story points. With story points, it is not primarily about the time required for a user story, but about recording its structural properties. These in turn can be used to determine the effort required. To do this, the team first defines a criterion or a combination of various criteria. A typical criterion is complexity. When using person days, all necessary work is identified and summed up. Often a user story of medium size serves as a reference here. The estimate is then made in comparison to this reference.
If user stories are too large, they need to be split to be able to realize them within a sprint. How to split should be strictly based on the value of the user ("As a [user], I want[feature] to achieve [value].") and not on the technology.
The process is optimally done as a team. This allows avoiding unnecessary dependencies between user stories, early description of solutions, and excessive production of less solution-oriented spike stories.
Acceptance criteria help to determine whether user stories have been successfully implemented. Here, key results are defined that are to be fulfilled by the user story. A much-used way to define acceptance criteria is to question keywords. The latter are specifically specific verbs, adjectives, and nouns:
- Who does what, when, and where?
- What happens as a consequence of this action?
- What options does the actor have?
Using such W-questions, acceptance criteria are relatively easy to establish.
The INVEST principle supports agile teams in defining whether a good quality user story has been created?
Determining quality or guaranteeing it to a certain extent is important in order to be able to generate maximum benefit from a user story.
Due to the undoubted relevance of this issue, we devote more detailed attention to INVEST below.
User stories should always be independent of each other. In practice, however, this is not always as easy as it first seems. Technical, content-related or functional, time-related or normative or regulatory dependencies regularly emerge. Even different competencies in the team can indirectly lead to dependencies in the realization of user stories.
In order to effectively exclude such and similar dependencies, it helps to perform a visualization in the sense of user story mapping. In the course of this, it should be possible to quickly identify critical points. An alternative method is to document dependencies in separate tables or as supplementary notes.
What makes a good user story?
In order to ensure high quality and, ultimately, maximum benefit for a user story, the INVEST principle mentioned briefly above is generally used. This requires the following six quality criteria.
- I (Independent): The user story should not be dependent on another user story.
- N (Negotiable): The user story forms a basis for discussion and can be further developed together.
- V (Valuable): The user story manifests a real advantage for the user, customer or client.
- E (Estimatable): The user story can be estimated in its scope by an experienced team using sufficiently concrete details.
- S (Small): The user story is not too extensive and is limited to the essentials in the respective context.
- T (Testable): The user story can be tested for its information content.
In addition, the following factors should be considered for high-quality user stories:
- The focus should always be particularly on the user.
- Creating good user stories is teamwork - communication, i.e. the evaluation of requirements, feedback, etc., plays an important role here.
- By establishing acceptance criteria, the work becomes more efficient and the result is of higher quality.
- Less is often more - a user story should be formulated briefly and precisely.
- User stories should be understandable and easily visible to everyone involved.
- User stories should be formulated simply so that everyone in the team can understand them immediately and clearly.
- User Stories alone are not always enough - they often need to be used in conjunction with Personas and Customer Journey Mapping for maximum success.
- Through targeted workshops and exercises, the competencies in terms of user stories can be optimized very effectively - the quality of the stories increases.
To evaluate a good user story, the following questions and context should be answered:
- What problem does the user story address?
- For whose problem does the story offer a solution?
- Is the problem understood and has it been sufficiently questioned?
- Is the problem merely a representation of the customer's requirement? If so, is there another solution to the problem?
SCRUM Userstory
Wie gestalten sich die Anforderungen in der Teamarbeit mit SCRUM?
User stories are an important standard for SCRUM teams when formulating requirements. Furthermore, they are a central factor in maintaining the backlog, i.e. the list of all requirements for a goal to be achieved.
On the one hand, as we explained above, user stories always remain a format for describing requirements. On the other hand, they also take on the role of a special hierarchy type within the backlog organization. These stories are then to be realized within a sprint and bring a concrete benefit to the user or customer.
User stories can also be used as a format to describe SCRUM epics or features.
FAZIT
User stories offer a simple but highly effective approach to discussing customer wishes or user needs or even customer problems in a universally understandable language, validating them and finally working on them precisely with a common understanding of the corresponding solutions.
With the help of this format, target groups can be viewed and understood in a more differentiated way. As a supplement to or in combination with personas and customer journey maps, they can show how the characteristics defined for these models, i.e. in particular the challenges and wishes of the personas as well as the touchpoints of the customer journey, (should) really interact in practice. On the basis of these considerations, the perfect measures can then be pinpointed.
Our support around the topic Customer Journey:
- Together with you, we create relevant customer profiles and derive a professional customer journey.
- We determine relevant channels and design an individual customer journey map specifically for your company.
- Based on this, we outline a positiveuser experience along all relevant touchpoints and implement it programmatically.
- In addition, we are happy to support you in the strategic alignment of lead nurturing with the defined customer journey and develop concrete content modules for the respective phases of the buying process.
For holistic and successful online marketing, we are also happy to take care of the following topics:
Oliver Parrizas will be happy to answer any questions you may have on the subject. 
+49-800-911-91-91
