Scrum
Scrum Master: Rolle und Aufgaben
Scrum Master – der Intendant der agilen Kultur. Was sind die Aufgaben eines Scrum Masters? Wie Verhält sich die Scrum Master Rolle in Bezug auf seine Scrum-Team-Kollegen?
Ja, Sie haben richtig gelesen, dieser Artikel bringt eine Weltneuheit. Was wurde nicht schon alles über Story Points geschrieben, kontrovers wurde Bedeutung, Sinn, Nutzen und Verfahren diskutiert.
Aber eine Sache blieb immer unberührt, alle waren sich einig, dass Story Points nur individuell geschätzt werden. Das wird sich heute ändern.
Mit diesem Artikel fügen wir der ganzen Diskussion einen qualitativ absolut neuen Aspekt hinzu:
Das Berechnen von Story Points über einen Algorithmus.
Mit diesem Excel Template kannst du Story Points ganz leicht, mit nur wenigen Klicks berechnen.
Alle, die sich schon intensiv mit Story Points und deren Methoden ihrer Ermittlung beschäftigt haben, werden sich sicher fragen, wie das überhaupt funktionieren soll, denn im Moment der Story Point Schätzung gibt es ja über eine Story oder über ein Epic kaum Daten auf die man einen Algorithmus anwenden könnte.
Und natürlich bewegen wir uns im agilen Umfeld, d.h. Techniken und Methoden, die wir einführen dürfen auf keinen Fall sehr kompliziert oder aufwändig sein.
An dieser Stelle – der Fairness halber – schon mal vorweg, ganz ohne Schätzung werden wir nicht auskommen, um die Daten für den Berechnungsalgorithmus zu bestimmen und es gibt auch ein paar Einschränkungen in der Anwendbarkeit.
Aber in den allermeisten Softwareentwicklungs-Projekten funktioniert die Berechnung verblüffend gut und liefert sehr valide Daten.
Außerdem müssen wir über den Mehrwert für die Teams und für die Organisation einer solchen Berechnung sprechen, denn ohne einen klar erkennbaren Mehrwert, sollten neue Verfahren gar nicht eingeführt werden.
Das war eines der Probleme, das häufig im klassischen Projektmanagement anzutreffen war, dass aus rein statistischen Gründen alles mögliche und mit entsprechendem Aufwand gemessen wurde, ohne dass ein signifikanter Mehrwert für Team oder Projektorganisation überhaupt erkennbar war.
Welchen Mehrwert hätte denn nun eine Story Point-Berechnungsmethode?
Beginnen wir hiermit als Einstimmung in die Beschreibung des Verfahrens selbst. Sollten Sie nach diesem Abschnitt nicht vom Mehrwert eines solchen Verfahrens überzeugt sein, dann sparen Sie etwas Zeit und brauchen nicht weiterlesen.
Story Points machen bislang immer Probleme, daher werden sie auch in den Communities und innerhalb vieler Organisationen so kontrovers diskutiert.
Besonders dann, wenn ein „agile Coach“ in einer skalierten Organisation mit vielen Teams Story Points einführen möchte, regt sich oft Widerstand, der mit allen möglichen Argumenten untermauert wird.
Da Story Points bislang team-individuell und subjektiv sind, können sie von einer skalierten Organisation für Planungen, Prognosen und Szenario-Simulationen nicht verwendet werden.
Auch das Normalisieren von Story Points (z.B. von SAFe vorgeschlagen) ändert daran nicht so viel, wie man gerne hätte.
Oft wird auch die Natur von Story Points nicht verstanden, und sie werden als Maß für den Aufwand missinterpretiert.
Dabei sind Story Points lediglich ein Maß für die Komplexität, aber wer kann schon eine gute Begriffsdefinition für den Begriff „Komplexität“ liefern.
Und auch die müsste organisationsweit gelten, und bei einer solchen Begriffsbestimmung gleiten wir ohnehin ins Philosophische ab.
Und wo wir gerade philosophisch werden, es geht uns bei der Komplexität ein wenig so, wie den Philosophen und eigentlich allen Wissenschaften, die nach der Wahrheit suchen: Wir setzen das voraus, was wir eigentlich beweisen wollen, nämlich, dass es Wahrheit überhaupt gibt.
In unserem Fall wissen wir nicht genau, wie wir Komplexität definieren, aber wir bestimmen sie schon mal. Und das noch durch eine individuelle und subjektive Schätzung.
Klingt nicht gerade nach einer präzisen Wissenschaft und an dieser Stelle kann ich die Kritiker der Story Point Schätzung schon verstehen.
Die Tatsache, dass es bei der Kritik überhaupt noch Story Points gibt, liegt schlicht daran, dass sie für den agilen Prozess sehr wichtig sind.
Es gibt im agilen Prozess ohnehin nicht sehr viel, was nach einer Zahl aussieht und was wir verwenden können, um eine mindestens rudimentäre Planungs- und Controlling- Basis zu schaffen, also Velocity zu messen und darüber ein Gefühl zu bekommen, ob der agile Prozess (noch) gut läuft oder wann eventuell mein MVP released werden kann.
Selbst für das Priorisieren von Aufgaben nach z.B. WSJF (weighted shortest job first) muss ich den Umfang der Aufgabe (job size) irgendwie ermitteln.
Um diese Argumentation hier nicht in die Länge zu ziehen, habe ich alles rund um die Definition und Bedeutung von Story Points in diesem Artikel zusammengefasst:
Hier geht es nicht um die Begründung, warum Story Points wichtig sind, sondern welchen Mehrwert deren Berechnung gegenüber einer individuellen (von Einzelnen vorgenommen) und subjektiven (entsprechend ihrer persönlichen Wahrnehmung) Schätzung hat.
Eine Berechnung hat per se die Eigenschaft, objektiv – also sachlich und neutral – zu sein.
Die Neutralität ist in einem skalierten Umfeld von großer Bedeutung, denn die Werte können teamübergreifend verwendet werden und einer organisationsweiten Verwendung steht nichts im Wege, es findet also eine Normalisierung der Story Points statt.
Btw. an alle Kritiker der Vergleichbarkeit von Teams:
Normalisierte Story Points machen nicht die Teams vergleichbar, sondern nur ihre Aufgaben.
Die Sachlichkeit wiederum sorgt dafür, dass die Neutralität nicht nur vorgegaukelt ist – wie bei der von SAFe vorgeschlagenen Normalisierung, die zwar nicht mehr individuell aber immer noch subjektiv bleibt – sondern konsistent (beständig, nachhaltig) und nachvollziehbar bleibt. Wir können objektiv hier also auch mit „nachhaltig“ und „unabhängig“ beschreiben.
In Summe liefert ein Verfahren zur Berechnung von Story Points der Organisation eine gleichermaßen nachhaltige und unabhängige Bewertung ihrer Aufgaben.
Ich denke, es ist sehr einleuchtend und man muss dafür nicht Ökonomie studiert haben, um zu erkennen, was eine Organisation mit nachhaltig und unabhängig bewerteten Aufgaben in Bezug auf Planung, Commitment, Prognosefähigkeit und Controlling anfangen kann.
Nein, sie mutiert nicht wieder in eine klassische Organisaiton, sondern sie tut genau das, was SAFe (5.1) im Principle #1 formuliert „take an economic view“.
Zunächst mal – und das werden wir später bei der Beschreibung des Verfahrens noch genauer sehen – erhält das Team nicht nur über den berechneten Wert an sich, sondern vor allem durch das Verfahren und die Art, wie das Team in das Verfahren aktiv involviert ist, deutlich mehr Klarheit über die zu bewältigende Aufgabe (die Story, das Feature, das Epic).
Das erleichtert – und ich unterstelle, verkürzt – in vielen Fällen den Planungsprozess für die kommende Iteration (Sprint, PI).
Teams fällt es zudem oft schwer, die Komplexität ihrer Aufgaben Stakeholdern gegenüber zu erklären und manchmal sogar zu rechtfertigen.
Von dieser Bürde wären sie grundsätzlich befreit und können sich ganz auf die Lösung der Aufgabe konzentrieren.
Natürlich verringert eine Berechnung auch die Irrtumswahrscheinlichkeit und trägt dazu bei, dass zwei der wichtigsten agilen Werte, mit denen Teams immer wieder Schwierigkeiten haben, besser unterstützt werden: Flow und Commitment.
Ersteres zahlt auf das KPI „Velocity“ ein, während letzteres durch das KPI „Sprint Accuracy“ repräsentiert wird, zwei der wichtigsten KPI’s für die Performance von Teams oder Development Valuestreams (SAFe).
So, nun zum Verfahren selbst. Und hier übergebe ich an meine Co-Autorin Gergana Petrova, die dieses Verfahren maßgeblich mit entwickelt hat und dafür gesorgt hat, dass diese Berechnungsmethode Bestandteil unseres Produktes scagile geworden ist. Dort können Sie das Verfahren life testen.
Das Verfahren wird von agilen Teams in der Iterations-Planungsphase eingesetzt, wie z.B. Sprint-Planning (Scrum), PI- oder Etappenplanung (z.B. SAFe), oder auch Vorbereitungen dazu (Refinements, Pre-Plannings).
Das Verfahren kann damit sowohl auf Story- wie auf Feature- oder Epic-Ebene angewendet werden.
Entscheidend dabei ist, dass die Berechnung noch immer auf Daten basiert, die vom Team erhoben werden. Bei aller Objektivität der Berechnung, das Resultat bleibt also in der Teamverantwortung.
Da agile Events möglichst kurz, insbesondere aber timeboxed sind, sollte das Verfahren auch nicht viel Zeit in Anspruch nehmen und ohne administrativen Aufwand einzusetzen sein, es muss also schnell, einfach und intuitiv sein.
Als Ergebnis der Berechnung erhalten wir die Anzahl der Story Points. Diese repräsentieren die „job size“, also die Größe der Aufgabe.
Man muss es immer wieder dazusagen, denn es wird gerne missverstanden:
Die Story Points repräsentieren nicht den Aufwand, sondern die job-size, denn Aufwand ist eine Eigenschaft des Teams, während job-size eine Eigenschaft der Aufgabe ist.
Die job-size setzt sich zusammen aus der Komplexität plus dem Umfang der Aufgabe, also gilt die Formel:
JOB SIZE = complexity + amount of work + uncertainty
Zu den beiden Parametern gesellt sich mit der „uncertainty“ noch ein dritter Parameter hinzu. Dieser wird immer dann gesetzt, wenn in der Aufgabe noch Risiken bezüglich eines möglichen Scope-Changes enthalten sind (z.B. „Falls sich herausstellt, dass die Schnittstelle nicht performant genug ist, müssen wir die Daten chachen“).
„Uncertainty“ meint nicht, ob dem Team die Aufgabe klar ist („wir wissen was wir tun sollen, aber nicht wie, denn wir haben das noch nie gemacht“), denn das wäre wieder eine Eigenschaft des Teams und kommt erst bei der Aufwandsschätzung zum Tragen, nicht bei der job-size.
Der Begriff Komplexität macht leider auch immer wieder Probleme, da es dafür auch keine so eindeutige und/oder sofort einleuchtende und auf uns hier übertragbare Definition gibt.
Wie wir gleich sehen werden, macht das aber nichts. Hier sei nur gesagt, dass wir uns auf zwei Definitionen des Begriffs beziehen, die wir sehr passend finden.
Komplexität repräsentiert die Anzahl von Elementen und Verbindungen zwischen ihnen innerhalb eines Systems
Komplexität repräsentiert den Informationsgehalt von Daten
Eine hinreichende Kritik dieser beiden Definitionen würde definitiv den Rahmen dieses Artikels und auch den Rahmen eines ganzen Buches sprengen. Bei dem Entwurf des Algorithmus haben wir uns recht grob von diesen beiden Definitionen – nennen wir es mal – „inspirieren“ lassen.
Mit diesem Excel Template kannst du Story Points ganz leicht, mit nur wenigen Klicks berechnen.
Um die job-size eines Backlog Items (Story, Feature, Epic) zu bestimmen, stellen wir 8 (Version 1) bis 10 (Version 2) Fragen, die vom Team beantwortet werden. Damit es – wie oben beschrieben – schnell geht sind es eben nur diese 8 bis 10 Fragen.
Man könnte hier deutlich mehr Fragen stellen und würde vermutlich noch genauere Werte erzielen. Aber uns kommt es mehr darauf an, dass das Verfahren schnell, einfach und praktikabel bleibt, denn es sollte in jeder Iteration angewendet werden.
Außerdem verwenden die meisten Teams die (angepasste) Fibonacci-Folge und damit die Werte (0,1,2,3,5,8,13,20,40,100). Es soll über den Algorithmus also nur einer der 10 Werte ermittelt werden.
Die Anforderung an den Algorithmus ist also weniger maximale Präzision, sondern eher maximale Konsistenz.
Jede der 8 bis 10 Fragen wird vom Team in nur drei Ausprägungen (kein, wenig, viel bzw. niedrig, mittel, hoch) bewertet.
Der Job Size Calculator ist direkt in die scagile Projektmanagement App integriert.
Unsere empirischen Tests haben gezeigt, dass bei nur drei Ausprägungen die beste Balance zwischen Geschwindigkeit der Schätzung, Genauigkeit und Konsistenz vorliegt.
So kann ein Backlog-Item mit einem Umsetzungsaufwand von mehreren Tagen (Story) bis mehreren Wochen (Feature oder Epic) mit dem Verfahren innerhalb von 1 bis 2 Minuten bewertet werden. Das ist ein durchaus akzeptabler Zeit-Invest.
Die 8 bis 10 Faktoren sind untereinander gewichtet. Die Auswahl der Faktoren, die bewertet werden und auch deren Gewichtung untereinander haben wir in zahllosen Tests mit einer großen Anzahl von Teams aus Entwicklern und Architekten ermittelt.
Die Faktoren und Ihre Gewichtung beziehen sich auf durchschnittliche Software-Entwicklungs-Projekte. Sehr wahrscheinlich können mit genau diesen Faktoren nicht alle Projekte oder Projekttypen abgebildet werden. Hier könnten die Fragen und Gewichtungen entsprechend angepasst werden.
Wir haben inzwischen sogar Marketingprojekte mit einem angepassten Set aus Fragen erfolgreich bewerten können.
Nun zu den Faktoren selbst. Ausgehend der beiden oben genannten Definitionen zur Komplexität, lassen sich die Faktoren, die wir definiert haben, gedanklich in zwei Gruppen aufteilen:
Gruppe 1
Die erste Gruppe sind Faktoren, die Interdependenz, Beziehungen und Zusammenhänge berücksichtigen (Interaktion, die Beziehungen zwischen den Elementen eines System).
Gruppe 2
Die zweite Gruppe beschreibt die Art der Elemente selbst. Auch hier haben wir wieder 4 Dimensionen.
Wie oben beschrieben, bekommt jeder Faktor eine Ausprägung (niedrig, mittel, hoch) und hat eine Gewichtung im Gesamtalgorithmus, der daraus eine Berechnung der StoryPoints vornimmt.
So kompliziert das ganze Verfahren klingt, so einfach und schnell ist seine Anwendung. Der Vorteil in der Anwendung liegt neben einem nachhaltigen und unabhängigen Ergebnis besonders auch in der Tatsache, dass Teams bei der Beantwortung der Fragen sich deutlich mehr Klarheit über den Gegenstand verschaffen und Risiken frühzeitig erkennen.
Schon das alleine führt zu einer verlässlicheren Planung (Team) und Prognosefähigkeit (Organisation).
Mit diesem Excel Template kannst du Story Points ganz leicht, mit nur wenigen Klicks berechnen.
Scrum Master – der Intendant der agilen Kultur. Was sind die Aufgaben eines Scrum Masters? Wie Verhält sich die Scrum Master Rolle in Bezug auf seine Scrum-Team-Kollegen?
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
Was ist die optimale Scrum Sprint Länge? Die überraschende Erkenntnis: 1-wöchige Sprints sind effektiver! Lese hier warum.
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.
