Sprint-Burndown und Story Points
Ziele von Storypoints
Im klassischen Projektmanagementansatz werden die Arbeitspakete in Zeiteinheiten geschätzt. Dies unterscheidet sich maßgeblich von der agilen Methode SCRUM. Hier erfolgt die Schätzung der User Stories in sogenannte Story Points oder Komplexitätspunkte im Rahmen des Refinement-Meetings.
Die Komplexität zu schätzen, ist gerade zu Beginn schwierig zu vermitteln. So ist rein zeitlich gesehen, das Abtippen eines 10 seitigen Dokumentes weitaus zeitaufwändiger als beispielsweise 5 Zeilen Code zu programmieren, dennoch kann die Code Programmierung komplexer sein. Dies bedeutet zugleich, dass mit zunehmender Erfahrung des Teams einerseits die zeitliche Dauer der Umsetzung sinkt, aber hingegen die Komplexität gleichbleibend ist.
Definition
Die Story Points sind nach der Fibonacci-Reihe aufgebaut:
1, 2, 3, 5, 8, 13, 20, 40, 100
Leicht erkennbar ist, dass je größer die Zahl desto größer die Abstände zwischen den Zahlen.
Velocity
Die Geschwindigkeit (Velocity) eines Teams während des Sprints ergibt sich aus der Summe aller erledigten User Stories und der darin enthaltenen Story Points. Eine gleichbleibende Velocity und eine damit bessere Planbarkeit der für einen Sprint möglichen User Stories ergibt sich meist erst nach 5-7 Sprintzyklen.
Im Folgenden ein Burndown-Beispiel:
Burndown Chart
Erläuterung
Wie in der Grafik erkennbar ist, wurden zu Beginn ca. 115 Storypoints geplant. Die graue Linie gibt den optimalen Pfad an. Die Steigung dieser fallenden Linie ist schlichtweg die Division aus Storypoints durch die Anzahl der Arbeitstage. Grau schattierte Balken spiegeln die Wochenenden wider. Die rote Linie zeigt die tatsächliche Reduktion der Story Points.
In der ersten Woche ist erkennbar, dass das Team mehr Story Points abgearbeitet hat als erforderlich wären. In der zweiten Woche ist dies genau umgekehrt. Sprünge nach oben zeigen, dass entweder neue Stories in den Sprint aufgenommen wurden oder eine als erledigte User Story wieder geöffnet wurde.
Ziel ist es, dass am Ende des Sprints alle User Stories erledigt sind und somit die rote Linie die Nulllinie erreicht.
Tipps
Hilfreich bei der Schätzung der Komplexität ist sich zu Beginn auf eine Benchmark User Story zu einigen. Anhand dieser User Story wird gemessen, ob die darauffolgenden mehr oder weniger komplex sind und entsprechend geschätzt.
Jedes Team legt selbst fest, in welchen Bereichen der Benchmark festgelegt wird. Meine Erfahrung hat gezeigt, dass hier ein Wert zwischen 5 und 8 ratsam ist. User Stories, die mit 20 oder mehr Story Points geschätzt sind, sollten ggf. unterteilt werden, um Schätzungenauigkeiten zu vermeiden und um sicherstellen zu können, dass die User Story auch in einem Sprint realisierbar ist.