Wie man gute Benutzerstories in Scrum schreibt

Etwa 70 % der Technologieprojekte scheitern. Jahrzehntelang wurde allgemein angenommen, dass Projekte scheitern, weil sie keine Best Practices befolgen oder weil das Team über keine richtigen Fähigkeiten verfügt. Doch die Umsetzung von Best Practices, Fähigkeiten und Kompetenzen hat sich in den letzten Jahrzehnten verbessert – warum scheitern Projekte dennoch?

Angesichts der Tatsache, dass 70 % der Softwareprojekte aufgrund schlechter Anforderungen scheitern. Die geschätzten Nacharbeiten, die mit diesen Fehlschlägen verbunden sind, überschreiten jährlich 45 Milliarden Dollar.

Die Frage lautet – warum geschieht das? Die Antwort ist zweigeteilt. Erstens verlieren geschäftliche Anforderungen oft die Kundenorientierung; zweitens fehlt es an einem umfassenden Referenzrahmen, der Anforderungsanalysten ermöglicht, Anforderungen von Kundenbedürfnissen und Strategie bis hin zur umgesetzten Lösung zu verfolgen und zu steuern.

Um gute Anforderungen oder Benutzerstories zu schreiben, befolgen Sie diese Schritte:

1. Definieren Sie so viele Personen wie möglich, um die Nutzer des Systems darzustellen.Dies hilft Ihnen, sich auf den Kunden zu konzentrieren und Anforderungen auf Basis der Kundenbedürfnisse zu steuern und zu verfolgen. Eingeführt von Alan Cooper, definieren Personen archetypische Nutzer des Systems – Beispiele für die Art von Personen, die mit ihm interagieren. Nutzer müssen nicht unbedingt Personen darstellen. Ein Nutzer kann auch eine Organisation repräsentieren.
2. Stellen Sie sicher, dass Ihre Benutzerstories die „3Cs“ befolgen:

• Karte — Sollte auf einer Karte oder einem Post-it notiert werden
• Gespräch — Holen Sie detaillierte Informationen vom Product Owner
• Bestätigung — Stellen Sie sicher, dass sie korrekt umgesetzt wird. Sie muss die Kriterien für die Benutzerakzeptanz erfüllen.

3. Teilen Sie Benutzerstories auf, damit sie angemessen groß sind und in einen Sprint passen. Einige Möglichkeiten, Geschichten zu teilen, sind:

• Aufteilen nach Arbeitsablauf-Schritten
• Aufteilen nach Eingabe-/Ausgabekanälen
• Aufteilen nach Nutzereinstellungen
• Aufteilen nach Person/ Rolle
• Aufteilen nach Datenumfang

4. Stellen Sie sicher, dass jede Benutzerstory die INVEST-Mnemonik befolgt:

Das agileINVEST-Mnemonik, entwickelt von Bill Wake, dient als Leitfaden, um hochwertige Product-Backlog-Elemente (PBIs) sicherzustellen, die typischerweise in Benutzerstory-Form verfasst werden.

• Unabhängig: Geschichten sollten so unabhängig wie möglich sein.
• Verhandelbar: Eine Geschichte ist kein Vertrag. Eine Geschichte ist eine Einladung zu einem Gespräch. Die Geschichte fasst das Wesentliche dessen zusammen, was gewünscht wird.
• Wertvoll: Wenn eine Geschichte keinen offensichtlichen Wert hat, sollte sie nicht durchgeführt werden.
• Schätzbare: Eine Geschichte muss schätzbar oder abgemessen sein, damit sie angemessen priorisiert werden kann.
• Klein: Für eine zweiwöchige Iteration sollten Benutzerstories im Durchschnitt 3–4 Arbeitstage umfassen – insgesamt! Dazu gehören alle Arbeiten, die erforderlich sind, um die Geschichte in den Zustand „Erledigt“ zu bringen.Je kleiner die Benutzerstory, desto höher die Schätzungsgenauigkeit!
• Prüfbar: Jede Geschichte muss prüfbar sein, um als „Erledigt“ gelten zu können.

• SMART-Ziele und INVEST für Benutzerstories schreiben
• Thema vs. Epic vs. Benutzerstory vs. Aufgabe
• Was bedeutet DEEP im Product Backlog?
• Wie schreibt man eine Produktvision für ein Scrum-Projekt?
• Wie verwendet man ein Scrum-Board für agile Entwicklung?
• Wer erstellt Produkt-Backlog-Elemente oder Benutzerstories in Scrum?
• Was ist agile Schätzung?
• Was ist ein Story Point in agilen Projekten? Wie schätzt man Benutzerstories?
• Aufteilung von Benutzerstories – Vertikaler Slice vs. Horizontaler Slice