Zum Inhalt springen

User Stories und Iterationsplanung

User Stories erklärt — das Format Als / möchte ich / damit, INVEST, Akzeptanzkriterien — und die Iterationsplanung, oft Sprint Planning genannt, mit Velocity in East Agile Tracker.

Eine User Story ist eine kurze Beschreibung von etwas, das ein Benutzer braucht, geschrieben aus seiner Sicht. Iterationsplanung ist die Art, wie ein Team entscheidet, an welchen Stories es im nächsten Zeitfenster arbeitet. Viele Teams nennen dieses Zeitfenster Sprint und das Meeting Sprint Planning; East Agile Tracker nennt sie Iterationen und Iterationsplanung.

Die gängige Vorlage lautet:

Als [Art von Benutzer] möchte ich [eine Fähigkeit], damit [ein Nutzen].

Zum Beispiel: Als Projektmanagerin möchte ich sehen, welche Stories blockiert sind, damit ich sie vor dem Ende der Iteration freimachen kann.

Die Vorlage benennt, wer profitiert, was diese Person braucht und warum. Das „Warum“ lässt das Team einen einfacheren Weg finden, denselben Nutzen zu liefern. Eine Story ist ein Platzhalter für ein Gespräch, keine vollständige Spezifikation: Die Details werden zwischen denen, die fragen, und denen, die bauen, ausgearbeitet.

INVEST ist eine Checkliste für eine gut geformte Story:

  • Independent (unabhängig) — kann für sich allein gebaut und geliefert werden.
  • Negotiable (verhandelbar) — die Details sind offen für Diskussion.
  • Valuable (wertvoll) — liefert etwas, das einem Benutzer oder Kunden wichtig ist.
  • Estimable (schätzbar) — das Team versteht sie gut genug, um sie zu dimensionieren.
  • Small (klein) — passt bequem in eine Iteration.
  • Testable (testbar) — es gibt einen klaren Weg festzustellen, dass sie fertig ist.

Akzeptanzkriterien legen fest, was zutreffen muss, damit die Story als fertig gilt. In der Form Given / When / Then geschrieben, wird jedes Kriterium zu einem Akzeptanztest:

Given eine Story mit einem ungelösten Blocker, when ich die Spalte Blocked öffne, then ist die Story dort aufgeführt.

Die Kriterien werden vereinbart, bevor die Arbeit beginnt, damit das Team und die Person, die die Story akzeptiert, dieselbe Definition von „fertig“ teilen.

Die Iterationsplanung beantwortet eine Frage: Woran arbeiten wir in dieser Iteration? Sie braucht drei Eingaben:

  1. Einen geordneten Backlog — Stories nach Priorität sortiert, die obersten bereit (INVEST-konform, mit Akzeptanzkriterien).
  2. Schätzungen — jede infrage kommende Story in Story Points dimensioniert.
  3. Velocity — wie viele Punkte das Team pro Iteration abschließt. Siehe Was ist Velocity?.

Das Team nimmt Stories von oben aus dem Backlog, bis die Summe seine Velocity erreicht. Mehr zu übernehmen setzt darauf, dass das Team plötzlich schneller arbeitet; weniger zu übernehmen lässt Kapazität ungenutzt.

  • Stories gibt es in vier Typen: Features, Bugs, Chores und Releases. Standardmäßig nehmen nur Features Punkte an. Siehe Stories.
  • Akzeptanzkriterien gehören in die Beschreibung. Es gibt kein eigenes Feld; die Kriterien gehören in die Beschreibung, bevor die Story gestartet wird. Wenn eine Story delivered ist, akzeptiert der Product Owner sie anhand dieser Kriterien oder lehnt sie ab. Siehe die Zustandsmaschine und die Acceptance-Schleife.
  • Der Backlog ist eine einzige, streng geordnete Liste und projiziert die kommenden Iterationen aus der Velocity, drei oder vier voraus, wobei jede Gruppe markiert wird, die die Velocity überschreitet. Siehe Iterationen.
  • Die Iterationsplanung läuft weitgehend automatisch. Mit eingeschaltetem Iterationen automatisch planen (Standard) füllt sich die aktuelle Iteration bis zu Ihrer Velocity; wird eine neue Story hineingezogen, wandert die mit der niedrigsten Priorität zurück an die Spitze des Backlogs. Teams, die sich im Scrum-Stil auf einen festen Umfang festlegen, können die automatische Planung ausschalten und so viel planen, wie sie möchten; ein Zähler wird oberhalb der Velocity rot. Siehe Eine Iteration planen.
  • Eine Story erstellen öffnet einen Editor für Titel, Beschreibung, Typ, Schätzung und Owners. Siehe Eine Story erstellen.