Scrum-Leitfaden | 21. User Story-Fehler

User Stories beschreiben, wie eine neue Produktfunktionalität in der Alltags- oder Geschäftssprache funktioniert. Ihre Vorbereitung erfordert jedoch viel Zeit, Mühe und Überlegung. Im heutigen Beitrag weisen wir auf die häufigsten User-Story-Fehler hin und schlagen vor, wie man damit umgeht.

Die häufigsten User Story Fehler – Inhaltsverzeichnis:

1. Einführung
2. Probleme mit 3W
3. Probleme mit 3C
4. User Story Fehler – Zusammenfassung

Einführung

User Story kann ein großartiges Werkzeug sein, um das Team zu motivieren, neue Lösungen für Probleme vorzuschlagen, die aus der Perspektive des Benutzers präsentiert werden. Wir haben in einem separaten Eintrag darüber geschrieben, was User Story ist. Und in diesem Artikel haben wir INVEST vorgestellt, eine beliebte Methode zum Schreiben guter User Stories. Heute konzentrieren wir uns auf User Story-Fehler.

Probleme mit 3W

Eine richtige User Story beantwortet die Fragen:

• Wer? (Wer ist der Zielbenutzer des Produkts?)
• Was? (Welche Fähigkeiten hat das Produkt und was kann es?)
• Wieso den? (Welchen Zweck erfüllt es?)

Die Antworten auf jede dieser Fragen können jedoch mit Problemen einhergehen. Das am wenigsten verbreitete Problem ist der Zweifel, was sich am Produkt als Reaktion auf die Bedürfnisse des Kunden ändern sollte. Daher konzentrieren wir uns auf Probleme in Bezug auf Wer? und warum?

Wer – Benutzerpersönlichkeit

Einer der häufigsten Fehler beim Erstellen von User Stories ist die Frage nicht präzise genug zu beantworten: Für wen? Mit anderen Worten: Wer ist der Nutzer, für den die geplante Änderung gedacht ist?

Häufig reicht eine allgemeine Antwort, die auf den Kunden oder Endbenutzer als Empfänger der Änderung hinweist, nicht aus. Die Lösung für dieses Problem besteht darin, sich den Empfänger als eine bestimmte Person vorzustellen. Eine Persona ist ein Modellbild des Zielkunden. Mit anderen Worten, eine Persona ist eine Darstellung der Person, die das Produkt auf eine bestimmte Weise verwenden wird.

Nachdem Sie Ihre User Story analysiert haben, stellen Sie möglicherweise fest, dass sie die Geschichten verschiedener Personen gleichzeitig erzählt. Wenn es viele Zielbenutzer gibt, ist es sinnvoll, die User Story in kleinere Fragmente aufzuteilen , um widersprüchliche, sich gegenseitig ausschließende oder einfach ineffektive Aktionen zu vermeiden.

Wieso den? – ein schlecht definiertes Ziel

Manchmal wird der letzte Abschnitt der User Story zur Quelle von Problemen. Es sollte den geschäftlichen Wert der Änderungen angeben, die während der Ausführung der User Story vorgenommen wurden. Sehen Sie sich ein Beispiel für Fehler in User Storys an, bei denen die Beschreibung zusätzlicher Funktionen das Ziel ersetzt:

Als Kunde möchte ich mit einem Klick einen Zauberstab kaufen, weil ich nächste Woche einen fliegenden Teppich kaufen möchte.

Anstatt den Grund für den Kauf des Zauberstabs zu nennen, fügt diese User Story der Einkaufsliste des potenziellen Kunden einen weiteren Punkt hinzu. Vergessen Sie daher bei der Erstellung einer User Story nicht die Gründe für Änderungen an der Funktionalität des Produkts.

Probleme mit 3C

Wir können den Prozess der Arbeit mit User Storys in drei Phasen unterteilen, die als 3Cs bezeichnet werden:

• Karte – Die Karte, auf der die User Story gespeichert ist
• Gespräch – Ein Gespräch innerhalb des Scrum-Teams über die User Story Card
• Bestätigung – Definieren von Akzeptanzkriterien, die bestätigen, dass eine Aufgabe abgeschlossen wurde

Bei all diesen können Fehler auftreten, die wir im Folgenden beschreiben.

Karte

Die Speicherkarte, auf der die User Story gespeichert ist, hat eine begrenzte Kapazität. Daher betreffen die häufigsten Probleme die Länge und den Umfang der User Story. Die User Story braucht Kohärenz und keine Umschweife, wie man so schön sagt, so präzise, ​​dass jedes Wort zählt.

Denn das Problem der User Story Card hat zwei Dimensionen. Zum einen die Formulierung: prägnant und mit einem notwendigen Mindestmaß an Aufzählung. Die zweite ist die tatsächliche Größe der User Story. Ein allgemeiner Satz kann eine große Anzahl von Aufgaben ausdrücken, die nicht in einem einzigen Sprint erledigt werden können.

Gespräch

Die Ein-Satz-Formulierung der User Story ist der Ausgangspunkt für ein Gespräch mit dem Entwicklungsteam. Daher ist es falsch, sie als Beschreibung der auszuführenden Aufgabe zu behandeln. Es verhindert die Möglichkeit von Verhandlungen und Diskussionen über verschiedene Wege seiner Umsetzung. User Story sollte nicht als Beschreibung von Anforderungen für neue Produktfunktionen behandelt werden, sondern ist vielmehr eine Einladung, ein Gespräch über spezifische technische Lösungen zu beginnen, die zur Realisierung des durch User Story definierten Geschäftswerts führen.

Bestätigung

Die Akzeptanzkriterien, die für jede User Story definiert werden müssen, haben wir ausführlich im Text beschrieben, der beschreibt, was eine User Story ist. Einer der häufigsten Fehler ist jedoch der Mangel an Unbestimmtheit der Leistungskriterien.

Eine gut geschriebene User Story enthält eine Beschreibung der Situation, in der sie implementiert wird. Sein Test besteht darin, dass der Benutzer die neue Funktionalität nutzt, die vom Entwicklungsteam erstellt wurde.

Ein nützliches Werkzeug zur Validierung der User Story ist die Entwicklung eines Akzeptanztests. Diese befindet sich normalerweise auf der anderen Seite der Karte mit der User Story.

User Story Fehler – Zusammenfassung

Bei der Erstellung und Anwendung von User Stories lohnt es sich, sich an folgende Regeln zu halten:

• Identifizieren Sie den von der Änderung betroffenen Benutzer genau
• Definieren Sie den Zweck der Erstellung neuer Produktfunktionen klar
• Halten Sie die Lautstärke so kurz wie möglich
• Behandeln Sie die User Story als Ausgangspunkt für Lösungsdiskussionen mit dem Entwicklungsteam
• Stellen Sie klare Regeln für die Annahme auf

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

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