5 1 Vote
Artikel-Rating

Eine der wichtigsten Merkformeln in der agilen Produktentwicklung mit Scrum lautet: Investiere in gute User Stories. Aber was macht eigentlich eine gute User Story aus und worauf solltest Du achten? Eine gute Hilfestellung für User Stories ist die sogenannte INVEST-Formel. In diesem Artikel zeige ich Dir, was sie bedeutet und worauf Du mit Deinem Scrum Team achten solltest, wenn Ihr sie verwendet.

INVEST ist ein Akronym für gute User Stories und steht für:

  • Independent

  • Negotiable

  • Valuable

  • Estimatable

  • Short (enough)

  • Testable

Wenn Du diese sechs Grundsätze beachtest, kannst Du potenziellen Ärger während eines Sprints deutlich reduzieren. Darüber hinaus ist die INVEST-Formel eine gute Orientierung, falls Dein Scrum Team eine sogenannte Definition of Ready entwerfen möchte.

Die Definition of Ready wird allerdings gar nicht im Scrum Guide erwähnt und Du solltest sie mit Vorsicht genießen, da sie schnell zu einer Art Gatekeeper mutiert. Schnell kann es passieren, dass sich Dein Scrum Team durch sie in Richtung Wasserfall-Denken bewegt.

Independent

Unabhängigkeit ist meiner Meinung nach einer der wichtigsten Aspekte für eine guten User Story. Und damit sind sowohl interne Abhängigkeiten (zu anderen User Stories) gemeint, als auch externe Abhängigkeiten zu anderen Abteilungen, Kunden etc. Je unabhängiger Deine User Story ist, desto besser kann Dein Scrum Team das Sprintziel aus eigener Kraft erreichen. Je mehr bekannte Abhängigkeiten existieren, desto eher werden die Entwickler des Teams zum Spielball von Einflüssen, die es selbst nicht auflösen können.

Interne Abhängigkeiten

Versuche daher immer, Deine User Story so zu gestalten, dass Abhängigkeiten zu anderen User Stories eliminiert werden. Wenn sich diese nicht vermeiden lassen, lohnt es sich, darüber nachzudenken, beide User Stories gleichzeitig im Sprint umzusetzen. Es ist auch denkbar, eine User Story, bei der Abhängigkeiten existieren, so “umzuschneiden”, dass nur die Teile einer User Story in den Sprint übernommen werden, die unabhängig sind.

  • Problematisch wird es immer dann, wenn zwei Teams voneinander abhängig sind. Das Scrum Framework Nexus, bei dem mehrere Teams an einem gemeinsamen Produkt Backlog arbeiten, löst diese Problematik mit Hilfe des Nexus Integration Teams und dem Nexus Sprint Backlog.

Externe Abhängigkeiten

Existieren externe Abhängigkeiten, so kann es durchaus sinnvoll sein, diese User Story nicht mit den Sprint zu übernehmen, bis diese Abhängigkeit aufgelöst ist. Hier musst Du allerdings besonders aufpassen, denn durch dieses Vorgehen kann sehr schnell Wasserfall-Denken entstehen: “Bevor wir nicht die Zusage vom Lieferanten haben, fangen wir gar nicht erst mit der Arbeit an.” Solange ein Scrum Team aber genügend andere (gleichermaßen wichtige) Aufgaben hat, die solche Abhängigkeiten nicht haben, ist es legitim, diese vorzuziehen. Hier hat jedoch natürlich der Product Owner das letzte Wort.

Externe Abhängigkeiten sind in der Regel Impediments und es ist die Aufgabe des Scrum Masters, diese aufzulösen, wenn die Entwickler diese nicht alleine auflösen können. Falls also externe Abhängigkeiten existieren, darf Dein Scrum Team nicht einfach warten, bis sich die Probleme in Luft auflösen, sondern muss aktiv daran arbeiten, diese Abhängigkeiten aufzulösen.

  • Es ist hilfreich, identifizierte Risiken und Impediments bereits beim Sprint Planning zu thematisieren und sie im besten Fall in eine Aufgabe zu transformieren. Wie das geht, erfährst Du in meinem Artikel Plannings mit der Team Alignment Map durchführen.

Negotiable

Jede User Story sollte außerdem verhandelbar sein. Das bedeutet, dass User Stories kein kleinteiliger Auftrag oder präzise Vorgabe ist, sondern den Entwicklern Spielraum bei der Umsetzung bietet. Kunden und Stakeholder geben mit einer User Story zwar vor, was sie benötigen und warum sie eine bestimmte Funktion benötigen, legen aber nicht fest, wie die Lösung genau auszusehen hat. Die meisten Scrum Teams, die ich kenne, verwenden für ihre User Stories folgende Formel:

Ich als <User> möchte <Funktion/Ziel>, sodass ich <Grund/Zweck> erreichen kann.

Dadurch wird zwar beschrieben, was jemand benötigt und warum es notwendig ist, aber es werden keine strengen Vorgaben dabei gemacht, wie das Ganze zu verwirklichen ist. Wenn ich sage: “Ich als Kunde Eures Streaming-Dienstes möchte über neue Musik meiner Lieblingsinterpreten informiert werden, damit ich keine Neuigkeiten verpasse”, ist das etwas ganz anderes als wenn ich sage: “Hier an genau dieser Stelle muss ein grüner Button für den E-Mail-Newsletter angezeigt werden, der einmal in der Woche verschickt wird.

  • User Stories sollten sich stets auf den Job to Be Done konzentrieren, den der Nutzer erledigen möchte.

  • Eine alternative zur User Story ist übrigens auch die sogenannte Job Story, die Deinem Team noch mehr Freiraum verschafft.

Valuable

User Stories müssen wertvoll sein. Damit wird sichergestellt, dass Ihr nur das entwickelt, was auch den Wert des Produktes steigert und keine Zeit für Funktionen verschwendet wird, die niemand braucht. Hier ist natürlich ganz besonders der Product Owner gefragt! Nur er oder sie entscheidet, welches diejenigen User Stories sind, die im Product Backlog ganz weit oben stehen. User Stories, die keinen Wert für den Kunden haben, kommen gar nicht erst in das Backlog hinein.

  • In der Praxis ist es ziemlich schwierig, den Wert einer User Story zu bemessen. Eine Möglichkeit, User Stories nach Wert zu priorisieren ist der sogenannte Opportunity Score.

Estimatable

Eine User Story muss schätzbar sein. Es muss jedem klar sein, wieviel Aufwand es sein wird, diese User Story zum Leben zu erwecken. Diese Aufwandsschätzung einer User Story erfolgt im Product Backlog Refinement Deines Teams. Hier diskutieren Entwickler und Product Owner mit Unterstützung des Scrum Masters darüber, wie die User Story umgesetzt werden könnte. Dadurch wird sich im Verlauf des Dialogs herauskristallisieren, was denkbare Wege sind, die Story umzusetzen und wieviel Aufwand das sein wird.

Fast alle Scrum Teams nutzen Story Points zur Schätzung ihrer User Stories Story. Auch sie wirst Du nicht im Scrum Guide finden können, da es sich hierbei ebenfalls lediglich um eine weitverbreitete Praktik handelt. Wenn Ihr möchtet, könnt Ihr in Deinem Team auch den Aufwand mit Stunden schätzen. (Empfehlen würde ich Dir das aber nicht.)

  • Viele Scrum Teams greifen bei der Aufwandsschätzung auch gerne auf das sogenannte Planning Poker zurück, um das Gespräch zu steuern und fruchtbar zu machen.

  • Es existiert allerdings auch eine sogenannte #NoEstimate-Strömung innerhalb der Scrum Community, die (gute) Gründe dafür anführt, warum man User Stories nicht schätzen sollte.

Short

Eine gute User Story sollte außerdem kurz sein. Und zwar vor allem kurz genug für einen einzigen Sprint. Der Grundgedanke von Scrum ist es ja, zum Ende in der Sprint Review ein fertiges Increment präsentieren zu können. Wenn Ihr Euch mit Dingen beschäftigz, die länger als einen Sprint dauern, führt Ihr diese Grundidee von Scrum ad absurdum.

Und ja, natürlich gibt es große Anforderungen, die länger als einen Sprint dauern werden. Aber jede noch so große Anforderung lässt sich in zwei oder mehrere Teile zerlegen, die Ihr in einem Sprint realisieren könnt. Ihr müsst allerdings darauf achten, dass jede einzelne User Story noch immer eine neue Funktion für Euren Nutzer darstellt.

Testable

Zu guter Letzt muss eine User Story testbar sein. Das heißt, Ihr wisst so exakt wie möglich, wann Ihr fertig seid. Im günstigsten Fall ist das eine Prüfung, die Euch entweder “Ja” oder “Nein” als Ergebnis ausliefert. Neben den klaren Kriterien darüber, ob Ihr eine User Story fertig gestellt habt, habt Ihr natürlich auch ein Prüfverfahren, das Euch dieses Ergebnis liefern kann. Und natürlich ist auch ein Korrekturlesen ein Test- beziehungsweise Prüfverfahren. Nur weil User Stories testbar sein sollen, hießt dass ja nicht, dass es immer super kompliziert sein muss.

  • Beim Testen von User Stories spielen natürlich sowohl die Definition of Done als auch Akzeptanzkriterien eine wichtige Rolle.