Agiles Projektmanagement
Agile Contracting mit Agile Functionpoints
Gibt es einen objektiven Bewertungsmaßstab, mit dem sich Agile Contracting hinreichend präzise realisieren lässt? Agile Function Points im Einsatz…
Man kann lange darüber streiten, aber die wohl wichtigsten KPI, oder meinetwegen zwei der wichtigsten top 5 KPI in Scrum sind die Sprint-Accuracy und die Scrum Velocity.
Ersterer ist prozessual betrachtet schon fast eine Voraussetzung für den zweiten, darauf komme ich später noch zurück.
Sprint-Accuracy gibt an, wie oft ein Team es schafft, das Sprint-Commitment zu halten, bzw. wenn man es etwas genauer haben möchte, wie dicht Teams daran kommen.
Aber hierum soll es heute nicht gehen. In diesem Artikel geht es um die Scrum Velocity.
Lade dir jetzt den kostenlosen Velocity Template im Excel Template, inklusive Anleitung herunter.
Nicht nur, dass es Scrum Teams oft sehr schwer fällt ihre Velocity konstant zu halten oder sogar zu steigern und damit Organisationen die Möglichkeit einer einigermaßen zuverlässigen Prognose für Aufwände, Dauer, Kosten (you name it) neuer Features zu geben.
In Scrum Velocity überhaupt adäquat zu messen und zwar so, dass man daraus sinnvolle Rückschlüsse ziehen kann, ist ebenso häufig ein Problem.
Dann ziehen wir uns auf unsere Burndown-Charts zurück und hoffen, dass wir damit durchkommen, erst durch den Sprint und dann durch das Projekt.
Heute früh kamen mir zwei Schüler auf dem Fahrrad entgegen und ich konnte nur einen kurzen Fetzen Ihrer Unterhaltung aufschnappen. Der eine sagte „Hoffentlich kommen die Vokabeln dran, die ich gelernt habe.“. Wir alle kennen diesen Satz, aber mit über 30 Jahren Abstand klingt er nicht mehr so dramatisch, dafür aber um so lustiger. Ziehen Sie selbst die Parallele.
Das Problem mit der Scrum Velocity fängt leider schon viel früher an
Um eine Velocity messen zu können, hat Herr Scrum uns eine Währung geschaffen: die Story Points (SP). Leider werden die Story Points in der Regel oft erst falsch verstanden und dann falsch angewendet, was die Berechnung der Velocity nicht leichter macht. Über Story Points habe ich bereits geschrieben, bei Interesse lesen Sie dort mal nach.
Zusammenfassend repräsentieren Story Points die Komplexität einer Story in Bezug auf ihren Aufwand und sind damit weder Komplexität noch Aufwand, sondern die Beziehung zwischen beiden. Sie werden daher auch oft in Fibonacci Zahlen angegeben. Da müsste es bei den meisten schon klingeln, denn Fibonacci-Folgen verwendet der geneigte Naturforscher zur Darstellung des Wachstums von Populationen.
Nehmen wir auch mal an, sie hätten auch die anderen SCRUM Kurse erfolgreich absolviert und vergeben in einem Sprint die Story Points erstens nur für Stories (und nicht für Bugs, ja alles schon gesehen) und auch nur dann, wenn die Story abgeschlossen wurde. Leider ist die Sprint-Accuracy in Teams oft nicht sehr ausgeprägt.
Wenn es so wäre und auch sonst alles gut läuft, würde im JIRA Ihr Velocity Chart ungefähr so aussehen:
Die Darstellung basiert auf einer Simulation von 6 Sprints und den dort erreichten Story Points.
Sprint
SP
Start
End
1
20
02. Jul
06. Jul
2
27
09. Jul
13. Jul
3
33
16. Jul
20. Jul
4
39
23. Jul
27. Jul
5
40
30. Jul
03. Aug
6
44
06. Aug
10. Aug
Das sieht doch sehr gut aus. Leider ist dies eine Simulation. Und zwar eine, die der Wirklichkeit leider nicht oft auch nur entfernt gerecht wird.
Hm, ein Trend lässt sich daraus ja nun wirklich nicht ablesen. Sie erinnern sich an die oben beschriebene Situation. Aber woran liegt das? Wir müssen nicht lange raten.
.
Oft werden Stories im aktuellen Sprint fast fertig. Fast fertig ist aber nicht fertig und daher gibt es auch keine Kekse im aktuellen Sprint.
Da sie aber im darauffolgenden Sprint dann schnell fertig gemacht werden, ernten wir im Folgesprint dann umso mehr Story Points.
Dann kommen noch diverse Einflussfaktoren dazu, die Bug-Rate, Kapazitätsschwankungen etc. Diese sind tatsächlich reale Einflussfaktoren auf die Velocity. Aber sie lassen sich kaum noch trennen von der Sprintgrenzen-Unschärfe.
Sollten Sie unter einem agile Contract arbeiten, dann werden sie im Sprint natürlich weiterhin nur für die erzielten Story Points bezahlt, können die Velocity des Teams aber dennoch unabhängig von dieser Logik real messen.
Sehen wir uns mal die folgende Tabelle an. Dort haben wir jede Story aufgeführt mit dem Datum, wann sie geschlossen wurde und zu welchem Sprint sie demzufolge gehört.
Story #
Sprint assigned
Sprint closed
SP
Closed
1
1
1
5
03. Jul
2
1
1
8
06. Jul
3
1
1
2
04. Jul
4
1
1
2
04. Jul
5
1
1
3
05. Jul
6
2
2
13
12. Jul
7
2
2
2
10. Jul
8
2
2
2
12. Jul
9
2
3
5
17. Jul
10
2
3
5
17. Jul
11
3
3
20
20. Jul
12
3
3
8
17. Jul
13
3
3
5
18. Jul
14
4
4
13
26. Jul
15
4
4
5
24. Jul
16
4
4
8
24. Jul
17
4
4
13
27. Jul
18
5
5
20
02. Aug
19
5
6
20
08. Aug
20
6
6
13
07. Aug
21
6
6
5
08. Aug
22
6
6
5
08. Aug
23
6
6
8
09. Aug
24
6
6
8
10. Aug
25
6
6
5
10. Aug
In dieser Tabelle sehen wir uns nicht die Summen pro Sprint an, sondern die Stories selbst. Wir sehen, in welchem Sprint sie ursprünglich waren und wann sie tatsächlich geschlossen wurden.
Darauf bilden wir nun einen Trend ab und erhalten dann diese viel aussagekräftigere Ansicht.
Das Team ist zwar ganz offenkundig nicht besonders gut in Bezug auf die Sprint-Accuracy, denn es ist ihm ein paarmal nicht ganz gelungen, die Stories, die sie sich vorgenommen haben, in diesem Sprint auch zu liefern. Dafür Schande über das Team. Aber Ihre Velocity wächst im Zeitverlauf recht kontinuierlich, so schlecht sind die Jungs und Mädels also gar nicht.
Zumindest wissen sie jetzt genau, woran sie arbeiten müssen und das Management kann sich wieder etwas beruhigter hinlegen.
Der Scrum Prozess ist ohnehin sehr sensibel und auch ziemlich diffizil. Außerdem bietet Scrum ohnehin nicht gerade üppig viele KPI’s, die irgendwie nach einer Zahl aussehen.
Wenn dann noch eines dieser KPI’s durch eine unglückliche Darstellung oder ungeeignete Messmethode die Realität verzerrt oder Dinge miteinander vermischt, die besser getrennt werden sollten, dann wird die Aufgabe ein Team voranzubringen schon sehr schwer.
Es soll hier nicht falsch verstanden werden: Die Art und Weise, wie JIRA das Velocity Chart darstellt ist nicht eigentlich falsch. Aber hier werden Sprint-Accuracy und Velocity so unglücklich vermischt, dass ein Zerrbild herauskommt und mit dem eigentlich so unglaublich wertvollen Instrument der Velocity-Betrachtung kaum noch sinnvoll gearbeitet werden kann.
In der vorgeschlagenen Methode gibt es viel mehr Messpunkte. Damit ist es egal, ob ein Team einwöchige- oder zweiwöchige Sprints hat, oder auch mal den Rhythmus wechselt.
Wir referieren hier auf das tatsächliche Close-Date, nicht auf das Sprintende.
Das bringt nicht nur mehr Messpunkte, d.h. wir müssen nicht so lange warten, bis ein Trend erkennbar wird, sondern auch mehr Unabhängigkeit vom gelebten Scrum-Prozess.
Und sogar Kanban-Teams können in Ihrer Velocity gemessen werden, die sonst immer so ganz unter dem Radar fliegen.
Unser Team aus erfahrenen und zertifizierten Agile Expert:innen entwickelt kontinuierlich praxiserprobte Strategien und Methoden, um agile Prozesse zu optimieren und mit den täglichen Herausforderungen besser umgehen zu können.
Gibt es einen objektiven Bewertungsmaßstab, mit dem sich Agile Contracting hinreichend präzise realisieren lässt? Agile Function Points im Einsatz…
Weltneuheit: Wir sind jetzt in der Lage Story Points ganz leicht über einen Algorithmus zu berechnen! Inkl. Kostenloser Story Point Calculator
Wie du die Scrum Velocity berechnen und diese so darstellen kannst, sodass sich ein echter Trend abzeichnet von dem ihr eine Prognose ableiten könnt. + kostenloses Excel Template
Für Scaled Agile Organisationen kann es frustriererend sein, wenn Projektmanagement Tools ihre Prozesse nicht unterstützen.
Daher haben wir scagile als eine App entwickelt, die aktiv agile Best-Practices fördert und mit der ein Value Flow über die gesamte Organisation hinweg etabliert wird.
