Eine User Story ist ein Versprechen, miteinander zu reden

Teil sieben der Werkzeugkiste des Product Owners. Die Story Map des Ferientools ist voller Karten. Jetzt schauen wir uns eine einzelne an.

Eine User Story beschreibt eine Funktionalität aus der Sicht eines bestimmten Nutzers. Meistens wird sie in normaler Sprache nach einer festen Vorlage geschrieben und ist bewusst kurz:

Als (Rolle oder Persona) will ich (Ziel oder Funktion), damit (der Nutzen).

Die Vorlage ist das Unwichtigste daran. Sie hilft, den Nutzer im Blick zu behalten, aber entscheidend ist, ob das Team vier Fragen beantworten kann: Warum bauen wir das? Für wen? Welches Problem löst es? Und wie bauen wir es technisch?

Eine User Story ist keine feste, schriftliche Spezifikation. Sie ist ein Versprechen, miteinander zu reden. Bevor sie gebaut wird, muss sie im Gespräch mit allen Beteiligten verfeinert und konkret gemacht werden.

Card, Conversation, Confirmation

Ron Jeffries hat die drei Teile einer Story als die 3 C beschrieben. Dahinter steht die Einsicht, dass sich keine Anforderung frei von Missverständnissen aufschreiben lässt.

• Card: Die Idee, kurz auf einer Karte. Gerade genug, um sie zu erkennen und ihr eine erste Priorität zu geben. Die Karte ist ein Platzhalter auf dem Board.
• Conversation: Die Story wird persönlich mit den Leuten besprochen, die sie bauen und testen, und am besten auch mit dem Kunden, bis alle sie gleich verstehen. Die Karte wird dabei schärfer.
• Confirmation: Sobald alle einig sind, kommen Akzeptanzkriterien dazu. Sie legen fest, wann die Story abgenommen wird, und fixieren ihren Umfang. Jetzt lässt sich die Story auch bewerten, zum Beispiel nach Wert, Aufwand und Risiko.

Akzeptanzkriterien geben Entwicklern und Testern ein konkretes Bild davon, was erwartet wird. Sie erlauben dem Product Owner und den Stakeholdern ausserdem zu prüfen, ob das Gebaute das ist, was sie wollten.

Die drei Amigos

Die drei Amigos (der Name stammt von George Dinwiddie) holen das Gespräch aus dem Kopf des Product Owners und bringen drei Perspektiven in einen Raum:

• Fachseite: Welches Problem oder Bedürfnis lösen wir?
• Entwicklung: Welche Lösung bauen wir?
• Test: Welche Qualitätsrisiken senken wir?

Bei Bedarf kommen weitere Perspektiven dazu, etwa UX. Die drei besprechen die Story, bis sie sie gleich verstehen. Dann ist sie bereit für die Entwicklung.

So führe ich es durch:

1. Der Product Owner schreibt die Story aus den Bedürfnissen der Nutzer und stellt sie dem Team vor.
2. Das Team bestimmt, wer bei dieser Story die Amigos sind. Sie brauchen die Fähigkeiten, um sie zu bauen, alle drei Perspektiven müssen vertreten sein, und es kommen nur Leute, die tatsächlich daran arbeiten.
3. Der Product Owner organisiert und moderiert das Meeting. Es ist auf 30 bis 60 Minuten begrenzt, und alle bereiten sich vor.
4. Die Story verlässt das Meeting mit Akzeptanzkriterien.
5. Weil alle dasselbe Verständnis haben, können sie jetzt parallel arbeiten: Der Product Owner aktualisiert die Produktdokumentation, die Testerin automatisiert die Testfälle, und der Entwickler schreibt den Code.
6. Sobald der Code fertig ist, prüft die Testerin ihn und gibt Feedback. Bugs werden im selben Sprint behoben, dann nimmt der Product Owner die Story ab, und sie wird im Sprint Review den Stakeholdern gezeigt.

Das Ergebnis sind weniger Rückfragen mitten im Sprint, schnellere Entwicklung, Tests innerhalb des Sprints statt danach und weniger Verschwendung.

Behaviour-Driven Development, das ich bei Quickline eingeführt habe, ist im Kern genau dieses Gespräch mit einem festen Ausgabeformat: Die Akzeptanzkriterien werden als Given, When, Then geschrieben und werden zu den automatisierten Tests.

Eine Story für das Ferientool

Als Mitarbeiter will ich sehen, wie viele Ferientage ich noch habe, bevor ich eine Woche beantrage, damit ich keine Tage beantrage, die ich nicht habe.

Akzeptanzkriterien:

• Das Restguthaben steht auf der Antragsseite über der Datumsauswahl.
• Das Guthaben berücksichtigt bewilligte und offene Anträge.
• Wenn die gewählten Tage das Guthaben übersteigen, sehe ich, wie viele Tage fehlen, und kann nicht absenden.

Dasselbe als Szenario:

# language: de
Angenommen ich habe noch 5 Tage und 2 Tage sind offen
Wenn ich 4 Arbeitstage auswähle
Dann sehe ich «1 Tag mehr, als du noch hast»
Und der Absenden-Knopf ist deaktiviert

Das zweite Kriterium kam von der Testerin im Amigos-Meeting. Niemand sonst hatte an offene Anträge gedacht. Genau dafür ist das Meeting da.

INVEST

Das Akronym von Bill Wake ist ein Qualitätscheck, der für jeden Backlog-Eintrag funktioniert, nicht nur für Stories.

• Independent (unabhängig): Er lässt sich ohne andere Einträge derselben Ebene bauen und deshalb frei priorisieren. Völlige Unabhängigkeit ist in der Praxis selten, aber prüf, ob ein anderer Schnitt die Abhängigkeit auflösen würde.
• Negotiable (verhandelbar): Er ist kein Vertrag. Er lässt Raum, über die Lösung und den technischen Weg zu sprechen. Halte das Gespräch beim Bedürfnis des Nutzers, nicht bei einer bestimmten Lösung.
• Valuable (wertvoll): Er liefert dem Nutzer einen Wert und bringt das Produkt näher an die Vision. Der Wert wird mit den Einträgen heruntergebrochen, also schneide Stories so, dass jede dem Nutzer noch etwas bringt.
• Estimable (schätzbar): Das Team versteht ihn gut genug, um Aufwand und Komplexität zu schätzen. Regelmässige Refinements machen das viel einfacher.
• Small (klein): Er passt in einen Sprint. Das entscheidet das Team, meistens mit Planning Poker.
• Testable (testbar): Man kann Testfälle daraus ableiten, meistens über Akzeptanzkriterien. Das gilt auch für nicht-funktionale Anforderungen.

Wer Stories schreibt

Alle: das Team, die Stakeholder, der Product Owner. Verantwortlich bleibt der Product Owner. Kriterien, die für jede Story gelten, gehören nicht auf jede Karte. Sie kommen in die Definition of Done, das Thema des letzten Texts dieser Serie.

Als Nächstes

Die meisten Stories sind zu gross, wenn sie zum ersten Mal geschrieben werden. Nächstes Mal: wie man sie so schneidet, dass jedes Stück noch etwas liefert.