Schätzgrößen: Story-Points

In Scrum-Projekten wird häufig mit der Größe "Story Points" gearbeitet. Mit den Story Points wird die Komplexität von Stories beschätzt. Nicht gleichzusetzen ist das mit einer Aufwandsschätzung.
Es handelt sich um einen Verhältniswert, die absolute Zahl ist unwichtig. Die Aussage: "Diese Story wurde mit 5 Story Points beschätzt" kann also von Projekt zu Projekt und von Team zu Team ganz unterschiedliche Implikationen haben, was den Kostenrahmen angeht.
Was aber in jedem Fall gegeben sein soll, ist ein passendes Verhältnis der Beschätzung innerhalb eines Backlogs. Hat also in einem Backlog eine Story zwei Story Points zugewiesen bekommen, sollte dies das Doppelte von einer Story sein, die mit einem Story Point beschätzt wurde.

Eine gängige Zuordnung sieht in etwa wie folgt aus:

Agile Schätzverfahren

Die Aktivität "Schätzung" ist die Erstellung einer Verknüpfung von Stories zu Komplexität. Es gibt verschiedene Vorgehensweisen, mit denen solche eine Verknüpfung hergestellt werden kann.

Planning Poker

Planning Poker ist das wahrscheinlich bekannteste Schätz-Spiel, das sehr häufig von agilen Softwareentwicklungs-Teams angewendet wird.

Neben allen Teammitgliedern und dem Product Owner werden für das Planning Poker benötigt: Ein Stapel der zu beschätzenden Backlog Items (z.B. als User Stories auf Story Cards) sowie für alle Personen, die an der Schätzung teilnehmen sollen, ein Stapel Planning Poker-Karten.

Häufig verwendet werden Planning-Poker-Karten mit den folgenden Optionen verwendet:
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Kaffeetasse. Das Fragezeichen kann gezeigt werden, wenn sich jemand unsicher ist, was eine realistische Beschätzung ist. Die Kaffeetasse steht dafür, dass derjenige eine Pause benötigt.

Der Product Owner nimmt die erste Story Card und liest diese vor. Er beschreibt sie dann noch kurz und mögliche Fragen werden besprochen. Alle haben nun kurz Zeit, sich Gedanken über ihre Einschätzung zu machen. Auf ein Signal hin zeigen alle die von ihnen gewählte Karte. 

Nun wird ersichtlich, ob es eine sehr ähnliche oder sehr ungleiche Einschätzung der Komplexität der Stories gibt. Sofern eine sehr ähnliche Einschätzung vorliegt, einigen sich die Teammitglieder meist schnell auf den Wert, den der Großteil als realistisch ansieht. Sind die Einschätzungen weiterhin eher ungleich, gilt folgende Regel:

Eine der Personen, die die höchste Einschätzung gemacht hat und eine der Personen, die die niedrigste Einschätzung gemacht hat, stellen dar, warum sie die Komplexität so hoch bzw. gering sehen. Dadurch werden mögliche Knackpunkte ("Wir müssen noch bedenken, dass...") oder auch Erleichterungen ("Wir haben doch schon...") aufgedeckt, die allen eine bessere Einschätzung ermöglichen. Dann wird eine erneute Schätzrunde vorgenommen.

Dieses Spiel wird so lange durchgeführt, bis alle Stories mit einer Schätzung versehen sind.

Estimation Game

Beginn des Estimation Games

Alle zu beschätzenden User Stories liegen als Stapel von einzelnen Story Cards vor. Jemand aus dem Team nimmt sich die oberste Story und liest sie laut vor. Gibt es Verständnisschwierigkeiten, kann er Rückfragen zu dieser Story stellen. Dann legt er sie auf den Tisch.
Das nächste Teammitglied zieht eine weitere Story Card aus dem Stapel. Es liest sie laut vor und kann ggf. Rückfragen stellen. Nun muss sich das Teammitglied überlegen, wie komplex die Story im Vergleich zur bereits auf dem Tisch liegenden Story ist:

• Schätzt es die Story genauso komplex wie die erste ein, legt es diese daneben.
• Schätzt es die Story weniger komplex als die bereits liegende ein, legt es die Karte unterhalb der bereits liegenden Story.
• Schätzt es die Story komplexer als die bereits liegende Story ein, legt es die Story Card über die liegende Karte.

Neue Optionen ab der dritten Karte

Jedes Teammitglied hat, sobald die ersten zwei Karten eingeordnet wurden, die Wahl zwischen drei Optionen:

1. Es nimmt eine neue Anforderung und ordnet diese ein (wie oben beschrieben).
2. Es nimmt eine Verschiebung in der Reihenfolge der bisher eingeordneten Items vor. Dies erfolgt immer mit Begründung.
3. Es setzt eine Runde aus.

Zuordnung zu StoryPoints

Wenn alle Backlog Items in eine Reihenfolge gebracht wurden, werden die Karten eines Planning Poker-Sets zugeteilt und Cluster gebildet.

Das Estimation Game ist dann zu Ende, wenn die Timebox abgelaufen ist oder wenn das Team mit der Zuordnung der Backlog Items zu den StoryPoints zufrieden ist.

Magic Estimation

Ein spezielles Verfahren, bei dem die direkte Kommunikation zwischen den Teammitgliedern bewusst ausgeschaltet wird. Es wurde entwickelt für die Beschätzung von großen Mengen an Backlog Items in kurzer Zeit.

Jedes Teammitglied nimmt eine individuelle Schätzung vor und platziert die Backlog Items bei den Story Points.
Sobald es selbst alle Stories ausgelegt hat, überprüft das Teammitglied die Schätzungen der anderen und nimmt, falls erforderlich, Korrekturen vor.

Der Product Owner markiert die sogenannten "Fall-Outs", die eine Nachbereitung benötigen, da sie entweder zu groß sind oder keine klare Zuordnung finden. Das ist für den Product Owner ersichtlich, wenn sie immer wieder hin und her geschoben werden.
Diese Fall-Outs werden dann gesondert durchgesprochen und eine Einigung über die Beschätzung angestrebt (eine Option ist es, hierfür dann wieder ein Planning Poker einzusetzen).

Rahmenbedingungen für die Schätzung

• Alle zu beschätzenden Items liegen vor (auf handschriftlichen StoryCards oder z.B. als Jira-Ausdrucke mit Hilfe des AgileCards-Plugins)
• Das gesamte Team inklusive Product Owner ist anwesend.
• Die Regeln der Schätzung sind allen bekannt und hängen möglichst noch einmal im Raum aus.

Vorteile dieses Vorgehens bei der Schätzung

• Schnelle Schätzungen, die trotzdem eine hohe Treffgenauigkeit aufweisen.
• Es schätzt immer das Team, dass sich später um die Umsetzung kümmert. Dadurch werden keine Schätzungen "vorgesetzt", die für das Umsetzungsteam unrealistisch sind.
• Schätzungen bereiten keine Bauchschmerzen mehr, sondern werden zu etwas "spaßigem".
• Berücksichtigung der Komplexität der Umsetzung.
• inspect&adapt, das Team wird immer besser in den Schätzungen.

Teamvelocity

Eng mit den Schätzungen zusammen hängt die Messung der Geschwindigkeit, mit der ein Team Product Backlog-Items umsetzen kann. Diese wird als "Teamvelocity" bezeichnet und in Story Points angegeben.
In Scrum-Projekten wird die Größe zum Ende eines jeden Sprints erhoben. Einbezogen werden nur die Stories, die vom Product Owner im Review-Meeting oder im Sprint-Verlauf als abgeschlossen gewertet werden. Nicht entsprechend der "Definition of Done" abgeschlossene Arbeiten werden mit 0 Story Points bewertet. Bereits nach wenigen Sprints bildet sich eine Vorstellung heraus, wie viele Story-Points das Team pro Sprint realisieren kann.

Diese Angabe hilft dem Team wiederum, im Rahmen der Sprint-Planung eine realistische Einschätzung dessen abzugeben, was es innerhalb eines Sprints umsetzen kann.

Interessante Links

• Tyner Blain: Agile Estimation, Prediction, and Commitment
• Scrum Methodology: Scrum Effort Estimation and Story Points
• Agile Advocate: Team Estimation Game
• David Campey: Magic Estimation
• Christoph Bedürftig: Schätzt du noch oder baust du schon?