Scrum
Scrum Prozess: Wertschöpfung und Risikomanagement
Scrum als Risikomanagement: Wie können agile Organisationen einen Scrum Prozess organisieren, ohne dabei die meiste Zeit im Dunkeln zu tappen?
Story Points machen immer Ärger und lösen ständig Diskussionen aus. Nicht nur darüber was sie eigentlich sind oder repräsentieren, sondern auch darüber, wozu sie überhaupt nützlich sind und schließlich darüber, wie sie ermittelt werden.
In der Tat ist die Sache mit den Story Points nicht ganz so trivial, wie sie für viele auf den ersten Blick aussieht. Und genau das erklärt auch die vielen – teils merkwürdigen – Diskussionen, die man in den Communitys so wahrnimmt.
Sie werden überrascht sein, was alles in ihnen steckt.
Grund genug also, ihnen einen eigenen Artikel zu widmen.
Lade dir jetzt den kostenlosen Story Point Calculator im Excel Template, inklusive Anleitung herunter.
Zunächst mal das wozu. Wofür werden Story Points verwendet?
Story Points sind ein Hilfsmittel, um die Velocity von Teams zu bestimmen.
Velocity – auch schon wieder so ein komischer Begriff. Die Geschwindigkeit von Teams, so so. Wie schnell schafft es ein Team, einen bestimmten Scope zu implementieren? Das „wie schnell“ ist erst mal nicht so das Problem. Das sind wir gewohnt in Zeiteinheiten auszudrücken.
Aber was heißt schon Scope? Und wie sollte man diesen objektiv – also vergleichbar – messen?
Hier kommen die Story Points ins Spiel. Aber dazu gleich mehr. Wir bleiben noch einen Moment beim Zweck, nämlich der Bestimmung der Velocity eines Teams.
Wozu und wie, das sind hier die Fragen. Zunächst das wozu.
Alles für die Organisationen
Organisationen haben ein natürliches Interesse, den ökonomischen Impact aller ihrer Aktivitäten im Auge zu behalten. Wenn ein Projekt gestartet wird – idealerweise noch vorher – möchte eine Organisation ganz gerne wissen, was es kosten wird. Time-to-Market sei Dank, wissen sie in der Regel jedoch ziemlich genau wann das Projekt live gehen soll. Bei Kosten und detailliertem Scope existieren in der Regel nur vage Wunschvorstellungen.
Denn unglücklicherweise wird Scrum immer dann als Methodik gewählt, wenn – aus welchen Gründen auch immer (z.B. zu hohe Komplexität der Anforderungen, time-2-market Anforderungen) – eine hinreichende Spezifikation des zu erstellenden Gegenstandes nicht vorliegt, aber die Zeit drängt.
Wenn man den Gegenstand schon nicht kennt, wäre es aber zumindest hilfreich zu wissen, welche Verarbeitungsgeschwindigkeit mein Team hat.
Nichts da also, worauf man jetzt eine valide Schätzung und ein schönes Projekt-Controlling mit hübschen Gantt-Chart und Meilensteinen nebst Ressourcenplanung usw. aufbauen könnte. Organisationen mögen das nicht.
Oder metaphorisch: Wenn ich die Route zu meinem Ziel nicht kenne, wäre es zumindest hilfreich, die Geschwindigkeit des Autos zu kennen, mit dem ich gerade fahre. Ich weiß dann zwar immer noch nicht genau, wann ich ankomme, aber die einzelnen Streckenabschnitte die unmittelbar vor mir liegen, könnte ich schon mal planen. Ich tappe also nicht mehr völlig im Dunkeln und je mehr sich die Gesamtroute erhellt, desto genauer wird meine Planung.
Spätestens nach 20 bis 30 Prozent der Projektlaufzeit sollte sich dieser Umstand einstellen. Ca. 80 Prozent Sicherheit sollte man schon deutlich früher haben: am „Point of no Return“, aber das erörtern wir an einer anderen Stelle.
Den hier beschriebenen Zusammenhang hat die Autoren von SAFe sogar bewogen, normalisierte Story Points zu fordern. Auf diesen Punkt komme ich später noch zu sprechen. Jetzt klären wir überhaupt erst mal die Story Points und ihre Anwendung.
Alles für die Teams
Selbstverständlich haben auch Scrum Teams ein hohes Interesse daran zu wissen, ob sie als Team besser werden oder stagnieren, um dann in Retrospektiven geeignete Maßnahmen ergreifen zu können.
Auch das ist ein nicht zu unterschätzender Umstand, dem wir hier noch etwas Aufmerksamkeit schenken müssen. Denn ich habe jetzt öfter schon die Meinung gelesen, dass die Velocity von stabilen und erfahrenen Teams ohnehin nicht schwankt. Zuletzt auch gerade wieder bei den oben erwähnten Autoren von SAFe aber auch anderswo.
Ich weiß ja nicht in welcher Realität diese Leute so leben, die Realität der Organisationen die ich so berate (Deutsche Bank, Lufthansa, Conrad Electronics, Deutsche Bahn und andere) und auch die unserer eigenen Entwicklerteams war das nicht gerade. In dieser Realität gibt es Projektlaufzeiten von 9 Monaten bis 3 Jahren, dann gibt es neue Projekte mit neuen Teams.
In dieser Realität bestehen Teams nicht nur aus erfahrenen Senior- oder Leadentwicklern, sondern integrieren wenige Seniors mit mehreren Intermediate- und Juniorentwicklern und wir tun viel dafür, dass deren Velocity gerade nicht stabil bleibt.
Und in der Realität ist nicht schon immer alles da und fertig eingerichtet, sondern die Teams kämpfen um ihre CI- und Dev-Umgebungen, Tools und Frameworks. In der Realität müssen sich Entwicklungsteams ständig mit neuen Technologien und Technical Debts auseinandersetzten, sehen neue und manchmal unerfahrene PO‘s und Scrum Master, etc.
Velocity unter solchen Bedingungen ist eher fragil, denn stabil und es ist ein täglicher Kampf, sie hochzuhalten, wenigstens aber stabil oder ideal leicht steigend. Ein Selbstverständnis, welches man einfach mal so voraussetzen kann, ist es jedenfalls nicht.
Wenn das alles so stabil – und keinesfalls in Gefahr – wäre, bräuchte man die meisten Teile der Scrum Methodik übrigens auch gar nicht.
Wer also meint, Story Points wären nur dafür da, um ein Gefühl dafür zu bekommen, was in einen Scrum Sprint passt, um sich dann immer auf die gleiche Anzahl von Story Points zu committen, der könnte sich die Mühe sparen. Dafür gäbe es einen einfacheren Weg. Man könnte als PO das DevTeam vor oder im Planning einfach fragen: „Passen diese drei Stories in den Sprint oder kann ich noch eine mit hinzunehmen?“. Die Antwort wäre nicht weniger präzise.
Wenn wir nun also wissen, welche Rolle Story Points in Scrum oder SAFe spielen, dann wird es nun Zeit, sich an die Definition und Beschreibung zu machen.
Und die hat es leider in sich, auch wenn es auf den ersten Blick so gar nicht danach aussieht. Aber die Mühe wird sich lohnen.
Story Points sind ein Maß für die Komplexität einer Story. Diese in Beziehung gesetzt zum Implementierungsaufwand dieser Story ergibt die Velocity.
Soweit ganz einfach. Was aber genau ist die Komplexität einer Story und wie bestimme ich sie? Da wird die Sache kurz etwas schwieriger – um nicht zu sagen „komplexer“.
Wenn Sie „Komplexität“ googeln bekommen wir schon eine Reihe recht unterschiedlicher Definitionen, die ich hier aus naheliegenden Gründen nicht alle zitieren und diskutieren möchte. Zwei erschienen mir für unsere Zwecke hier kurz und sinnvoll:
oder
„Der Informationsgehalt von Daten“
Letztere könnte man streng philosophisch genommen wohl auch umgekehrt definieren. Denn Daten aggregieren sich zu Informationen und enthalten sie nicht, aber das ist eine andere, etwas spitzfindige Diskussion.
Wenn Teams nun aber die Komplexität einer Story schätzen, dann haben sie ganz natürlich und in Ermangelung anderer objektiver Kriterien lediglich den Aufwand im Kopf, den sie für die Implementierung brauchen. Dieser lässt sich leichter Bestimmen und ist auch irgendwie naheliegend.
Auch wenn das Verfahren nicht ganz falsch ist – wie ich
später noch zeige – tappen die Teams damit in eine böse Falle.
Da der Aufwand individuell ist, überträgt sich automatisch diese Eigenschaft dann auch auf die Komplexität.
Und wenn wir zurück nach oben schauen, wozu Story Points verwendet werden – nämlich für die Velocity – dann wird die Falle schnell sichtbar: Es wird praktisch Zeit mit Zeit verglichen und das führt natürlich zu nichts.
Denn wenn die Velocity Komplexität in Beziehung zum Aufwand setzt, kann ich die Komplexität NICHT mit Aufwand beschreiben, weil ich sonst Aufwand mit Aufwand in Beziehung setze, also Zeit mit Zeit vergleiche.
Sehr ungünstig.
Zudem ist Komplexität eine Eigenschaft der Story. Aufwand wiederum deutet eher auf eine Eigenschaft des DevTeams.
So kommen wir aber nicht weiter. Die Situation ist verzwickt, denn es steht uns kein objetives Kriterium für die Bestimmung von Komplexität zur Verfügung. Jedenfalls keines, welches sich einigermaßen praktikabel und mit überschaubarem Aufwand aus einer Story ableiten ließe.
Die Lösung ist ein Workaround über die „Relativitätstheorie“. Das wiederum klingt kompliziert, ist aber einfacher. Und so gehts:
Sie sind damit weder ganz Komplexität (zu schwierig zu bestimmen), noch ganz Aufwand (wir wollen ja nicht Zeit mit Zeit vergleichen), sondern irgendwas dazwischen.
Denn Teams starten immer unter sehr schwierigen Bedingungen. Neues Team, keine Spezifikation, neues Thema, unerfahrener Product Owner, neue Technologie, es gibt so viele Gründe, alle ungemütlich.
Die Velocity ist am Anfang eines Projektes natürlich sehr niedrig. Das müssen die Teams möglichst schnell aufholen.
Die Stakeholder dürfen in dieser frühen Phase nicht zu schnell nervös werden und ins Micromanagement einschwenken (ein sehr verbreiteter Managementfehler).
Das Besserwerden muss also faktisch institutionalisiert werden. Und dafür brauchen wir zwei Dinge:
Ein Forum, das genau ist der Sinn der Sprint Retrospektive, das am meisten unterschätzte Meeting. Und einen Maßstab, der uns anzeigt, ob die Velocity steigt, sinkt oder konstant bleibt, damit wir in der Retrospektive geeignete Maßnahmen ergreifen können deren Effekt sich beobachten lässt: die Velocity, generiert aus den Story Points und in Beziehung gesetzt zum tatsächlichen Implementierungsaufwand.
Es ist nicht ganz trivial, aber doch die einzige Chance, einigermaßen genau zu bestimmen, wo das Team so steht.
Natürlich veranstalten wir den ganzen Zirkus nur deshalb, weil ein objektives Verfahren mit guten Kriterien zur Bestimmung der Komplexität nicht da ist. Mit so einem Verfahren wären allerdings Teams auch sofort miteinander vergleichbar.
SAFe möchte das gerne, daher auch die Forderung nach normalisierten Story Points. Scrum wollte das eigentlich nie. Beide haben gute und nachvollziehbare Gründe für ihre Position.
Alle, die sich schon mal mit „agile Contracting“ beschäftigt haben, werden die SAFe Position sicher verstehen. Scrum Puristen werden es aber nicht mögen, denn Competition ist kein guter Motivator.
Finden Sie Ihre eigene Wahrheit.
Mit diesem Excel Template kannst du Story Points ganz leicht, mit nur wenigen Klicks berechnen.
Scrum als Risikomanagement: Wie können agile Organisationen einen Scrum Prozess organisieren, ohne dabei die meiste Zeit im Dunkeln zu tappen?
Wofür stehen die 4 C’s in Scrum? Warum es die Scrum Rituale und Rollen überhaupt gibt bzw. warum sie zwangsläufig erforderlich sind, um erfolgreich zu sein.
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.
