Zeige mehr…

Agile Vorhersagen

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:

Punkte

Aufwand

T-Shirt-Größe

1

minimal

XS

2

klein

S

3

mittel

M

5

groß

L

8

sehr groß

XL

13

riesig

XXL

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:

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

Vorteile dieses Vorgehens bei der Schätzung

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

Weiterführende Informationen

Agile-Dienstleistungsportfolio von //SEIBERT/MEDIA
Agile Softwareentwicklungs-Projekte mit //SEIBERT/MEDIA

Oder stellen Sie eine unverbindliche Anfrage

Zeige mehr…
Zeige mehr…