von David Theil
Menschen sind schlecht, wenn es um absolute Schätzungen geht. Wie viele Kilogramm hat eine Ananas? Wie viele Kilometer sind es zwischen Berlin und Wien? Wie lange dauert es ein Haus zu bauen? Wie viele Milliarden Dollar Gewinn macht Apple?
Wenn es aber um relative Schätzungen geht sind wir Menschen schon besser. Was ist schwerer dieser Apfel oder diese Ananas? Und wie viele Äpfel wiegen genauso viel wie diese Ananas? Zwei? Drei?
Der unterschied in beiden Schätzungen ist die Komplexität. Von einer gesichtslosen Einheit wie Kilometer zu einer realen Entfernung zu schätzen ist schwieriger als einen Vergleich zwischen zwei realen greifbaren Dingen zu machen.
Es liegen 9.105 Kilometer Luftlinie zwischen Berlin und San Francisco, zwischen Wien und Berlin liegen 325 Kilometer Luftlinie. Das sagt uns nichts. Aber die Entfernung zwischen Berlin und San Francisco ist 28-mal die Entfernung zwischen Berlin und Wien ist schon greifbarer. Deswegen rechnen Zeitungen auch gerne Zahlen und Fakten in Badewannen und Fußballfelder um.
Wir haben als Menschen mehr Bezug zu realen Dingen und beim agilen Schätzen geht es genau um diesen Fakt.
Schwierig wird es nämlich dann, wenn wir gefragt werden wie lange man von Wien nach Berlin braucht. Da werden einige sagen 7,5 Stunden mit dem Auto, andere werden sagen eine Stunde und 15 Minuten mit dem Flugzeug und ein Eurofighter-Pilot, der gerade über Berlin in der Luft ist und es eilig hat würde mit seinen 2000 km/h Top-Speed gerade einmal ca. 10 Minuten brauchen.
Und das ist auch schon die zweite wichtige Erkenntnis, die man ins agile Schätzen mit einfließen lässt. Es kommt darauf an wen man fragt und welche Geschwindigkeit man hat, wenn es um Schätzwerte geht. Deswegen trennen wir in der agilen Welt den Schätzwert von der Umsetzungsgeschwindigkeit und schätzen in Story-Points.
Story-Points sind komplexitätsbezogene Aufwandsschätzungen mit einer für jedes Projekt individuellen Einheit namens Story-Points.
Vorgehensweise bei der agilen Schätzung
1. Initiale Füllung des Backlogs
Um zu einer initialen Schätzung zu kommen muss zunächst das Backlog grob gefüllt sein. Der Product-Owner leitet dazu von der Vision, die er auch im Team etabliert hat, eine Reihe von User-Stories/Product-Backlog-Items (=PBI) ab. Wenn das Backlog eine gute initiale Füllung aufweist, kann mit der initialen Schätzung begonnen werden.
2. Herunterbrechen auf greifbare Einheiten
Der Product-Owner und das Team beginnen nun gemeinsam mit der initialen Schätzung des Product-Backlogs. Dazu stellt der Product-Owner die einzelnen User-Stories/Product-Backlog-Items (=PBI) dem Team vor und diskutiert deren Hintergründe.
Nun gibt es die Möglichkeiten, dass
- die PBIs zu von der Granularität grob sind (Beispiel: „Wir brauchen eine App die Userdaten verwaltet“, „Als User brauche ich eine App um meine Daten zu verwalten“)
- die PBIs unvollständig sind
- die PBIs von der Granularität durchmischt sind.
In der Praxis begegnen wir allen Fällen, meist jedoch tritt eine Kombination aus verschieden granularen PBIs auf die auch nicht vollständig sind. Das wiederspricht übrigens in keiner Weise dem agilen Ansatz, sondern ist nur umso mehr eine Bestätigung, dass agile Vorgehensweisen für derart komplexe Aufgabenstellungen gemacht sind. Denn agile Methoden können mit diesen unvollständigen Anforderungen umgehen und im Laufe der Zeit können die Lücken in den Anforderungen geschlossen werden. Sind die Anforderungen zu Grob, so müssen sie zerteil und auf die Grobanforderungen heruntergebrochen werden, sodass man auf eine greifbare Aufgabenstellung kommt.
In der Einleitung wurden Fragen diskutiert wie „Wie viele Milliarden Dollar Gewinn macht Apple?“ oder „Wie viele Kilometer sind es von Berlin nach San Francisco?“. Das sind Aufgabenstellung die nicht Greifbar sind. Wenn ich aber Frage wieviel kostet eine Maß-Bier am Oktoberfest so ist das sehr viel Greifbarer und die Schätzungen sind einfacher.
Im klassischen Projektmanagement wird zu Beginn des Projekts eine Work-Breakdown-Structure gemacht. Soweit müssen wir im agilen Schätzen nicht gehen. Das können und wollen wir gar nicht weil wir eine Trennung zwischen Was und Wie haben. Außerdem haben wir eventuell nicht alle Anforderungen und das Backlog ist eventuell auch nicht vollständig.
3. Initiale Schätzung des Backlogs in Story-Points
Wenn die Arbeitspakete im Backlog so vorliegen, dass mindestens ein PBI granular genug für eine einfache Schätzung ist, so kann dieses PBI als Referenz für die Schätzung dienen. Die Story-Points-Schätzung wird üblicherweise nur vom Development-Team durchgeführt, der Product-Owner nimmt zwar beim Schätz-Meeting teil, beratet das Team aber nur inhaltlich und beantwortet inhaltliche Fragen zu den einzelnen User-Stories und PBIs schätzt jedoch nicht aktiv mit. In diesem Fall wird das PBI dessen Umfang gut überschaubar ist verwendet und mit allen andere PBIs verglichen. Wenn es gut ausgewählt wurde, so können diesem PBI dann beispielsweise 8 Story-Points geben werden. Alle anderen müssen nun vergleichen werden.
- Hat das PBI mehr, oder weniger Story-Points?
Um das PBI einzuordnen kann die Fibonacci-Folge verwenden werden.
- 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, …
Menschen können größere Schätzungen schlechter einschätzen, die Fibonacci-Folge hat den Vorteil, dass die Abweichung zur nächsten Zahl immer um ca. 60% höher ist und somit dem höheren Schätzrisiko Rechnung getragen ist. Das hat den Effekt, dass eine Kategorisierung besser funktioniert und die Schätzungen einen sinnvollen Fit erreichen.
Das Development-Team schätzt somit bei der initialen Schätzung jedes einzelne PBI im Backlog indem es jedes PBI mit dem Referenz-PBI vergleicht und den Estimation-Poker spielt.
Was sind nun Story-Points?
Wie in der Einleitung bereits geschildert sind Story-Points komplexitätsbezogene Aufwandsschätzungen. Sie sagen etwas über den Aufwand und den Komplexitätsgrad einer Aufgabe aus, nichts aber über den zeitlichen Aufwand, der in ein Product-Backlog-Item gesteckt werden muss um dies umzusetzen. Das würde an dieser Stelle auch noch keinen Sinn machen. Der zeitliche Aufwand steht erst dann fest, wenn ein PBI von einem Team/Teammitglied umgesetzt wird. Story-Points dienen also vorwiegend der Grobplanung und der Kosten-Nutzen Rechnung.
4. Initiale Schätzung des Backlogs in Value-Points
Bei der Schätzung der Value-Points wird ähnlich vorgegangen wie bei der Schätzung für Story-Points. Das Backlog muss wie bei der Story-Point-Schätzung in einer vernünftigen Granularität vorliegen. Bei der Value-Point Schätzung, liegt aber der Fokus auf dem Business-Value der einzelnen PBIs/User-Stories.
Der Business-Value, oder Geschäftswert, ist bei agilen Methoden sehr wichtig. Denn bei agilen Vorgehensweisen wird versucht sehr schnell Geschäftswert zu liefern. Um zu priorisieren und den Business-Value planen zu können, muss dieser zunächst für die einzelnen Aufgaben geschätzt sein. Im Gegensatz zu Story-Point Schätzungen nehmen bei Value-Point-Schätzungen neben dem Development-Team auch der Product-Owner und ggf. Stakeholder und Key-User an der aktiven Schätzung teil. In manchen Teams werden Value-Points auch nur von Product-Owner und Stakeholdern bzw. Key-Usern geschätzt. In diesem Fall muss bei der Priorisierung des Backlogs dann noch auf den Technischen-Wert geachtet werden.
Dazu wird wieder ein granulares und gut überschaubares Referenz-PBI ausgewählt. Dieses wird im Team nochmals besprochen und dann ein Referenz-Value vergeben beispielsweise 8. Die Skala der Value-Points orientiert sich wieder an der Fibonacci-Reihe. Im Zuge der Schätzung wird jedes vorhandene PBI der Reihe nach mit dem Referenz-PBI verglichen und der Estimation-Poker gespeilt.
5. Priorisierung
Wurden die PBIs im Zuge des Estimation-Pokers (Planning-Pokers) geschätzt so steht das Team vor der nächsten Herausforderung. Nun muss das Product-Backlog in eine sinnvolle Reihenfolge gebracht werden. Bei der Priorisierung müssen sowohl die Story-Points als auch die Value-Points Berücksichtigung finden.
Das Team stellt sich in dieser Situation oft folgende Fragen:
- Ist es sinnvoll zunächst an vielen kleinen User-Stories mit wenig Value-Points zu arbeiten, um jedoch schnell kleinere Features liefern zu können?
- Oder ist es sinnvoll zunächst an User-Stories mit möglichst vielen Value-Points zu arbeiten, auch wenn dies die schnelle und regelmäßige Auslieferung verzögert oder verhindert?
Die Antwort auf diese Fragen ist weder noch. Das Team kann nur mit der Betrachtung der einzelnen Einheiten keine klare Aussage über die Priorität und Reihenfolge der User-Stories treffen. Einerseits müssen bei der Entscheidung, welche User-Stories im nächsten Sprint umgesetzt werden sollen, technische Abhängigkeiten Berücksichtigung finden, andererseits müssen Story-Points und Value-Points noch zueinander in Bezug gesetzt werden. Um dies zu ermöglichen wir eine neue Kennzahl notwendig das Preis-/Leistungsverhältnis oder in der Englischen Literatur oft als „Bang for the Book Score“ bezeichnet, setzt die Value-Points mit den Story-Points in ein Verhältnis das Value/Story-Point-Verhältnis.
Dazu wird für jedes PBI dessen Value-Points durch die Story-Points dividiert. Danach können alle PBIs/User-Stories nach diesen Quotienten sortiert werden. Diejenigen Stories, die den höchsten Quotienten aufweisen, haben dann also das beste „Preis-/Leistungsverhältnis“ also Value/Story-Point-Verhältnis und sind somit am lukrativsten umzusetzen.
Sollte hier User-Stories als erstes aufscheinen die jedoch noch technische Abhängigkeiten vorbedingen, so spricht dies meist für eine falsche oder unfertige Schätzung der Value-Points. Da in den Value-Points-Schätzungen ja auch der Technische-Wert mit einfließen sollte.
6. Kosten-Schätzung mit Value-Points und Velocity
Die Planung des ersten Sprints erfolgt dann auf der Priorisierung des Backlogs und auf Erfahrungswerten. Das Team schätzt ungefähr ab wie viele Story-Points sie im ersten Sprint schaffen werden und Planen den Sprint dann mit dieser Anzahl ungefähr aus. Am Ende des ersten Sprints wird dann verglichen. Lag das das Team über oder unter der geschätzten Story-Point-Anzahl? Die Anzahl der tatsächlich geschafften Story-Points wird Velocity genannt. Diese Umsetzungsgeschwindigkeit schwankt noch in den ersten Sprints pendelt sich dann aber nach 2-3 Sprints langsam ein und bleibt dann, solange das Team gleich bleibt relativ stabil. Aufgrund dieser Velocity kann dann eine Zeitliche Abschätzung getroffen werden wie lange das Team brauchen wird das Backlog abzuarbeiten. Aufgrund dieser Abschätzung und den vorhandenen Kosten, die für das Team aufgebracht werden kann dann ein Budget in Euro für das gesamte Backlog errechnet werden. Des Weiteren kann ein Kostenfaktor pro Story-Point berechnet werden, was wiederum Aussagen über die Kosten der einzelnen geplanten Features zu lässt.
Agile Schätzmethoden
1. Estimation-Poker (Planning-Poker)
Estimation-Poker (oder auch Planning-Poker, oder Scrum-Poker genannt) ist eine konsensbasierte Schätzmethode die vor allem in agilen Projekten eingesetzt wird. Das Schätzen wird gamifiziert indem jeder Schätzer die Fibonacci-Folge in Form von Pokerkarten bis z.B. 144 in der Hand hält. Einige Planning-Poker-Kartensets weichen von der Fibonacci-Folge ab und haben beispielsweise ab 13 die Karten 20 40 und 100 im Deck. Beim Estimation-Poker-Game wird nun der Reihe nach PBI für PBI vom Product-Owner präsentiert. Das Team vergleicht dann diese PBIs mit dem Referenz-PBI und jeder Developer entscheidet für sich verdeckt, wie viele Story-Points das PBI bekommen soll. Wenn alle Developer die Schätzung verdeckt durchgeführt haben, werden die Karten, gemeinsam umgedreht und verglichen. Nun kann jeder ein Statement abgeben warum diese Story-Point-Anzahl gewählt wurde. Derjenige der die höchste oder die niedrigste Karte gespielt hat muss allerdings ein Statement abgeben warum diese Zahl gewählt wurde. Nachdem alle Argumente gehört wurden und darüber diskutiert wurde, wird nun eine weitere Runde gespielt. Solange, bis das Team einen Konsens erreicht hat und alle dieselbe Story-Point-Anzahl wählen.
Vorteil:
Plannig-Poker/Estimation-Poker ist ein konsensbasiertes Verfahren, das solange gespielt wird bis im Team Einigkeit über die Aufwände herrscht. Dies ist eine Grundvoraussetzung für die Umsetzung mit agilen Methoden wie Scrum, bei denen Das gesamte Team für die Umsetzung gemeinsam verantwortlich ist. Das Herstellen des Commitments des Teams ist somit leichter möglich.
Nachteil:
Planning-Poker/Estimation-Poker kann sehr lange dauern und zeitraubend sein. Es kann ausschweifend diskutiert werden und benötigt einen guten Moderator, der die Diskussion leitet und sicherstellt, dass jeder im Team zu Wort kommt und auch wirklich ein Konsens erreicht wird.
2. Estimation-Game
Beim Estimation-Game wird um Zeit zu sparen, ein Stapel von auf Papier geschriebener User-Stories auf den Tisch gelegt und dem Team zum Schätzen gegeben. Das Team hat zunächst die Aufgabe die User-Stories mit einander in Bezug zu setzen und in eine Reihenfolge ihrer Größe zu bringen. Dazu nimmt jeder Developer der Reihe nach eine User-Story vom Stapel, liest den Inhalt laut vor und ordnet die User-Story passend der Größe nach in eine Reihe ein. Der Product-Owner steht dabei dem Team für Rückfragen zur Verfügung und achtet darauf, dass jede Story auch richtig verstanden wurde. Während das Team die User-Stories in eine Reihe bringen, darf nicht diskutiert werden. Derjenige der die Story-Card gezogen hat ist für die Einordnung verantwortlich. Wenn alle User-Stories der Größe nach sortiert sind, werden von der kleinsten zur größten User-Story die Story-Points vergeben. Die vorhergehende User-Story dient dabei immer als Referenz zur darauffolgenden User-Story. Bei der Vergabe der Story-Points darf das Team über die Anzahl der Points diskutieren, die Reihenfolge darf nur in Ausnahmefällen verändert werden, wenn zum Beispiel das Team gemeinsam zu dem Entschluss gekommen ist, dass eine große Abweichung zwischen den Soll- und Ist-Platz der Story in der Liste ist und die Story doch falsch verstanden wurde.
Vorteil:
Aufgrund des nur eingeschränkt zugelassenen Diskussionsspielraums und des Diskussionsverbots in der Sortierphase, ist das Estimation-Game meist schneller als Planning-Poker. Das Estimation-Game eignet sich daher sehr gut für eine grobe initiale Schätzung des Backlogs.
Nachteil:
Das Estimation-Game ist eine ungenauere Methode, das unter umständen auch keinen Konsens im Team erreicht. Daher ist es oft notwendig eine zweite genauere Schätzung durch Planning-Poker durchzuführen.
3. Magic-Estimation
Die schnellste Methode um zu einer initialen Schätzung des Backlogs zu kommen ist die Magic-Estimation. Dazu werden die auf Papier geschriebenen User-Stories zu gleichen Teilen im Team verteilt. Am Tisch oder auf einem Board an der Wand ist die Fibonacci-Folge gelegt. Das Team muss nun innerhalb von 10 Minuten alle Kärtchen einer Zahl zuordnen. Während dieser Zeit darf jeder vom Team seine eigenen Karten platzieren und andere Karten verschieben. Während die Zuordnung stattfindet sind keine Diskussionen im Team erlaubt. Der Product-Owner beobachtet den Prozess und nimmt gegebenenfalls User-Stories aus dem Spiel, wenn er merkt, dass sich einzelne Team-Mitglieder bei diesen uneinig sind. Diese herausgenommenen User-Stories werden im Nachgang dann mit dem Team diskutiert und zugeordnet.
Vorteil:
Die schnellste Methode der Zuordnung und Grobschätzung.
Nachteil:
Die User-Stories werden nicht im gesamten Team besprochen. Der Product-Owner kann nicht sicher gehen, dass das Team alle User-Stories auch richtig verstanden hat. Es kann auch sein, dass nicht jeder Developer alle User-Stories sieht und versteht. Somit kann weder ein gemeinsames Verständnis für die Aufgabenstellung noch ein Konsens vorausgesetzt werden. Es braucht daher auf jeden Fall eine zweite Detailschätzung und ein gemeinsames Refinement mit dem Product-Owner.
Fazit
Agile Schätzmethoden reduzieren die Komplexität der Schätzung indem sie Umsetzungsgeschwindigkeit von Aufwands-Schätzungen trennen. Sie stellen auch einen Konsens im Team her und können eingesetzt werden obwohl noch nicht alle Anforderungen bis ins letzte Detail vorhanden sind. Diese Stärke macht das Team und die Lösung flexibel und somit effizienter und günstiger.
Dieser Artikel gehört zur Artikelreihe „Digitalisierung Kosten- und Budgetplanung“
Buchempfehlungen – schneller gelesen als gedacht
Wenn Sie jetzt mehr über Digitalisierung oder agile Softwareprojekte wissen wollen, dann klicken sie auf eines dieser Bücher (Link zu Amazon):
Folgen Sie uns jetzt im Social Media:
https://www.facebook.com/Digitalisierung Täglich zwischen 20 und 100 Beiträge aus über 200 verschiedenen Fachquellen
https://www.facebook.com/DerDigitalisierungsCoach/ Der DigitalisierungsCoach auf Facebook, Infos, Termine und mehr.
https://twitter.com/DavidTheil
Zum Autor:
David Theil aus Linz Oberösterreich ist Digitalisierungs-Coach, Software-Entwickler und als Head of Software-Development für über 30 Softwareentwickler verantwortlich. Beruflich beschäftigt er sich bereits jahrelang mit der Digitalisierung und hat bereits bei vielen Digitalisierungs-Projekten in der Wirtschaft federführend mitgewirkt. Er bewegt sich in Themen wie Digitalisierung, IoT, oder Industrie 4.0 sowohl beratend als auch praktisch mit echten Lösungen.
https://www.xing.com/profile/David_Theil
https://www.linkedin.com/in/david-theil-1a4190148/
https://www.linkedin.com/groups/8678887
https://medium.com/@david.theil
https://twitter.com/DavidTheil
DigitalisierungsCoach 