User Stories sind populär. So populär, dass manche meinen, sie seien ein fester Bestandteil von Scrum. Populär ist auch das Template, mit dem viele sie beschreiben:

Als <Nutzergruppe>
Möchte ich <Funktionalität>
Damit <Wert>

Also:

Als Amazon-Kindle-Nutzer
Möchte ich ein Buch kaufen
Damit ich etwas zum Lesen habe

Verfeinert werden User Stories durch Akzeptanzkriterien.
Stichpunkte, Skizzen, Beispiele, Tabellen. Alles dient dazu, die Gespräche über die Story bis zur Entwicklung im Gedächtnis zu behalten. Was auch möglich ist, wenn die Umsetzung spätestens 1-2 Sprints nach dem Gespräch stattfindet.

Für eine User Story mit Akzeptanzkriterien gibt es INVEST als Qualitätsmaßstab:

  • I wie Independent. Die Story ist unabhängig von anderen Stories umsetzbar. Das erleichtert Priorisierungsänderungen.
  • N wie Negotiable. Die Story ist eine Gesprächsgrundlage. Über die Details verhandelt das Team persönlich.
  • V wie Valuable. Die Story liefert einen sichtbaren Mehrwert für Nutzer. Im Gegensatz zu technischen Stories, die zum Beispiel nur die Datenbank betreffen.
  • E wie Estimable. Die Story ist schätzbar.
  • S wie Small. Die Story ist schnell umsetzbar. In Scrum zum Beispiel in einem Sprint.
  • T wie Testable. Die Story ist so konkret, dass man Testfälle ableiten kann.

Die Gefahr der Ritualisierung

Ich mag User Stories. In der Produktplanung lenken sie den Blick weg von den technischen Details. Hin zu den Nutzern und ihren Bedürfnissen. Das ist gut.

Und doch hat mich in den letzten 9 Jahren, die ich als Scrum Master und Trainer für agiles Vorgehen arbeite, ein gewisses Unbehagen beschlichen.

Ich mag es nicht, wenn zu viel Wert auf die strikte Einhaltung des Templates gelegt wird. Selbst dann, wenn es auf die Anforderung gar nicht passt. Diese Ritualisierung von Ideen, ohne die Hintergründe zu verstehen, lehne ich ab.

Und auch den INVEST-Kriterien stehe ich mittlerweile etwas kritisch gegenüber. Zeit, sich User Stories und ihre Qualitätskriterien einmal genauer anzuschauen.

Ziele liefern Wert, sind aber nicht implementierbar

Im Kurs stelle ich die Frage: „Was kann ich als Bankkunde mit einem Geldautomat machen?“ Die Antworten sind immer die gleichen:

User Goals

Was die Teilnehmer also nennen, sind Ziele. Wären wir ein Team, das einen Geldautomat entwickelt, würden wir folgende User Stories formulieren:

User Stories

Sind diese Ziele für den Nutzer wertvoll? Ja! Sie spiegeln Bedürfnisse des Bankkundens wieder.

Sind diese Ziele direkt implementierbar? Nein! Damit ein Ziel umsetzbar wird, müssen erst konkrete Schritte abgeleitet werden. Für die Story „Geld abheben“ sieht das so aus:

Steps

Auch diese Schritte kann man als User Story formulieren:
„Als Bankkunde möchte ich den Betrag eingeben, damit ich den korrekten Betrag ausgezahlt bekomme.“

Ist dieser Schritt direkt implementierbar? Ja! Sobald die Akzeptanzkriterien geklärt sind.

Aber ist dieser Schritt auch für den Nutzer wertvoll? Für sich genommen, nein.

Wert entsteht erst, wenn das Ziel erreicht ist. Der einzelne Schritt muss einen Fortschritt darstellen. Für den Bankkunden, und die Bank. Aber für sich genommen hat er keinen Wert.

Die Konsequenzen für User Stories

Soweit war mir das lange klar, ich habe auch darüber geschrieben. Die Konsequenzen für User Stories wurden mir aber erst vor Kurzem bewusst.

Gute User Stories auf Zielebene sind oft unabhängig von einander umsetzbar und liefern Wert. Sie sind Independent, Negotiable, und Valuable. Sie sind aber nicht klein, gut schätzbar und testbar (S,E,T).
Das liegt daran, dass man keine Akzeptanzkriterien für sie definieren kann, ohne über die Schritte nachzudenken und zu sprechen.

Bei guten User Stories auf Schrittebene ist es umgekehrt. Zusammen mit den Akzeptanzkriterien sind sie verhandelbar, schätzbar, klein, und testbar (N,E,S,T). Sie sind aber nicht unabhängig und liefern alleine keinen Wert (I, V). Und was ist die Konsequenz, wenn sie keinen Wert liefern? Ist das User Story Template, das den Wert für den Nutzer enthält, dann noch sinnvoll? Das zu beantworten, überlasse ich Dir.

Die folgende Tabelle gibt eine Übersicht über die User Stories und die sinnvollen INVEST-Kriterien:

Der Ausweg

Wie geht man mit den Unterschieden in den Stories um? Die Stories auf Zielebene sind eher grob. Daher kann man sich schnell eine Übersicht verschaffen. Sie ändern sich seltener. Man kann sie daher zur längerfristigen Planung benutzen:

Die Stories auf der Schrittebene sind dagegen klein und gut schätzbar. Deswegen sind sie die ideale Grundlage für die Entwicklung.

Eine Herangehensweise ist nun folgende. Das Team überlegt: „Was ist der einfachste Weg, um das Ziel zu erreichen? Und wie können wir früh Architekturrisiken reduzieren?“

Angenommen, das Team sieht das größte Risiko in der Kommunikation des Geldautomaten mit dem Bankrechner. Wenn nach der Eingabe des Betrags geprüft wird, ob noch genügend Geld auf dem Konto ist.

Wie sieht nun ein einfacher Weg aus, um zum Ziel zu kommen? Du hängst User Story, Schritt und Akzeptanzkriterien untereinander auf (als Post Its):

In späteren Sprints ergänzt das Team Schritte. Und ändert die Akzeptanzkriterien. So wird nach und nach das System aufgebaut. Im besten agilen Sinne.

Und jetzt noch ein radikaler Gedanke zum Schluss. Was, wenn genau diese Post Its das Product Backlog darstellen?