Agile Mythen: User Stories – Pflichtformat in Scrum?!?

Das User Story Format wird insbesondere von Scrum Teams oft genutzt, um Anforderungen zu dokumentieren. Es ist eine kurze Syntax, die zwar total simpel klingt, wenn wir uns aber hinsetzen und versuchen diese Syntax mit Leben zu füllen, stellen wir schnell fest: Das ist doch gar nicht so einfach. Der ein oder andere mag auch schon über User Stories gestolpert sein, die irgendwie „gekünstelt“ klingen. Was ist also dran an diesem kleinen Satz? Wieso verwenden ihn so viele? Und müssen Scrum Teams Anforderungen im User Story Format dokumentieren? Machen sie sonst keinen „richtigen“ Scrum?

Was sagt denn der Scrum Guide?

Wenn das User Story Format Pflicht ist für Scrum Teams, dann müsste das im Scrum Guide stehen. Pragmatisch wie ich bin, habe ich also die Worte „User Story“ in die Textsuche des Scrum Guides eingegeben und keinen einzigen Treffer bekommen!

Der Scrum Guide spricht nur von Product Backlog Einträgen, nicht von User Stories. Grundlegend können wir somit festhalten, Scrum Teams müssen laut Scrum (Guide) nicht das User Story Format nutzen.

Im Umkehr Schluß kann es also auch nicht heißen, das Scrum Teams die dieses Format nicht nutzen keinen „richtigen“ Scrum machen. Bleibt die Frage, was genau sind dann Product Backlog Einträge? Gibt der Scrum Guide dazu Auskunft wie diese geschrieben werden sollen?

Product Backlog Einträge

Der Scrum Guide beschreibt Product Backlog Einträge so:

„Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. Ein Product Backlog‐Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert.“

Dem entsprechend ist nicht definiert, wie ein Product Backlog Einträge beschrieben sein soll, es ist lediglich festgehalten, dass es eine Beschreibung gibt. Laut Scrum Guide hat ein Product Backlog Eintrag vier Attribute:

Nutzt also Formate um eure Product Backlog Einträge aufzuschreiben, die für euren Kontext Sinn machen. Das könnten beispielsweise simple Texte, Aufzählungspunkte oder Hypothesen zum Erforschen sein.

Wenn das User Story Format nicht im Scrum Guide festgelegt ist, woher kommt es dann eigentlich?

Ursprung des User Story Formates

Das User Story Format kommt aus dem Extreme Programming, kurz auch als XP bezeichnet. Kent Beck hat es erfunden und bezeichnet mit Stories (er nannte sie nicht „User Stories“) wirkliche Geschichten eines Nutzers. Was meint Kent nun damit genau? Kent bezeichnet die Erzählung, wenn ein Software Nutzer ein Problem beschreibt, als Nutzergeschichte (User Story). Doch von dieser kleinen Syntax, wie wir sie heute kennen spricht er nicht.

Die User Story Syntax stammt von Rachel Davies von Connextra. Wahrscheinlich war Rachel aufgefallen, dass viele Nutzergeschichten sehr lang waren. Sie wollte eine kurze und knackige Beschreibung haben, die Menschen zu einer Konversation einlädt.
Daher kam sie auf die Idee die “Rolle”, das “Feature” und den damit erzeugten “Nutzen” typischerweise in folgender Syntax zu beschreiben:

• Als “Rolle” möchte ich “Feature” haben, damit “Nutzen”. Oder auch:
• Um “Nutzen erreichen” als “Rolle” möchte ich “Feature”.

Und warum ist User Stories schreiben jetzt so schwer?

Grundsätzlich ist User Stories schreiben nur dann schwer, wenn wir eigentlich keine User Story vorliegen haben, sondern auf Teufel komm raus versuchen eine Anforderung in dieses Format zu pressen. Wenn ihr euch also schwer tut eine User Story zu formulieren, dann fragt euch erst mal: Kenne ich einen Nutzer (User), der mir zu dieser Thematik auch eine Geschichte erzählen kann? Falls ja, geht hin und fragt ihn doch, ob er euch einen Product Backlog Item zu dieser Thematik formulieren kann. In dieser Situation kann es euch helfen, gemeinsam die User Story Syntax als Hilfestellung zu nutzen. Denn die Syntax wirft drei wichtige W-Fragen auf:

1. Wer will das haben?
2. Was will dieser Nutzer haben?
3. Warum möchte dieser Nutzer das haben?

Wenn ein Nutzer diese drei Fragen beantworten kann, hat er sich wirklich Gedanken zu dieser Anforderung gemacht und kann konkret erklären was er haben will und warum ihm das helfen würde. Unser Job als Scrum Team ist es dies zu verstehen oder Nutzern dabei zu helfen diese Fragen beantworten zu können.

Dabei können wir als Scrum Teams die, wer will das haben, Frage dafür nutzen zu validieren: Ist dieser Nutzer wirklich in unserer Zielgruppe? Oder produzieren wir potentiellen unnötige Funktionalität und erzeugen somit Verschwendung (für diese Zielgruppe)?

Oder wir können diese Gespräche mit unseren Nutzern als Input nutzen, um Personas zu erstellen. Personas helfen uns als Team, unser Wissen über unsere Nutzer zu dokumentieren und im Team bzw. Auch mit anderen Stakeholdern zu teilen.

Häufig sind wirkliche User Stories für Entwicklungsteams sehr groß und lassen sich eher als Epic einordnen: etwas, das zu groß ist, um es in einem Sprint zu erledigen. In dem Fall kann es helfen das „Was“ als Überschrift zu nehmen und die User Story weiter zu zerlegen (wir nenne das Product Backlog Einträge klein machen bzw. User Story Splitting).

Die Frage nach dem Warum, hilft uns Hintergründe, Probleme und Bedürfnisse zum Vorschein zu bringen. So können wir ein tieferes Verständnis der Situation erlangen und sicherstellen das unser Produkt wirklich einen Mehrwert für die User liefert. Product Owner nutzen das Warum auch dafür, um zu validieren ob dies auf ihre Produkt Vision einzahlt. Tut es dies nicht, muss ich mir als Product Owner überlegen: Macht es Sinn meine Vision anzupassen oder gehört diese User Story wirklich nicht zu meinem Produkt?

Fazit

Ein Product Backlog besteht nicht aus User Stories sondern aus Product Backlog Items. User Stories können eine mögliche Form von Product Backlog Items sein. Grundsätzlich heißen Einträge in einem Product Backlog, Product Backlog Einträge. Product Backlog Einträge haben 4 Attribute, Beschreibung, Reihenfolge, Schätzung, Wert.

User Stories machen nur dann Sinn, wenn es wirklich eine Geschichte ist die euch ein Nutzer so erzählen würde. Die User Story Syntax stellt zwar 3 W-Fragen, aber sie ist nur ein Einladung zu einer Konversation in der wir mehr Wissen über eine Thematik und einem User erlangen können. Der Wert entsteht dabei “vor dem Papier”.

Und Product Backlog Einträge kann bekanntlich jeder schreiben und an den Product Owner herantragen.