Scrum-Leitfaden | 19. User Stories – was sind sie?

User Story ist eine kurze Beschreibung einer neuen Produktfunktion oder ihrer Verbesserung. Es enthält keine technische Lösung, sondern geht auf Fragen zur Funktionalität ein: Wer ist der Nutzer? Was macht das Produkt? Und was ist sein Zweck? Die User Story beschreibt das Produkt in Alltags- oder Geschäftssprache, weist aber auch auf die Aufgaben des Scrum Teams hin, die die Leistung des Teams verbessern sollen.

Was sind User Stories? - Inhaltsverzeichnis:

1. Einführung
2. Benutzer Geschichte. Wessen Geschichte ist es?
3. Wie verwende ich User Stories?
4. Akzeptanzkriterium
5. Zusammenfassung

Einführung

User Story ist die gebräuchlichste Art, die vom Scrum-Team durchgeführten Aufgaben zu formulieren . Eine einzelne User Story definiert eine kleine Funktionalität des Produkts. Es beschreibt das kleinste aussagekräftige, partielle Produktziel. Aus diesem Grund sind User Stories sehr kurz.

User Stories werden während der gesamten Zeit der Arbeit am Produkt erstellt. Sie werden kontinuierlich erstellt, von dem Moment an, in dem die Entscheidung getroffen wird, mit der Arbeit zu beginnen, bis zur Verwirklichung des Produktziels.

Das Erstellen von User Storys ist die Aufgabe eines Product Owners. Basierend auf einem Gespräch mit einem Kunden, formuliert Antworten auf Fragen, die es ermöglichen, User Storys zu erstellen, und trägt sie in das Product Backlog ein. User Stories spiegeln jedoch nicht nur Kundenbedürfnisse wider.

Benutzer Geschichte. Wessen Geschichte ist es?

Das Scrum-Team erstellt eine User Story, um die Bedürfnisse des Benutzers zu definieren, und deshalb wird sie in Geschäftssprache niedergeschrieben. Mit anderen Worten, es zeigt die Vorteile auf, die seine Implementierung für den Produktnutzer bringen wird. Im Product Backlog können sich aber auch User Stories befinden, die die Bedürfnisse des Entwicklungsteams beschreiben, zum Beispiel den Workflow zwischen den Entwicklern verbessern, oder die Bedürfnisse des Product Owners beschreiben, zum Beispiel das Product Backlog organisieren. In solchen Fällen ist der Benutzer in der User Story der Entwickler und der Product Owner.

Sie können eine User Story beschreiben, indem Sie die 3W-Fragen beantworten :

• Wer?
• macht was?
• Wieso den?

Die User Story ist dann in einer Formel enthalten:

Als [Benutzertyp] möchte ich [was tun?], weil [warum? warum?].

Beispiele für User Stories über die Funktionalität eines Online-Shops, die in dieser Form geschrieben wurden, sind in der folgenden Tabelle dargestellt:

Mit dieser Formel lässt sich nicht nur eine User Story formulieren, sondern auch Fachsprache relativ einfach in Business übersetzen und umgekehrt . Infolgedessen sehen sowohl Entwickler als auch Stakeholder das Ziel und die Phasen seines Fortschritts klar. Wir werden auch das Erstellen guter User Storys mit der INVEST-Methode in einem separaten Artikel in der Scrum Guide-Serie behandeln.

Wie verwende ich User Stories?

Das Erstellen einer schematischen User Story ist nur der Anfang. Sie sind Signale und Ausgangspunkte für Diskussionen über Probleme und deren Lösungen. Die Diskussion von User Stories findet während der Sprint-Planung statt, um zu klären, welche technischen Probleme das Entwicklungsteam dem Sprint-Backlog hinzufügen wird.

Typischerweise werden User Stories im physischen Raum auf kleine, farbige Karten geschrieben , die am Arbeitsplatz angeheftet werden. Im digitalen Raum funktionieren jedoch digitale Whiteboards, die vom Scrum-Team gemeinsam genutzt werden, am besten.

Das Speichern von User Storys auf diese Weise hat mehrere Vorteile, weil:

• Betont die Autonomie jeder User Story – jede hat einen eigenen Rahmen und kann unabhängig von den anderen ausgeführt werden
• Betont die Dynamik von User Stories – die Reihenfolge ihrer Umsetzung wird vom Scrum-Team neu verhandelt und die aktuelle Umsetzungsreihenfolge ist dank der physischen Anordnung von Karten mit User Stories auf dem Board sichtbar
• Dient als Erinnerung – dank der visuellen Darstellung von User Stories hat das Scrum Team einen Wegweiser im Blick, der es bei der Erstellung von Detaillösungen an das Ziel erinnert.

Das Entwicklungsteam schätzt den erforderlichen Aufwand zur Fertigstellung einer User Story in Tagen, Arbeitsstunden oder Story Points ein.

Akzeptanzkriterium

Eine User Story muss in dem Moment, in dem sie vom Entwicklungsteam zur Entwicklung angenommen wird, bestimmte Akzeptanzkriterien erfüllen . Die Abnahmekriterien legen fest, ab wann die Arbeit an einer User Story als abgeschlossen gelten kann.

Auf diese Weise wissen sowohl der Kunde als auch die Entwickler, wie sich ihre Arbeit in Geschäftswert umwandeln lässt. Typischerweise gilt eine User Story als abgeschlossen, wenn der darin angegebene Benutzer die beschriebene Aktion ausführen kann. Sehen Sie sich anhand des obigen Beispiels diese User Story mit dem Inhalt an:

Ein Kunde kann mit einem einzigen Klick einen Zauberstab kaufen.

Es ist abgeschlossen, wenn eine funktionierende Schaltfläche „Jetzt kaufen“ auf der Seite des Online-Shops erscheint, die die Standardzahlungs- und Versandinformationen für den angemeldeten Benutzer verwendet.

Zusammenfassung

Eine User Story ist eine prägnante Beschreibung einer neuen Produktfunktionalität oder -verbesserung. Es dient als kleinstes Ziel, das in der Geschäftssprache ausgedrückt wird, dh aus der Perspektive des Geschäftswerts und des Benutzers. Es hilft, die auszuführende Aufgabe sowie die Kriterien für ihre Erledigung klar zu definieren.

Wenn Ihnen unsere Inhalte gefallen, werden Sie Teil unserer fleißigen Bienen-Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autorin: Caroline Becker

Als Projektmanagerin ist Caroline Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

Alle Beiträge anzeigen

Scrum-Leitfaden:

1. Glossar der Grundbegriffe, Rollen und Begriffe
2. Was ist Scrum?
3. Scrum-Werte
4. Wie implementieren Sie Scrum in Ihrem Unternehmen?
5. Scrum Team – was ist das und wie funktioniert es?
6. Wer ist ein Product Owner?
7. Die häufigsten Fehler des Product Owners
8. Wer ist der Scrum-Master?
9. Eigenschaften eines guten Scrum Masters
10. Die häufigsten Fehler des Scrum Masters
11. Welche Statistiken und Metriken sollte der Scrum Master verfolgen?
12. Zusammenarbeit zwischen Product Owner und Scrum Master
13. Entwicklungsteam in Scrum
14. Die häufigsten Fehler von Entwicklern
15. Scrum-Artefakte
16. Scrum skalieren
17. Sprint-Rückstand
18. Was ist das Product Backlog?
19. Was sind User Stories?
20. Erstellen Sie die beste User Story mit INVEST
21. Die häufigsten Fehler in User Storys
22. Akzeptanzkriterien für User Storys
23. Schätzung und Story Points in Scrum
24. Planungspoker
25. Team-Schätzspiel
26. Inkrement definieren
27. Scrum-Ereignisse
28. Was ist Sprint in Scrum?
29. Verpflichtungen des Scrum-Teams – Produktziel, Sprintziel und Abschlussdefinition
30. Was ist ein Burndown-Diagramm?
31. Wie erstellt und interpretiert man ein Burndown-Diagramm?
32. Vor- und Nachteile des Burndown-Charts
33. Kanban-Boards in Scrum und Scrumban
34. Velocity in Scrum - Schnelligkeit des Entwicklungsteams
35. Tägliches Scrum
36. Sprint-Planung
37. Sprint-Review
38. Was ist eine Sprint-Retrospektive?
39. Häufige Fehler während einer Sprint-Retrospektive
40. Pflege des Produkt-Backlogs