Intime Eingriffe in Teams und Schätzprozesse mit Story Points

Dieser Blogpost ist ein Erfahrungsbericht aus einem Softwareprojekt. Es wird die Umstellung des Vorgehens bei Schätzungen mit Story Points im Backlog-Refinement beschrieben. Wer wenig Zeit hat und eigentlich nur ein Management-Summary haben möchte, sollte einen einen Blick auf die Zusammenfassung am Ende des Posts werfen. Für alle Anderen beginnen wir jetzt mit dem ersten Teil und der Problem­beschreibung als Auslöser der Umstellung.

Problembeschreibung

Bei uns entstand während der Entwicklung in einem Projekt das Gefühl, dass die Story Points (SP) für den Inhalt von kleinen (1 SP) User Stories nicht passen. Es gab mal 1-SP-Stories mit gefühlt viel Inhalt und welche mit wenig Inhalt. Dass wir viel Inhalt in kleinen Stories untergebracht haben, kommt aus der Historie: Zu Anfang gab es mehrere Dienstleister, viel politisches Gerangel und Druck im Projekt. Wir hatten uns angewöhnt, auch viel Inhalt mit kleinen Story Points zu schätzen.

Damit existierte immer eine Erwartungshaltung für den Funktionsumfang von 1 SP. Ein Beispiel ist die Entwicklung eines neuen Dialogs für den Nutzer: Der neue Dialog enthält dabei ein Formular mit Dateneingabe und -validierung. Dagegen gab es auch triviale Themen mit 1 SP. Ein Thema war das Hinzufügen eines Hinweistextes für den Nutzer; derartige Punkte haben wir dann auch mit 1 SP geschätzt und diesem kleinen Bereich zugeordnet.

Die Ausgangslage

Die Bilder in der Galerie sollen den Effekt etwas verdeutlichen. Das Feature A wird aufgrund des trivialen Funktionsumfangs mit 1 SP bewertet (Abb. 1). B wird mit Druck der Erwartungshaltung ebenfalls mit 1 SP geschätzt (Abb. 2). Realistisch und als Abgrenzung zu trivialen Inhalten wäre der Umfang von Feature B jedoch mit 3 SP besser differenziert (Abb. 3).

Damit festigte sich eine gefühlte Bandbreite von kleinen User Stories. Grob eingeteilt in kleine, mittlere und große Themen, so dass kein Spielraum mehr bestand, Inhalte im 1-SP-Bereich voneinander abzugrenzen.

Soviel zum Problem. Beschäftigen wir uns nun mit der Motivation für die Anpassung des Schätzprozesses.

Motivation

Die fehlende Differenzierung bereitete uns zusehends Kopfschmerzen, weshalb wir das Problem angehen und lösen wollten. Als Erstes war für uns wieder eine (i) Unterscheidung der Inhalte voneinander wichtig. Wir wollten eine erneute Abgrenzung von simplen und komplizierteren Themen im 1 SP-Abschnitt erreichen.

In einem Stacey-Diagramm^[1] (Abb. 4) lässt sich das grafisch darstellen; es betrifft die beiden Bereiche in der unteren linken Ecke, farbig dargestellt in Gelb und Türkis. Neben der Differenzierung wollten wir zusätzlich eine (ii) realistischere Einschätzung der User Stories haben: Was hat eher die Größe 1 SP, was ist eher 2 oder sogar 3 SP groß?

Zusätzlich ging es uns auch um mehr (iii) Flexibilität in den Schätzungen. Es stünde dann nicht nur ein Wert (1 SP) zur Auswahl, sondern die Selektion würde sich auf zwei oder mehr (1 SP, 2 SP, 3 SP) Werte erweitern. Bei einer Verknüpfung der Differenzierung und der Flexibilität entsteht durch die Kombination so eine realistischere Einschätzung der Größe.

Außerdem sollte ein positiver Effekt auf die (iv) Planungssicherheit für das Anforderungsmanagement erreicht werden. Inhalte mit 1 SP sind dann möglichst immer simpel, es gibt wenig Risiko, Komplexität und Aufwand. Alle im Team wissen, was auf sie zukommt und es reduziert die Gefahr einer Fehleinschätzung.

Nun genug dem Vorgeplänkel. Der kommende Hauptteil des Artikels beschäftigt sich mit dem Umstellungsprozess für Schätzungen im Team. Also wie war unser Ansatz, dass Problem zu lösen?

Umstellungsprozess

Bis hierher waren unsere Annahmen für fehlende Abgrenzungen von Inhalten bei 1-SP-Stories rein hypothetisch, wobei sich dieses Gefühl aber über längere Zeit festigte. Um dieser Vermutung nachzugehen, haben wir im ersten Schritt Daten in JIRA mit folgender Fragestellung ausgewertet: Lassen sich dort Spuren finden, die unser Gefühl der großen Bandbreite bei kleinen Story Points bestätigen? Die Idee bestand darin, die Cycle Time der User Stories zu berechnen. Also: Wie lange braucht das Team für die reine Implementierung der User Stories?

Gibt es demnach große zeitliche Schwankungen innerhalb von kleinen User Stories aufgrund von unterschiedlichen Inhalten? Für die Berechnung wurden die Unteraufgaben der einzelnen User Stories betrachtet. Wichtig war für uns die Zeit, in der sich die Aufgaben im Status „In Progress“ befanden.

Der Ansatz

Für eine User Story haben wir dann die Zeiten der Unteraufgaben aufsummiert. Somit konnte für jede 1 SP Story die reine Entwicklungszeit berechnet werden. Der Mittelwert und die Standardabweichung lieferte dann noch greifbare Zahlen.

Wir glaubten an eine fehlende Differenzierung in den 1-SP-Stories. Es bestand aber auch die Möglichkeit, dass höhere Story Points (2 SP, 3 SP, …) eine ähnliche Problemstellung aufwarfen. Um Schwierigkeiten mit größeren Werten ausschließen zu können, haben wir die Auswertung für die User Stories mit 2, 3, 5 und 8 SP wiederholt. 13 SP und höhere Punkte gab es nicht im Status „In Progress“. Ergänzend wurden die Zeiten auf Werktage beschränkt, um eine Verfälschung der Daten ausschließen zu können. War eine User Story über das Wochenende „In Progress“, wurden damit der Samstag und der Sonntag nicht gezählt.

Jetzt wird es ein wenig statistisch. Keine Sorge, über Mittelwerte und Standard­abweichung geht es aber nicht hinaus.

Ergebnisse

Die Auswertung wird in Abbildung 5 dargestellt. Auf der x-Achse sind die Story Points aufgeführt, die y-Achse zeigt die Cycle Time in Tagen. Für die 1-SP-Stories (roter Kasten) benötigten wir für die Entwicklung also im Mittel (Ø) 7 Tage. Die Standardabweichung (SD) beträgt ± 5 Tage. Minimal (MIN) sind es damit 2 Tage, maximal (MAX) 12 Tage Entwicklungszeit. Für die weiteren SPs ergeben sich für

• 2 SP (Ø: 11 Tage, SD: ± 9 Tage, MIN: 2 Tage und MAX: 20 Tage)
• 3 SP (Ø: 15 Tage, SD: ± 13 Tage, MIN: 2 Tage und MAX: 28 Tage)
• 5 SP (Ø: 17 Tage, SD: ± 13 Tage, MIN: 4 Tage und MAX: 30 Tage)
• 8 SP (Ø: 19 Tage, SD: ± 17 Tage, MIN: 2 Tage und MAX: 36 Tage)

Nach den Ergebnissen steigt die durchschnittliche Cycle Time mit der Größe der User Stories von 1 SP bis 8 SP um jeweils Ø 3 Tage an. User Stories mit 2 SP brauchen im Durchschnitt 3 Tage länger als 1-SP-Stories, 3-SP-Stories benötigen 3 Tage länger als 2-SP-Stories, usw.

Die Standardabweichung von 1 SP bis 8 SP verändert sich im Mittel um jeweils ± 3 Tage. Beträgt die Abweichung der durchschnittlichen Entwicklungszeit bei 1 SP ± 5 Tage, sind es bei 2 SP ± 9 Tage, bei 3 SP bereits ± 13 Tage, usw.

Mit steigenden SP erhöht sich die Cycle Time aber auch die Varianz in der Entwicklungszeit und damit die Bandbreite von Inhalten innerhalb einer Größe. 8-SP-Stories mit ± 17 Tagen variieren also in der Entwicklungszeit mehr als 1-SP-Stories mit ± 5 Tagen. Damit konnte das Gefühl einer überdurchschnittlichen Bandbreite von Inhalten in 1-SP-Stories vom Anfang nicht bestätigt werden.

Erste Erkenntnis

1-SP-User-Stories schwanken in den Inhalten nicht mehr als User Stories mit mehr Story Points. Ganz im Gegenteil, je größer eine User Story geschätzt wird, umso größer ist die Varianz von Inhalten. Mal ist der Inhalt für die Story Points klein und die Entwicklung geht schneller. Zu einem anderen Zeitpunkt ist der Inhalt für die Story Points groß und die Entwicklung dauert entsprechend länger. Vermutlich für viele keine große Überraschung.

Nachdem wir nun etwas Konkretes hatten, wollten wir auch tätig werden. Wie genau wir jetzt vorgegangen sind, beschreibt der nächste Abschnitt.

Umstellung

Jetzt gab es also etwas zum Anfassen: Die Cycle Time variiert über alle User Stories. Die Problemstellung lässt sich damit auf alle Story-Größen übertragen. Mit diesen Erkenntnissen konnten wir nun das weitere Vorgehen entscheiden. Wie sollte es jetzt weitergehen und wie können wir den Umgang mit Story Points verbessern?

Nach einigen Gesprächen haben wir uns trotzdem für die 1-SP-Stories entschieden. Initialer Aufhänger waren diese kleinen Stories, denn dort entstand das Gefühl der Problemstellung. Außerdem sind die kleinen Story Points am unteren Ende der Story-Point-Skala. Sie bilden die Grundlage für die Markierung von Ready Stories und haben damit eine gewisse Brisanz. Außerdem wollten wir ja irgendwo anfangen.

Aus der Problemstellung heraus sollte sich die Differenzierung und Flexibilität für die Schätzung der Inhalte erhöhen; es sollte mehr Spielraum für die 1-SP-Stories erzeugt werden. In der nachfolgenden Zeit haben wir eine Methode für die Anpassung erstellt. Wichtig war neben der Konzipierung auch die Umsetzung und die Erfolgskontrolle. Als Vorgehen wählten wir eine Transformation der SP-Skala. Abbildung 6 und Abbildung 7 zeigen eine Darstellung der Umstellung.

Die linke Menge repräsentiert die alte Skala für Story Points, mit der das Team bis zur Umstellung geschätzt hat. Die rechte Menge repräsentiert die neue Skala, mit den in Zukunft gearbeitet werden sollte. Um die Differenzierung, Flexibilität und Skalierung erreichen zu können, brauchten wir mehr Platz im unteren Schätzbereich. Die ursprünglichen 1 SP wurden neu auf 1 SP, 2 SP und 3 SP erweitert. Frühere kleine 1 SP bleiben 1 SP. Alte mittlere 1 SP werden jetzt mit 2 SP bewertet. Große 1 SP werden neu den 3 SP zugeordnet. Die alten Größenschätzungen für 2 SP, 3 SP, usw. werden nach oben skaliert (Abb. 7), somit entsprechen die Werte auf der rechten Seite den neuen Schätzwerten.

Beispiel

Es soll ein neues Formular mit Dateneingabe und -validierung entwickelt werden. Nach der alten Skala würde ein Entwickler im Backlog Refinement für die User Story 1 SP vergeben. In Folge der Umstellung hat der Entwickler jetzt die Größen 1 SP, 2 SP und 3 SP als Differenzierung der Größe zur Verfügung. In Abgrenzung zu einem trivialen Thema wie etwa das Hinzufügen eines Hinweistextes kann der Entwickler nach neuer Schätzung 3 SP vergeben.

Nachdem das Konzept für das Vorgehen fertiggestellt war, wurde die Umstellung mit Hilfe einer Präsentation im Team gestartet. Zur Umstellung des Prozesses gehört auch die Begleitung der Aktivitäten und die Reflektion des Vorgangs. Vorab sei erwähnt, dass es starke Auswirkungen im Prozess gegeben hat. Hier nun die Erfahrungen als wir uns im Prozess befanden.

Begleitung

Die Änderungen für Schätzungen waren nun ausgerollt, jedoch war die Umstellung damit nicht abgeschlossen. Wichtig war jetzt, das Team durch Hilfestellung bei Fragen oder Problemstellungen zu unterstützen.

Das Hauptaugenmerk bei der Unterstützung während der Umstellung wurde auf das Backlog Refinement gerichtet. Es gab als Erinnerung für den Zusammenhang von alten und neuen Schätzwerten einen Ausdruck der Abbildung 7. Eine Verbindung ist hier zum Beispiel die von 3 SP zu 8 SP. Bei Fragen und Unklarheiten konnten so die Entwickler einen kurzen Blick auf die alten und neuen Werte werfen. Es gab immer mehrere Ausdrucke, falls ein Teammitglied Notizen oder Kommentare vermerken wollte.

Nachdem wir an der Schätzbasis geschraubt hatten, wollten wir im Team wissen, inwieweit sich die Änderungen auf den Entwicklungsprozess auswirken. Es stellte sich also die Frage: Was hat es gebracht und war die Umstellung erfolgreich? Diese Fragen wird im nächsten Abschnitt beantwortet.

Reflektion

Wir wollten wissen, ob die Ziele (siehe Motivation) mit

• (a) Bessere Unterscheidung der Inhalte
• (b) Realistischere Einschätzung der Anforderungen
• (c) Größere Flexibilität bei der Vergabe von Story Points und
• (d) stabilere Planungssicherheit für das Anforderungsmanagement

erreicht wurden. Bei den Punkten (a) – (c), also Unterscheidbarkeit, Realitätsnähe und Flexibilität, kann davon ausgegangen werden, dass die Inhalte durch die größere Auswahl von Story Points (1 SP, 2 SP und 3 SP) für kleine Funktionalitäten besser differenziert werden können. Dadurch ergibt sich eine erweiterte Flexibilität bei der Vergabe der Story Points und zusätzlich eine realistischere Einschätzung der Größe.

Wie sieht es jedoch bei Punkt (d) aus? Konnte die Planungssicherheit für das Anforderungsmanagement erhöht werden? War es möglich, ein „Verschätzen“ bei Story Points zu reduzieren?

Mit einem Blick auf die Grafik in Abbildung 8 lässt diese Frage recht einfach beantworten: Nein. Dargestellt sind zwei Linien. Auf der x-Achse sind die Sprints angetragen, die y-Achse zeigt die Anzahl von Story Points. Die geplanten User Stories pro Sprint (Commitment) werden in der blauen Linie dargestellt. Der orange Linie visualisiert die gelieferten (Completed) User Stories pro Sprint. Auch wenn der blaue Kasten nicht eingezeichnet wäre, sieht man sofort den Startzeitpunkt der Umstellung: Man erkennt die Veränderung in den Verläufen. Die Ausschläge der einzelnen Linien werden größer.

Hier noch kurz zur Anmerkung: Die Ausschläge nach oben waren erwartet. Betrachtet man Abbildung 7, so erhöhen sich die Schätzungen von der linken Seite Richtung der rechten Seite. Beispiel: Ursprüngliche 2 SP entsprechen jetzt 5 SP. Daher auch die höheren Werte für geplante und gelieferte User Stories. Beabsichtig waren aber nicht die stärkeren Differenzen zwischen den beiden Linien, also das größere „Verschätzen“ zwischen commited und completed User Stories.

Zweite Erkenntnis

Nach der Umstellung hat sich das Team mehr verschätzt. Der Punkt (d) einer stabileren Planungssicherheit konnte nicht erreicht werden. Bei der Bewertung der Verschätzungen sind uns zusätzliche Einflussgrößen auf die Veränderung der Velocity aufgefallen: Irgendwie schien uns die Umstellung nicht der einzige Grund für die Auswirkung auf die Velocity zu sein. Der nächste Abschnitt beantwortet die Frage nach zusätzlichen Fehlergrößen.

Limitierung

Eine Auswirkung von Störparametern kann auch die negative Veränderung der Sprintergebnisse ausgelöst haben – eine Größe kann hier die Einarbeitung in neue, unbekannte Themengebiete sein. Hierzu zählten auch Pakete mit hohem Risiko; es war unbekannt, was uns in der Entwicklung erwartet.

Für die Implementierung der Aufgaben war auch die Einarbeitung in neue Technologien notwendig. Unbekannte Themen, hohes Risiko in den Themen und Lernaufwand für Entwicklungswerkzeuge erzeugten zusätzliche Belastungen des Teams während der Umstellung

Ein Ursache-/Wirkungszusammenhang zwischen Umstellung der Schätzbasis als Ursache und Verschätzungen zwischen geplanten und gelieferten User Stories als Wirkung muss daher kritisch betrachtet werden. Neue, risikobehaftete Themen mit Einarbeitungszeit erschienen als Auslöser möglich.

Die Umstellung der Schätzbasis und mögliche zusätzliche Einflussgrößen wirkten sich negativ auf die Velocity aus. Wir mussten also Handeln und uns überlegen, wie wir weiter vorgehen wollten. Der nun folgende wichtige Abschnitt beschäftigt sich mit der Darstellung von Maßnahmen für die Stabilisierung des Prozesses.

Stabilisierung

Die Situation musste jetzt wieder beruhigt werden. Ziel war es, alle Story Points eines Sprint verlässlich zu schaffen. Zum Erreichen der Sprintziele hat sich das Team die aktuelle Prozessentwicklung angeschaut und Ideen für eine Lösung besprochen. Nach Überlegungen im Team sollte es wieder eine gleiche Basis für Schätzungen geben; alle mussten wieder ein gemeinsames mentales Modell davon haben, nach welchen Faktoren die Größe einer User Story geschätzt wird. Als Ansatz wollten wir wieder auf bekannte Schätzgrößen zurückgehen.

Schlussendlich fiel die Wahl dann auf die Schätzung der Komplexität, andere Merkmale wie Zeit oder Risiko wurden bewusst ausgeklammert. Wir wollten uns nur auf eine Größe und damit auf die Komplexität konzentrieren.

Nach Einführung der reinen Komplexitätsbetrachtung und einiger Adaptionszeit wurde erneut überprüft, wie die Differenz zwischen geplanten und gelieferten Story Points aussieht. Das Resultat wird in Abbildung 9 dargestellt. Die Unruhephase hat mit der Umstellung ab Sprint 36 begonnen, ab Sprint 56 haben sich die beiden Kurven zwischen geplanten und gelieferten Story Points dann wieder angenähert. Es hat somit 20 Sprints gedauert, bis wieder eine Stabilität für einen verlässlichen Sprintoutput erreicht werden konnte.

Dritte Erkenntnis

Mit einer Schätzung auf einer gemeinsamen Basis (Komplexität) konnten wir wieder eine stabile Planungssicherheit herstellen. Was haben wir gelernt aus der Umstellung? Welche Punkte wollen wir bei der nächsten Prozessumstellung beachten? Lernerfahrungen werden jetzt im anschließenden Fazit zusammengetragen.

Fazit

1. „Gefühlte“ Probleme sind nicht automatisch auch „tatsächlich vorhandene“ Probleme und die Wahrnehmung kann täuschen. Ein genauer Blick mit Hilfe der Betrachtung von vorhanden Daten kann ein anderes Bild zeichnen.
2. Eine gute Vorbereitung, Bereitstellung von Hilfestellungen sowie eine ständige Kontrolle der Auswirkungen mit kontinuierlicher Anpassung der Umstellung sind ein Muss.
3. Es ist Vorsicht bei Änderungen von Prozessen im Team geboten, denn Umstellungen können sich auch negativ auswirken.

Als Beispiel dient die im Artikel beschriebene Anpassung der Basis bei Schätzungen. Hier hat sich die Justierung im Prozess negativ auf die Planungssicherheit für das Anforderungsmanagement durch eine steigende Differenz zwischen geplanten und gelieferten User Stories gezeigt.

Neben der Unsicherheit in der Planung hat die Umstellung auch einen negativen Einfluss auf die Entwicklung ausgeübt. Hierbei hat ein erhöhter zeitlicher Aufwand für die kontinuierlichen Anpassungen zur Stabilisierung die weitere Entwicklung ausgebremst. Grundsätzlich hat die Phase der Stabilisierung länger gedauert als die Phasen der Vorbereitung und der Umstellung des Prozesses.

Damit gilt in Reflektion auf die beschriebene Umstellung bei Schätzungen: Vorsicht bei Änderungen an Teamprozessen!

Ich habe nun viele Punkte aufgeführt, die bei der Umstellung der Schätzbasis passiert sind. Da es doch einige Themen waren, will ich zur Erinnerung eine Zusammenfassung mit allen wichtigen Aspekten liefern.

Zusammenfassung

Der Beitrag beschreibt einen Erfahrungsbericht zu einer Prozessumstellung in einem Softwareprojekt. Wir haben die Basis für Schätzungen von User Stories geändert. Auslöser der Umstellung waren „gedachte“ Probleme mit 1-SP-User-Stories; im Team wurde eine „gefühlte“ Bandbreite von unterschiedlich großen Inhalten in 1-SP-User-Stories wahrgenommen. Eine Differenzierung der Themen viel uns dadurch schwer. Mit der Änderung wollten wir wieder eine Unterscheidung von Themen, eine realistischere Einschätzungen der Inhalte, eine Flexibilität in der Vergabe der Story Points und eine stabilere Planungssicherheit für das Anforderungsmanagement erreichen.

Wir haben die Umstellung in Phasen durchgeführt. Dazu zählten:

• die Entwicklung eines Lösungsansatzes
• die Umstellung des Prozesses
• die Kontrolle der Auswirkungen und die Adaption des Vorgehens in Form einer Stabilisierung

Während der Umstellung konnten wir drei Erkenntnisse gewinnen.

1. Es gibt kein „gefühltes“ Problem mit 1-SP-User-Stories. Sie schwanken in den Inhalten nicht mehr als User Stories mit größeren Story Points.
2. Mit der Umstellung haben wir uns mehr verschätzt. Wir konnten keine größere Planungssicherheit erreichen.
3. Mit einer Schätzung auf einer gemeinsamen Basis (Komplexität) konnten wir wieder eine stabile Planungs­sicherheit herstellen.

Daraus folgt:

1. „Gefühlte“ Probleme sind nicht automatisch „vorhandene“ Probleme.
2. Für zukünftige Umstellungen sind eine gute Vorbereitung, Hilfestellungen für beteiligte Personen, eine Kontrolle des Fortschritts und Anpassungen im Prozess wichtig.
3. Änderungen von Prozessen können weitreichende Folgen haben. Neben Irritationen zum neuen Vorgehen entstanden auch ein erhöhter Zeit- und Kostenaufwand für die Stabilisierung der Velocity im Projekt.

Daher gilt immer: Vorsicht bei Änderungen an Teamprozessen!

Referenzen