Benutzergeschichten zu schreiben ist eine grundlegende Fähigkeit für jeden Softwareingenieur, der in eine Agile-Umgebung eintritt. Während viele Teams digitale Plattformen nutzen, um Aufgaben zu verwalten, vermittelt das Verständnis der Kernmechanismen einer Benutzergeschichte ohne Abhängigkeit von Software eine stärkere Grundlage. Diese Anleitung konzentriert sich auf den manuellen Prozess, bei dem physische Gegenstände wie Post-its, Whiteboards und Indexkarten verwendet werden, um klare, umsetzbare Anforderungen zu formulieren. Ziel ist Klarheit des Denkens, nicht die Bequemlichkeit eines Bildschirms.
Wenn Sie die Software entfernen, werden Sie gezwungen, tief mit dem Inhalt zu arbeiten. Es gibt keine Autovervollständigungs-Funktionen oder vorgefertigte Vorlagen, hinter denen man sich verstecken könnte. Sie müssen den Wert, den Akteur und die Notwendigkeit explizit formulieren. Diese manuelle Disziplin stellt sicher, dass das Team den Problembereich versteht, bevor überhaupt ein einziger Codezeile geschrieben wird. Im Folgenden untersuchen wir die Struktur einer Geschichte, die Akzeptanzkriterien und die Methoden zur Verfeinerung von Ideen ohne digitale Unterstützung.
📖 Verständnis des Kernkonzepts
Eine Benutzergeschichte ist eine leichtgewichtige Beschreibung einer Funktion, erzählt aus der Perspektive der Person, die die neue Fähigkeit wünscht, meist ein Benutzer oder Kunde des Systems. Es ist kein Spezifikationsdokument. Es ist ein Platzhalter für ein Gespräch. Die physische Handlung, eine Geschichte auf eine Karte oder Papier zu schreiben, verstärkt diesen Zweck. Sie soll bewegt, bearbeitet, verworfen oder kombiniert werden können. Digitale Systeme verpflichten einen oft zu früh zu einer starren Struktur. Manuelle Methoden halten die Geschichte fließend.
Warum manuell arbeiten?
Es gibt mehrere überzeugende Gründe, Benutzergeschichten manuell zu schreiben, besonders für neue Ingenieure:
- Fokus auf Wert:Ohne Felder, die ausgefüllt werden müssen, konzentrieren Sie sich auf die eigentliche Wertversprechen.
- Kognitive Belastung:Das Schreiben von Hand verlangsamt Sie und gibt Ihnen Zeit zum Nachdenken, bevor Sie sich an Text binden.
- Zusammenarbeit:Physische Karten ermöglichen es Teams, die Arbeit physisch umzustellen und den Fluss sowie die Priorität zu visualisieren.
- Unabhängigkeit:Sie lernen das Format derart gut, dass Sie auch dann gültige Anforderungen formulieren können, wenn die Werkzeuge nicht zur Verfügung stehen.
📋 Die Struktur einer manuellen Geschichte
Jede Benutzergeschichte folgt einer bestimmten Struktur. Wenn Sie manuell schreiben, verwenden Sie auf Ihren Indexkarten oder Post-its ein einheitliches Format. Diese Konsistenz ermöglicht es dem Team, Informationen schnell während Planungssitzungen zu erfassen. Das Standardformat besteht aus drei unterschiedlichen Teilen. Verpassen Sie keinen davon.
1. Die Person (Wer)
Identifizieren Sie die spezifische Rolle oder Art des Benutzers. Vermeiden Sie generische Begriffe wie „Benutzer“. Seien Sie präzise. Ist es ein „Administrator“, ein „Gastbesucher“ oder ein „Premium-Abonnent“? Die Person bestimmt die Berechtigungen und den Kontext der Funktion.
2. Die Aktion (Was)
Beschreiben Sie die Fähigkeit oder Aktion, die der Benutzer ausführen möchte. Dies ist das Verb. Es sollte ein Ziel auf hoher Ebene sein, keine technischen Implementierungsdetails. Zum Beispiel ist „Suche nach Artikeln“ besser als „Eingabe der Abfrage in die SQL-Datenbank“. Die Aktion repräsentiert die Absicht des Benutzers.
3. Der Nutzen (Damit)
Dies ist der wichtigste Teil, der von Anfängern oft übersehen wird. Warum möchte der Benutzer dies? Welchen Wert bietet es? Wenn Sie diese Frage nicht beantworten können, ist die Geschichte möglicherweise nicht wertvoll. Der „Damit“-Teil verbindet die Funktion mit einem geschäftlichen oder nutzergerechten Ergebnis.
Beispielstruktur
Schreiben Sie dies auf einer oder zwei Zeilen. Halten Sie es knapp.
- Als[Person],
- möchte ich[Aktion],
- damit [Vorteil].
📝 Definition von Akzeptanzkriterien
Eine Geschichte ist ohne Akzeptanzkriterien nicht abgeschlossen. Dies sind die Bedingungen, die erfüllt sein müssen, damit die Geschichte als erledigt gilt. Beim manuellen Schreiben sollten diese direkt unter der Story-Karte oder auf einem separaten Blatt, das daran angeheftet ist, aufgelistet werden. Sie dienen als Testfälle für die ingenieurtechnische Arbeit.
Akzeptanzkriterien beseitigen Unklarheiten. Sie definieren die Grenzen der Funktion. Ohne sie könnten zwei Ingenieure unterschiedliche Lösungen für dieselbe Geschichte implementieren. Das manuelle Schreiben zwingt Sie dazu, Randfälle vor Beginn der Entwicklung zu bedenken.
Das Given/When/Then-Format
Verwenden Sie für präzise Kriterien die Given/When/Then-Struktur. Dies ist eine manuelle Übersetzung von Behavior Driven Development (BDD). Sie strukturiert die Logik klar.
- Gegeben: Der ursprüngliche Kontext oder Zustand.
- Wenn: Der ausgelöste Ereignis oder die durchgeführte Aktion.
- Dann: Das erwartete Ergebnis.
Beispielkriterien
- Gegeben, dass der Benutzer angemeldet ist,
- Wenn sie auf die Abmeldeschaltfläche klicken,
- Dann werden sie auf die Startseite umgeleitet.
- Wenn sie auf die Abmeldeschaltfläche klicken,
Tabelle der Kriterientypen
Verschiedene Arten von Kriterien existieren. Eine Tabelle hilft dabei, sie während des manuellen Schreibens zu kategorisieren.
| Typ | Beschreibung | Beispiel |
|---|---|---|
| Funktional | Spezifisches Verhalten des Systems | „System sendet E-Mail nach Formularabsendung“ |
| Nicht-funktional | Leistungs- oder Sicherheitsbeschränkungen | „Seite lädt in weniger als 2 Sekunden“ |
| Geschäftslogik | Regeln, die die Daten steuern | „Rabatt gilt nur für Bestellungen über 50 US-Dollar“ |
| Usability | Anforderungen an die Benutzerfreundlichkeit | „Die Schaltfläche muss ohne Scrollen sichtbar sein“ |
🌐 Überprüfung mit dem INVEST-Modell
Sobald Sie eine Geschichte manuell geschrieben haben, müssen Sie ihre Qualität überprüfen. Das INVEST-Modell ist der Standardrahmen dafür. Sie können eine Checkliste auf einem separaten Blatt Papier verwenden, um jede Geschichte zu bewerten, bevor Sie sie in das Backlog aufnehmen. Dadurch wird sichergestellt, dass die Arbeit handhabbar und wertvoll ist.
Unabhängig
Die Geschichte sollte selbstständig sein. Sie sollte nicht davon abhängen, dass eine andere Geschichte zuerst abgeschlossen ist, um wertvoll zu sein. Obwohl technische Abhängigkeiten bestehen, sollte der Wert eigenständig sein. Wenn Sie auf Story A warten müssen, um Story B zu erstellen, überlegen Sie, ob Story B aufgeteilt werden kann.
Verhandelbar
Die Geschichte ist ein Versprechen auf Diskussion, kein Vertrag. Sie ermöglicht einen Austausch zwischen Ingenieur und Stakeholder. Wenn der Text zu detailliert ist, wird er zu einer Spezifikation, keine Geschichte mehr. Lassen Sie Raum für technische Exploration.
Wertvoll
Jede Geschichte muss Wert für den Nutzer oder das Unternehmen liefern. Wenn eine Geschichte die „Weil“-Anforderung nicht effektiv erfüllt, sollte sie verworfen oder überarbeitet werden. Wert ist der primäre Treiber des Backlogs.
Abschätzbar
Das Team muss in der Lage sein, die erforderliche Anstrengung abzuschätzen. Wenn eine Geschichte zu ungenau ist, kann sie nicht abgeschätzt werden. Wenn sie zu komplex ist, muss sie aufgeteilt werden. Das manuelle Schreiben hilft, Unschärfen zu erkennen, weil Sie die Details physisch aufschreiben müssen.
Klein
Eine Geschichte sollte klein genug sein, um innerhalb einer einzigen Iteration oder Sprint abgeschlossen zu werden. Große Geschichten sind Risiken. Sie führen oft zu unvollständiger Arbeit. Wenn eine Geschichte sich wie ein Projekt anfühlt, teilen Sie sie in kleinere, sequenzielle Geschichten auf.
Prüfbar
Sie müssen sicherstellen können, dass die Geschichte abgeschlossen ist. Wenn keine Akzeptanzkriterien vorhanden sind, ist die Geschichte nicht prüfbar. Das manuelle Schreiben zwingt Sie, klar zu definieren, wie „fertig“ aussehen soll.
INVEST-Checkliste
Verwenden Sie diese Tabelle, um Ihre Geschichten während der Planung zu überprüfen.
| Buchstabe | Frage zur Abfrage | Status |
|---|---|---|
| I | Kann dies ohne die anderen entwickelt werden? | [ ] |
| N | Ist der Umfang offen für Diskussionen? | [ ] |
| V | Bietet es klaren Wert? | [ ] |
| E | Können wir die Anstrengung schätzen? | [ ] |
| S | Passt es in einen Sprint? | [ ] |
| T | Gibt es klare Bestehen/Versagen-Kriterien? | [ ] |
🔍 Der Verfeinerungsprozess
Verfeinerung, auch als Grooming bekannt, ist die Tätigkeit, Geschichten für die zukünftige Entwicklung vorzubereiten. Dazu brauchen Sie keine Software. Tatsächlich kann die physische Bewegung von Karten über einen Tisch das Verständnis für den Ablauf verbessern. Eine Verfeinerungssitzung beinhaltet das Überprüfen von Geschichten, die Klärung von Details und die Aufteilung großer Aufgaben.
Schritt 1: Die Überprüfung
Versammeln Sie das Team um einen großen Tisch. Legen Sie die Karten aus. Lesen Sie jede Geschichte laut vor. Diese einfache Maßnahme erfasst Fehler, die beim stillen Lesen unsichtbar sind. Hören Sie auf Unklarheiten im „Damit“-Abschnitt.
Schritt 2: Die Aufteilung
Wenn eine Karte zu schwer erscheint, teilen Sie sie auf. Schreiben Sie die neue, kleinere Geschichte auf eine frische Karte. Legen Sie die neue Karte über die ursprüngliche oder daneben. Stellen Sie sicher, dass die ursprüngliche Karte aktualisiert wird, um die Aufteilung widerzuspiegeln. Diese visuelle Trennung hilft bei der Steuerung des Umfangs.
Schritt 3: Die Fragen
Während der Überprüfung stellt das Team Fragen. Schreiben Sie diese Fragen auf ein separates Blatt. Beantworten Sie sie nicht sofort. Fragen deuten auf Wissenslücken hin. Sie werden zu den Aufgaben für die nächste Sitzung. Dadurch wird die Planung von der Beantwortung getrennt.
Schritt 4: Die Reihenfolge
Ordnen Sie die Karten nach Abhängigkeit oder Wert an. Verwenden Sie Schnüre oder Klebeband am Tisch, um Verbindungen darzustellen. Wenn Karte A vor Karte B erfolgen muss, zeichnen Sie eine Linie zwischen ihnen. Dieser visuelle Ablauf hilft, Engpässe zu erkennen, bevor die Entwicklung beginnt.
📈 Priorisierungstechniken
Sobald Sie eine Liste von Geschichten haben, müssen Sie entscheiden, was zuerst gebaut werden soll. Manuelle Priorisierungsmethoden sind oft effektiver als digitales Sortieren, da sie eine physische Interaktion mit der Arbeit beinhalten.
Die MoSCoW-Methode
Färben Sie Ihre Karten oder verwenden Sie verschiedene Formen, um die Priorität anzugeben. Dies ist eine klassische manuelle Methode.
- M – Muss haben:Kritisch für die Freigabe. Keine Ausnahmen.
- S – Sollten haben:Wichtig, aber nicht entscheidend. Kann bei Bedarf verschoben werden.
- C – Könnten haben:Wünschenswert, aber nicht notwendig.
- W – Werden Nicht Haben: Zustimmung, außerhalb des aktuellen Umfangs zu bleiben.
Das gewichtete kürzeste Auftragssystem (WSJF)
Für einen mathematischeren Ansatz weise Werte und Zeit Werte zu. Schreibe die Zahlen auf die Karte. Berechne das Verhältnis manuell. Dies zwingt das Team, den Wert zu quantifizieren, anstatt sich auf Bauchgefühl zu verlassen. Es ist eine wertvolle Übung für neue Ingenieure, um Geschäftsabwägungen zu verstehen.
⚠️ Häufige Fallen, die vermieden werden sollten
Auch bei einem manuellen Ansatz passieren Fehler. Neue Ingenieure geraten oft in bestimmte Fallen, wenn sie Geschichten schreiben, ohne die Anleitung durch Software-Validierung zu haben.
1. Technische Sprache
Schreibe keine Geschichten aus der Perspektive des Systems. Vermeide Wörter wie „Datenbank“, „API“ oder „Backend“. Schreibe aus der Perspektive des Nutzers. Das System ist für den Nutzer unsichtbar. Wenn du schreibst: „Das System aktualisiert den Cache“, interessiert das den Nutzer nicht. Ihn interessiert die Geschwindigkeit der Seite.
2. Fehlende Akzeptanzkriterien
Es ist leicht, den Teil „Als ein…“ zu schreiben und den Teil „Damit…“ oder die Kriterien zu vergessen. Eine Geschichte ohne Kriterien ist kein Nutzerstory, sondern ein To-Do-Liste-Eintrag. Sie erzeugt Unklarheit. Fordere immer Kriterien an, bevor die Karte als abgeschlossen gilt.
3. Zu viele Details
Eine Geschichte zu schreiben, ist nicht dasselbe wie eine Spezifikation zu schreiben. Wenn du fünf Absätze auf einer einzigen Karte schreibst, hast du wahrscheinlich zu viel spezifiziert. Halte die Karte klein. Details gehören in die Diskussion während der Nacharbeit, nicht auf die Karte selbst.
4. Ignorieren von Randfällen
Bei manueller Schreibweise konzentriert man sich oft auf den glücklichen Pfad. Du musst explizit festhalten, was passiert, wenn Dinge schief laufen. Füge Kriterien für Fehlerzustände hinzu. „Angenommen das Netzwerk ist aus, wenn der Nutzer abschickt, dann sehen sie eine Nachricht zum erneuten Versuch.“
5. Mangelnde Zusammenarbeit
Eine Geschichte isoliert zu schreiben, ist verschwendete Zeit. Geschichten sind Gesprächsanlässe. Wenn du eine Geschichte schreibst, ohne sie mit einem Kollegen zu besprechen, wird sie wahrscheinlich missverstanden. Überprüfe sie immer manuell mit einem Kollegen.
👩💻 Übergang zu digitalen Systemen später
Während dieser Leitfaden sich auf manuelle Methoden konzentriert, wechseln Teams letztendlich zu digitalen Systemen zur Verfolgung und Berichterstattung. Die Fähigkeiten, die du hier erlernst, übertragen sich direkt. Wenn du letztendlich eine digitale Plattform verwendest, wirst du bessere Geschichten schreiben, weil du die Grundstruktur verstehst. Du wirst dich nicht auf die Software verlassen, um den Wert für dich zu definieren.
Der Übergang verläuft reibungslos, wenn die Grundlage fest ist. Das digitale Werkzeug wird zu einem Archiv für die manuelle Arbeit, die du bereits durchdacht hast. Du kopierst einfach den Karteninhalt in das System. Die Logik bleibt gleich.
📝 Praktische Übung für neue Ingenieure
Um diese Konzepte zu festigen, versuche die folgende Übung. Dazu brauchst du keine Software, nur Papier und einen Stift.
- Schritt 1:Wähle eine Funktion aus, die du täglich verwendest (z. B. eine Suchleiste auf einer Webseite).
- Schritt 2:Schreibe die Nutzerstory auf einer Indexkarte im Standardformat.
- Schritt 3:Schreibe drei Akzeptanzkriterien mit Given/When/Then.
- Schritt 4:Wende die INVEST-Modell-Checkliste auf die Karte an.
- Schritt 5: Notieren Sie zwei Fragen, die Sie zur Geschichte haben, die ein Entwickler stellen würde.
- Schritt 6: Überprüfen Sie die Karte mit einem Kollegen. Fordern Sie ihn auf, den Abschnitt „Damit“ zu kritisieren.
💬 Letzte Gedanken zur manuellen Disziplin
Die Beherrschung der Kunst der Nutzerstory liegt in Präzision und Empathie. Es erfordert, dass Sie sich in die Lage des Nutzers versetzen. Es erfordert Klarheit und Kürze. Der manuelle Prozess entfernt den Lärm der Softwareoberflächen und lässt nur die Botschaft übrig. Diese Disziplin macht Sie zu einem besseren Ingenieur. Sie macht Sie zu einem besseren Kommunikator.
Wenn Sie die Werkzeuge weglassen, bleibt Ihnen die Logik. Diese Logik ist es, die Software antreibt. Durch die manuelle Übung stellen Sie sicher, dass Ihre Logik vor der Anfrage an den Computer, sie auszuführen, solide ist. Dieser Ansatz reduziert Nacharbeit und erhöht die Qualität. Es ist eine ruhige Sicherheit in Ihrer Fähigkeit, Wert zu definieren.
Denken Sie daran, das Ziel ist nicht, ein digitales Backlog zu füllen. Das Ziel ist, ein Problem für eine Person zu lösen. Halten Sie den Menschen im Prozess. Halten Sie die Geschichte einfach. Halten Sie die Kriterien klar. Diese Prinzipien werden Ihnen gut dienen, unabhängig davon, welche Werkzeuge Sie letztendlich verwenden.
📊 Zusammenfassung der wichtigsten Erkenntnisse
- Aufbau: Verwenden Sie immer: Als [Rolle] möchte ich [Funktion], damit [Zweck].
- Kriterien: Definieren Sie Gegeben/Wenn/Dann zur Klarheit.
- Validierung: Prüfen Sie vor der endgültigen Festlegung anhand von INVEST.
- Zusammenarbeit: Überprüfen Sie die Karten physisch mit dem Team.
- Fokus: Setzen Sie Nutzenwert über technische Umsetzung.