Writes Scrum Master User Stories

User stories in Scrum

A user story can be defined relatively easily. Using a story, it describes a very specific need of a user. And that in a simply written language (ideally in that of the customer and without the use of technical terms).

It consists of a meaningful headline and is short (approx. One or two sentences long) and goal-oriented. In contrast to Use cases (= Use case) they are not as detailed and focus more on what is really important. Many employees in agile teams are now of the opinion that user stories are better suited for teamwork than the so-called Use cases.

9 criteria that make up a user story

  • A user story is not a series of actions. It describes the functionality briefly and clearly from the user's point of view (role -> goal).
  • The user story is kept short and consists of one or two sentences (role -> goal). Their content is then discussed in the team to ensure that everyone understands the same thing.
  • User stories can be seen as part of use cases.
  • User stories are preferred for planning projects.
  • User stories can be written faster and do not need as much time for analysis and writing as use cases.
  • User stories are based on verbal communication, discussion and collaboration within the team.
  • User stories have to be implemented and tested in one iteration, in contrast to use cases.
  • User stories can be written by anyone (user or customer, product owner, developer, etc.).
  • User stories contain acceptance criteria / acceptance tests. These are usually on the back when using user story cards. If there are more than 10 acceptance criteria, this is a sign that a user story is too big.

Definition: In Scrum, an iteration is called a sprint. This is a fixed time frame of one, two to four weeks in which agile teams develop a deliverable product.

User story criteria based on the INVEST principle

Independent (I) It is not dependent on any other user story

Negotiable (N) It serves as a basis for discussion and can be further developed together.

Valuable (V) It always represents a benefit for the user, customer or client.

Estimatable (E) She is valuable. So it has so many specific details that an experienced team can estimate their scope.

Small (S) It's the right size.

Testable (T) It can be tested.

Example of a user story

A short example of a more detailed user story could look like this:

`` Headline: Display of data protection declaration when logging in to the system Story: Before using personal data, every logged-in user must confirm that he is observing the data protection declaration in accordance with the legal requirements. Acceptance criteria:

  • Text information is displayed every time you log on to the system and must be confirmed.
  • If the user does not confirm the data protection declaration, he will not be logged into the system.
  • The content of the data protection declaration must be maintained by authorized persons (roles). ``

So that the project team can implement this within the planned sprint, it is necessary that the user story in the product backlog already contains some relevant points up to the first sprint planning:

  • a headline
  • the user story, i.e. description, which provides the basis for further conversation between the product owner and the (development) team. This discussion ideally ends with a clear statement for the acceptance criteria.
  • Acceptance criteria (criteria by which we can recognize that the story contains the functionality that is desired)
  • a time estimate (e.g. using story points)
  • If necessary, e.g. test cases, or what does not meet the requirements, wire frames, UI design, etc.

With regard to user stories, the so-called acceptance tests (90% of which should be automated) are also often referred to as acceptance criteria, story tests, test confirmations, satisfaction factors, etc. They are necessary to determine when a user story is to be used as a accepted applies.

Who writes user stories and when

User stories can be written by anyone on the team, not just the Product Owner (PO). As a rule, so-called User story workshops instead, which provide an introduction to the correct writing of user stories. The aim is to generate a product backlog that describes the functionality of a complete project, or at least the planned functionality for the next 3 to 6 month release cycle. The user stories are written during the entire, agile project implementation and are then stored in the product backlog, where they can be prioritized by the product owner.

Prioritize user stories The product owner first thinks about which user stories from the backlog are most important so that the application runs minimally. Must have stories It therefore identifies so-called “must have” user stories from the existing user stories, without which the system would not work. And which are the prerequisites for the other stories so that they offer the customer or user added value.

User stories will follow Must have and Should have prioritized.

Should have stories Then he takes care of the “Should Have” user stories. These are absolutely necessary so that the added value for the customer is ensured and must therefore be implemented. Thus, a user story with little importance is given higher priority if another more important user story depends on it.

Discuss stories as a team The team then discusses and analyzes the user stories together and decides which of them will be implemented in the next sprint.

Write a good user story

In order to go into a little more detail of a user story, you will learn in this section how to write a really good user story.

From the user's point of view: Write the story from the user perspective and user role (e.g. business user, consumer, administrator, editor, etc.). The typical story format is usually: "As (user role), I want (functionality) so that I can achieve (goal)."

Teamwork is required: Writing user stories is teamwork. The product owner usually writes the story details for the next sprint planning meeting together with the team after the details necessary to understand the story have been worked out in a joint discussion.

Communication is important: In order for the user stories to be properly understood by everyone involved, it is important that the team discusses them, brings in ideas and understands what the user is about. A user story is not a specification and it does not replace a dialogue with one another.

Keep it simple: User stories are simple and precise. They are written in a language that everyone understands. Complex and ambiguous terms should be avoided. You write in active, not passive, and focus on the important information.

Acceptance criteria are important: So-called acceptance criteria are important and must always be included. You determine when a story is complete and ensure that it can also be tested.

Working with paper maps: User stories should be displayed in a visible manner. This is easily possible with the help of paper cards. The team has something in hand and can often use it to think better about the story.

Always keep an eye on: The user stories should be visible to everyone. There is no point in writing it and then scorching it in the ticket system or the intranet jungle. There are story boards where you can attach the user stories in the form of paper cards. This makes it possible to present these visually to everyone, thereby stimulating or maintaining discussions or clarifying questions that have arisen in the meantime.

Who, what and when?

Who from the Scrum Team has what to do with the user stories and when? We'll clarify that briefly in this section:

Product owner Prioritizes user stories, adds or removes others, decides which user stories will be addressed in the next sprint, divides user stories and epics, accepts finished and tested user stories.

ScrumMaster Cannot change anything directly in a user story. However, he helps the PO to organize sprint planning meetings, the team to implement stories and eliminate impediments and to prepare the review meeting.

Stakeholders Cannot change anything directly in a user story. However, it defines the value, the priority and requirements.

team Takes over the time estimate for a user story during the iteration, divides user stories into tasks, develops user stories, ensures the user story quality during development, demonstrates the user story to the PO.

What if user stories are too big

There are agile projects that tend to have some very large user stories (so-called Epics) contain. Assuming that it is not possible to break them down into small user stories.

Epics in general always bring problems. Therefore, if possible, avoid these and split them up into smaller user stories.

Definition of epics An epic is a user story that is too big on its own for a single sprint. The term is often used to denote a very large user story that needs to be broken down into smaller stories. Epics only make sense if they are planned for a late future and are not part of the release planning.

User stories that get too big create problems in the long run. The team does not remember long enough the discussions and acceptance criteria for the user story that are necessary to implement the story properly. There is an accumulation of bugs and misunderstood implementation attempts. As a rule, a user story should always be so small that it can be implemented by one or more developers (including tests and acceptance) within 2 to 5 days. This also has the advantage that less documentation is required with regard to the user story details than if a user story has to be constantly re-documented and updated due to its complexity and the resulting implementation time.

Disadvantages of so-called epics

Many Scrum experts suggest that tasks that take more than 12 hours to complete should be broken down into smaller tasks.

  • Epics are difficult to estimate. They contain too many unknown factors that say anything about actual size.
  • So-called epics, which contain a time estimate, should be treated with caution. They mislead the product owner into making a wrong estimate of the project duration.
  • A team that appreciates an epic never correctly assesses such a user story, but rather organizes a guessing game. Through this estimate, it binds itself to a task that, due to an unknown magnitude, can never be completed in the estimated time.

Ways to split up large user stories (epics)

  • Split according to workflows
  • Break down according to business use cases
  • Distribution according to effort (high effort / low effort)
  • Division according to complexity
  • Split according to data structure
  • Distribution according to GUI design
  • Distribution according to performance variants
  • Split according to basic functionalities
  • Distribution according to spikes (research)

Download: The Story Splitting Cheat Sheet by Humanizing Work can be downloaded here as a PDF in English.

Note: No matter how a story is split up to make it smaller. It should not be forgotten that in the end there must still be functionality for the user / stakeholder.

Conclusion

A user story is about how a user understands a functionality and the team implements it. The best way to communicate to the team what the user wants is to talk to the team members about it.

In order to determine that everyone on the team has correctly understood the discussion on the user story, it is important to define tests. It makes no sense to rely solely on the documentation for a task because it is often not really read, nor is it complete or up-to-date. If everything has been done and implemented correctly and tested accordingly, the task is accepted as accepted.

It is very important that user stories are written down. But a documented user story is not the main part, but the associated communication with the team and the acceptance tests. User stories are often used in agile projects because they promote teamwork and at the same time show the value of a task from the customer or user perspective. In addition, you underline the verbal communication and are also understood by people without a technical background.

There is more information on agile product development on our topic page.