Agile Methode: Burndown Chart (Burndownchart, Burndown Graphic)

Burndown Chart ist eine Methode, mit der die Fortschritte der Leistungserstellung innerhalb einer Timebox abgebildet werden kann.

Hilfsmittel / Voraussetzungen

Ein Flip-Chart oder Pin Board, das über den Verlauf der Timebox nicht benötigt wird und für alle Beteiligten sichtbar ist.

Voraussetzung:

• Die Tasks (Arbeitspakete) oder Inkremente, die in der Timebox abgearbeitet, oder erstellt werden sollen, sind benannt und der Timebox zugewiesen.
• Die Arbeitspakete sind so skaliert, dass sie nicht länger als einen Tag dauern.

Wie geht es?

Vertikale (y-Achse): Die Gesamtzahl der Arbeiten, die innerhalb der Timebox zu erledigen sind.

Horizontale (X-Achse): Die Tage, die die Timebox dauern soll.

Das Umsetzungsteam aktualisiert jeden Tag beim Daily Standup Meeting den Burndown Chart. Für den jeweiligen Tag wird die Zahl der noch offenen Arbeitspakete eingetragen.

Liegt die Zahl der verbleibenden Arbeitspakete unter der Ideallinie, wird mehr Arbeit geleistet als geplant. Liegt die Zahl der Arbeitspakte über der Ideallinie, dann ist das Team langsamer als geplant.

Burndown Charts werden in vielfältigem Zusammenhang genutzt. Es gibt:

• Sprint Burndown Chart
• Etappen Burndown Chart
• Product Backlog Burndown Chart
• usw.

Agile Methode: Feature Points 

Die Schätzung erfolgt analog zur Schätzung mit Story Points. Im Unterschied zur Stories werden hier die „Features“ geschätzt. D.h. es wird die Komplexität von einzelnen Inkrementen relativ geschätzt. Mit den Feature Points kann das Team bestimmen, wie viele und welche Features in eine Timebox passen. Die Team Velocity kann ebenso aus Feature Points ermittelt werden. 

Hilfsmittel / Voraussetzungen

Die Features (Funktionalitäten) müssen vorher aus dem Product Backlog entwickelt werden.

Wie geht es?

1. Aus dem Product Backlog, einer Etappe oder eines Sprints, wird ein Feature ausgewählt, das von dem Team für relativ klein gehalten wird. 
2. Dieses Feature bekommt den Wert 1 zugewiesen.
3. Alle weiteren Features werden relativ zu diesem Feature geschätzt.

Agile Methode: Normalisierte Schätzung (Normalized Estimation)

Mit der normalisierten Schätzung wird versucht, eine gemeinsame Schätzbasis zwischen verschiedenen Teams zu erarbeiten.

Bei der Schätzung auf Basis von Story Points wählt jedes Schätzteam eine individuelle User Story als Referenzwert für den Schätzwert 1. Da jedes Team seinen eigenen Referenzwert auswählt, sind die Story Points der einzelnen Teams nicht vergleichbar.

Damit ist auch die Team Velocity nicht vergleichbar. Die Story Points verschiedener Teams dürfen nicht addiert werden. Dieses Problem versucht das Scaled Agile Framework (SAFe) zu lösen.

Wie geht es?

1. Jedes Team wählt eine Referenzstory, die ungefähr einen halben Tag Aufwand zur Umsetzung benötigt. Oder die Teams einigen sich auf eine Story als Referenz. Eine weitere Möglichkeit besteht darin, mehr als eine Story als Referenz zu nutzen.
2. Alle anderen Storypoints werden anschließend auf Basis dieser Referenzschätzung geschätzt.

Hier wird eine Übertragung gemacht. 1 Storypoint = 1 Personentag. Die Schätzung findet faktisch nicht auf Basis von Storypoints, sondern auf Basis von Personentagen statt, die jetzt als Storypoints bezeichnet werden. 

Agile Methode: Team Velocity (Team Performance)

Über die Team Velocity kann die Arbeitsgeschwindigkeit eines Teams und die Weiterentwicklung eines Teams gemessen werden. Außerdem kann eine Prognose gemacht werden, wie viele Story Points von einem Team innerhalb einer Timebox geleistet werden. Außerdem kann der Product Owner damit den Fortschritt der Leistungsentwicklung innerhalb einer Timebox verfolgen.

Hilfsmittel / Voraussetzungen

Der erwartet Aufwand für die Leistungserstellung der einzelnen User Stories oder Inkremente muss in Storypoints geschätzt sein.

Die verwendeten Timeboxes müssen gleich groß sein.

Wie geht es?

1. Die Zahl der Storypoints, die ein bestimmtes Team innerhalb einer Timebox abgearbeitet hat, wird ermittelt.
2. Die Erwartung, wenn sich das Team weiterentwickelt: Es arbeitet in der nächsten Timebox mindestens so viele Story Point ab, wie in der vorherigen. Unter dieser Annahme ist die Zahl der Storypoints für die nächste Timebox als Basis für die auszuwählenden User Stories, die in die Timebox passen, recht einfach.
3. Mit zunehmender Zahl der durchlaufenen Timeboxes kann die durchschnittliche Zahl an Storypoints berechnet werden.

Agile Methode: Magic Estimation – die magische Schätzung 

Ziel / Nutzen

Die Magic Estmation ist eine relative Schätzung, d.h. alle zu schätzenden User Stories, Tätigkeiten, etc. werden in eine Rangfolge des Aufwandes gebracht.

Hilfsmittel

Planning Poker Karten oder andere Schätzwerte

Wie geht es?

1. Die Schätzwerte werden auf dem Tisch ausgelegt.
2. Das Schätzteam sortiert die User Stories oder was sonst geschätzt werden soll, zu den jeweiligen Schätzwerten.
3. Sind sich die Teammitglieder nicht einig, dann erläutern sie ihre Entscheidung mit allen anderen.

Agile Methode: Schätzen mit Planning Poker

Ziel / Nutzen

Mit dem Planning Poker kann alles geschätzt werden. Die Ergebnisse von einem Planning Poker werden realistischer, wenn die Schätzenden gleichzeitig die Leistungserbringer sind, die mit den Schätzergebnissen leben müssen. 

Hilfsmittel

pro Schätzer einen Satz Planning Poker Karten

Wie geht es?

1. Jeder Schätzende hat einen Satz an Planinng Poker Karten. Auf den Karten stehen die Werte: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Diese Zahlen können je nach Planning Pokersatz auch abweichen. Typisch ist, dass die Differenz der Zahlen größer wird, wenn die Zahlen größer werden.
2. Für jedes zu schätzende Element, schätzt jeder Schätzer verdeckt wieviel Aufwand er erwartet. 
3. Die Vertreter des niedrigsten Werte und des höchsten Wertes erläutern die Gründe für ihre Schätzung.
4. Danach erfolgt eine neue Schätzung.
5. Dieser Prozess wird fortgesetzt, bis sich die Schätzungen auf einen Schätzwert angenähert haben. 

Auch hier besteht natürlich die Möglichkeit, die Schätzergebnisse wieder in Personentage umzurechnen, wenn die Personentage für die kleinste Einheit zusätzlich geschätzt werden. Problematisch kann es werden, wenn die Ergebnisse von mehreren Planning Poker Runden mit unterschiedlichen Teilnehmern zusammen genommen werden. 

Agile Methode: Schätzen im agilen Umfeld

Im klassischen Projektmanagement ist das Schätzen für die Projektplanung von Bedeutung. Von vielen Menschen, die in Projekten arbeiten, wird das Schätzen von Dauer, Arbeitsstunden und Kosten als der aufwendigste und unangenehmste Teil des Planungsprozesses empfunden. 

Da die Planung in agilen Methoden scheinbar keine so große Rolle spielt, entsteht hier schnell die Erwartung, „nicht mehr schätzen“ zum müssen. Diese Hoffnung deckt sich aber nicht mit der Realität. Auch hier müssen die Beteiligten und insbesondere die Menschen, die die Leistungen entwickeln, ständig schätzen.

Exaktheit vor Genauigkeit

Die wichtigste Schätzregel, wenn sie agil arbeiten:

Was bedeutet das?

Stellen sie sich vor, jemand schätzt und kommt zu folgender Aussage:

„Am ersten Dienstag im Februar des nächsten Jahres in Frankfurt wird es zwischen 17:00 und 17:15 genau 2 mm Niederschlag am Bahnhof geben.“

1. Diese Aussage ist sehr genau. 
2. Wie viel Aufwand steckt in dieser Aussage: Der Schätzende hat die Wetterdaten des Frankfurter Bahnhofs über die letzten zehn Jahre in seine Analyse einfließen lassen. Er hat Wahrscheinlichkeiten für die Niederschlagswahrscheinlichkeit und Niederschlagsmenge berechnet. Er hat zusätzlich ein globales Langzeit Wettermodell bemüht uns außerdem die Temperaturkurve für Frankfurt in Kombination mit der Niederschlagswahrscheinlichkeit statistisch kombiniert. Er hat sich also alle Hilfsmittel, die ihm zur Verfügung standen, genutzt und alles getan, damit diese Schätzung so exakt wie möglich wird. Dafür hat er natürlich viel Arbeitszeit aufwenden müssen. Es hat sich gelohnt. Oder?
3. Würden sie dieser Schätzung vertrauen? Würden sie sich darauf verlassen, dass dieses Ereignis genauso eintritt?

Nehmen wir im Vergleich ein andere Aussage:

„Im Frühjahr des nächsten Jahres wird es am Frankfurter Bahnhof regnen.“

1. Diese Aussage ist sehr exakt.
2. Der Aufwand, der hinter dieser Schätzung liegt, ist kaum messbar. Die Kausalität, die der Schätzende genutzt hat, war: Im Frühjahr innerhalb von drei Monaten irgendwann Regen => also auch am Frankfurter Bahnhof. Hat sich der Aufwand gelohnt?
3. Würden Sie dieser Schätzung vertrauen? Würden Sie darauf vertrauen, dass dieses Ereignis eintritt?

 Die erste Schätzung ist sehr genau. Das Eintreten ist sehr unwahrscheinlich. Der Aufwand sehr groß. Der Nutzen der Schätzung ist sehr gering.

Die zweite Schätzung ist sehr exakt. Das Eintreten der Schätzung extrem wahrscheinlich. Der Aufwand minimal. Aber der Nutzen der Schätzung ist nicht vorhanden.

Irgendwo zwischen diesen beiden Extremwerten liegt eine Schätzung, die einen guten Kompromiss zwischen den beiden Schätzungen darstellt. Diese gilt es zu finden.

Es gibt eine Reihe an Schätzverfahren, die in einem agilen Umfeld bevorzugt werden. Allerdings können auch alle anderen Schätzverfahren, die sich im Projektmanagement etabliert haben, eingesetzt werden. Umgekehrt gilt aber auch, dass alle Schätzverfahren die typisch für ein agiles Vorgehen sind, im klassischen Projektmanagement verwendet werden.

Agile Methode: Schätzen mit Story Points (Storypoint)

Ziel / Nutzen

Story Points werden verwendet, um die relative Umsetzungskomplexität von User Stories zu schätzen. Dieses Schätzverfahren abstrahiert von der Aufwandsschätzung in Stunden. Das kann vorteilhaft sein, weil das Team mit zunehmender Erfahrung lernt und damit die Umsetzungsgeschwindigkeit zunimmt.

Außerdem findet eine Abstraktion von den verschiedenen Arbeitsgeschwindigkeiten der Teammitglieder statt. Die Schätzung wird also auch für Menschen unterschiedlicher Verfahren vergleichbar.

Hilfsmittel

keine

Wie geht es?

1. Das Team wählt aus den Uster Stories eine Geschichte, die relativ klein ist. Diese Geschichte bekommt den Wert 1 zugewiesen.
2. Alle weiteren User Stories werden relativ zu dieser Referenzstory geschätzt. Wenn eine Story z.B. 4 Storypoints hat, dann ist die Umsetzungskomplexität 4-mal so groß wie die Referenzstory.
3. In weiteren Verlauf können die Storypoint auch auf Personenstunden um skaliert werden, wenn der User Story, der ein Wert 1 zugewiesen wurde, zusätzlich Personenstunden zugewiesen werden. So können alle weiteren Schätzungen leicht in Personenstunden ungerechnet werden.