In der dynamischen Landschaft der Softwareentwicklung, insbesondere im agilen Umfeld, bleibt die präzise Einschätzung von Aufgaben eine zentrale Herausforderung. Traditionelle Methoden der absoluten Schätzung, basierend auf Zeiteinheiten wie Stunden, Tagen oder Wochen, stoßen dabei oft an ihre Grenzen. Die agile Community hat deshalb alternative Ansätze entwickelt, in denen die relative Schätzung eine zentrale Rolle spielt. Story Points sind hier ein entscheidendes Instrument. In diesem Artikel analysieren wir die Vor- und Nachteile verschiedener Schätzmethoden, beleuchten detailliert die Bedeutung von Story Points und zeigen typische Fallstricke auf.
Warum schätzen wir überhaupt?
Bevor wir uns in die Debatte über relative versus absolute Schätzung vertiefen, wollen wir verstehen, warum die Schätzung in der agilen Software-Entwicklung eine so entscheidende Rolle spielt:
- Priorisierung: Schätzungen helfen Teams zu entscheiden, welche Aufgaben oder User Stories zuerst angegangen werden sollten. Sie ermöglichen es den Stakeholdern, fundierte Entscheidungen darüber zu treffen, welche Funktionen innerhalb eines bestimmten Zeitrahmens realisierbar sind oder welche Funktionen ein gutes „Preis-Leistungs-Verhältnis“ haben.
- Vorhersagbarkeit: Schätzungen bieten eine Grundlage für die Vorhersage von Projekplänen und Release-Terminen. Sie geben den Stakeholdern ein Gefühl dafür, wann sie mit einem funktionierenden Produkt(-teil) rechnen können.
Bei der Schätzung gibt es zwei Hauptansätze: relative und absolute Schätzung.
Absolute Schätzung: Präzision als trügerische Sicherheit
Die absolute Schätzung versucht, den Aufwand einer Aufgabe in konkreten Zeiteinheiten zu quantifizieren. Auf den ersten Blick wirkt dieser Ansatz vertraut und nachvollziehbar. Allerdings birgt er eine Reihe von Schwachstellen:
- Individuelle Unterschiede: Es spielt eine entscheidende Rolle, ob eine unerfahrene oder erfahrene Person die Aufgabe bearbeitet. Wechselt die bearbeitende Person, müssen auch die Schätzungen unter Umständen angepasst werden.
- Unsicherheit und Komplexität: Komplexe Aufgaben sind von Natur aus schwer vorherzusagen. Unvorhergesehene Probleme und Abhängigkeiten können den tatsächlichen Aufwand erheblich beeinflussen.
- Druck und Fehlinterpretation: Absolute Schätzungen können Druck erzeugen, wenn sie als verbindliche Zusagen interpretiert werden. Dies kann dazu führen, dass Teams unrealistische Zeitpläne aufstellen oder Abstriche bei der Qualität machen.
- Der menschliche Faktor: Es gibt Situationen, in denen Stundenschätzungen gut funktionieren, insbesondere in klaren Kontexten mit wiederholbaren Aufgabenstellungen. In solchen Fällen spricht nichts dagegen, in Stunden zu schätzen. Wird die Aufgabenstellung jedoch komplexer, wird es zunehmend schwerer bis unmöglich, eine absolute Fertigstellungszeit in Tagen oder Wochen anzugeben. Aber warum ist das so?
Der Mensch ist evolutionsbedingt gut darin, relativ zu schätzen und zu vergleichen, und weniger gut darin, etwas absolut zu schätzen. Diese Tendenz beeinflusst auch Deine Fähigkeit, Aufwände für Aufgaben einzuschätzen. Hier sind einige Beispiele, die den Unterschied zwischen relativer und absoluter Schätzung verdeutlichen: - Beispiel: Ich gebe Dir zwei Bücher zum Lesen. Ein kleines Buch und ein schweres, dickes.
- Absolut: Sage mir für jedes der zwei Bücher, wie lange Du in Stunden und Minuten brauchst, sie zu lesen.
- Relativ: Du vergleichst die zwei Bücher. Für welches benötigst Du mehr Zeit? Kannst Du mir auch sagen, wie viel länger? Doppelt so lange?
Dieses Beispiel zeigt, dass es für Dich einfacher ist, Vergleiche anzustellen und relative Größen zu bestimmen, als exakte, absolute Werte zu schätzen. Diese menschliche Tendenz spielt auch beim agilen Schätzen eine Rolle.
Relative Schätzung: Der Fokus auf die relative Größe
Im Gegensatz zur absoluten Schätzung konzentriert sich die relative Schätzung auf den Vergleich von Aufgaben untereinander. Hierbei wird der Aufwand einer Aufgabe nicht in Zeiteinheiten, sondern in relativen Größenordnungen ausgedrückt. Story Points sind die gängigste Methode für diese Art der Schätzung.
Story Points: Mehr als nur Zahlen
Team: “Was fließt alles in unsere Schätzung ein? Komplexität? Aufwand? Risiko?” Scrum Master: “Ja.”
Story Points geben uns keinen direkten Aufschluss über die benötigte Zeit zur Umsetzung, sie verfolgen einen anderen Ansatz: Story Points dienen als Maßeinheit für die relative Bewertung des Gesamtauwands, der für die Fertigstellung eines Product Backlog Items anfällt. Dabei berücksichtigen Story Points sämtliche Faktoren, die den gesamten Arbeitsaufwand beeinflussen können, um ein Product Backlog Item in den Zustand „fertig/done“ zu bringen:
- Komplexität/Kommunikationsaufwand: Erfordert die Aufgabe intensives Nachdenken oder umfangreiche Kommunikation mit anderen Abteilungen, Stakeholdern oder Fachleuten? Müssen wir uns erst an eine Lösung herantasten („Trial and Error“)? Ist die Validierung der Ergebnisse aufwändig? Etc.
- Unsicherheit/Risiko: Sind die Anforderungen klar definiert? Müssen bestehende Code-Bestände angepasst werden, für die keine automatisierten Testverfahren existieren? Haben wir den Code im Griff oder muss viel nachgetestet werden, um sicherzustellen, dass wir nichts verschlimmbessert haben? Ist das Team mit den verwendeten Technologien vertraut oder betreten wir Neuland?
- Arbeitsvolumen/Umfang/Größe: Welche tatsächliche Arbeit ist erforderlich, um dieses Product Backlog Item zu realisieren? Auch wenn die Arbeit nicht komplex ist, kann sie langwierig sein. Welche Programmieraufgaben sind durchzuführen, welche Tests sind zu entwickeln, ist ein UI-Design erforderlich, sind Code-Integrationen und Dokumentationen notwendig?
Story Points sind eine Maßeinheit für die relative Größe und vereinen alle oben genannten Punkte. Sie dienen dazu, ein gemeinsames Verständnis im Team zu schaffen und die Planung und Priorisierung von Aufgaben zu erleichtern.
Story Points als Abwandlung der Fibonacci-Reihe
Eine angepasste Fibonacci-Reihe (1, 2, 3, 5, 8, 13, 20, 40, 100) hat sich als besonders geeignet für die Vergabe von Story Points erwiesen. Sie spiegelt die zunehmende Unsicherheit bei größeren Aufgaben wider. Der Unterschied zwischen 1 und 2 Story Points ist gering, während der Unterschied zwischen 13 und 20 deutlich größer ist. Dies hilft Teams, sich auf die relative Größe von Aufgaben zu konzentrieren, anstatt sich in Details zu verlieren.
Praxistipp: Um zu starten, benötigt ihr lediglich eine Referenz-Story, die einen Wert von 2 Story Points hat. Alle weiteren Stories und Product Backlog Items werden relativ zu dieser Referenz-Story geschätzt.
Velocity und Forecasting
Die Velocity ist die durchschnittliche Anzahl von Story Points, die ein Team in einem Sprint abschließt.
Beispiel:
Abgeschlossene (done) Product Backlog Items und deren Story Points pro Sprint:
- Sprint 1: 2+3+5+2+2 = 14
- Sprint 2: 3+5+5+2 = 15
- Sprint 3: 8
- Sprint 4: 5+3+3+3+3+2+2 = 21
(/) Velocity = (14+15+8+21) / 4 Sprints = 14,5
In unserem Beispiel hat das Team in Sprint 3 acht Story Points umgesetzt und eine weitere Story begonnen, diese aber nicht beendet. Die angefangene Story wurde im nächsten Sprint fertiggestellt. Da die Velocity den Durchschnitt über ein paar Sprints berechnet, gleichen sich solche Szenarien aus. Ebenso urlaubsstärkere Zeiten im Sommer oder Weihnachten. Verschwendet keine Zeit damit, Story Points zu splitten und lange darüber zu diskutieren, ob von einer 8er Story jetzt 3 Punkte im alten und 5 Punkte in den neuen Sprint wandern. Die Velocity ändert sich dadurch nicht.
Sie dient als Grundlage für das Forecasting, also die Vorhersage, wie viele Aufgaben in zukünftigen Sprints abgeschlossen werden können. Dies ermöglicht es Teams, Zeitpläne zu erstellen und den Fortschritt transparent zu kommunizieren.
Achtung! Der Forecast basiert auf einer Schätzung. Wie beim Wetterbericht wird der Forecast genauer, je kleiner der Zeitraum ist, den wir betrachten. Eine Aussage über den Fertigstellungsgrad in vier Monaten in der Zukunft ist möglich, aber eben ungenau. 🌞 🌤️ 🌥️ 🌦️
Einsatzbereiche von Story Points
Story Points sind ein vielseitiges Werkzeug, das in verschiedenen Bereichen des agilen Projektmanagements eingesetzt werden kann:
- Kommunikation: Story Points fördern die Kommunikation und Zusammenarbeit im Team, da sie eine gemeinsame Sprache für die Schätzung und Größe von Aufgaben schaffen.
- Team Collaboration: Relative Schätzung fördert die Zusammenarbeit zwischen Teammitgliedern. Durch die Diskussion und Debatte über die relative Größe von User Stories erhält jeder ein gemeinsames Verständnis der anstehenden Arbeit. Wenn jemand zum Beispiel eine Story mit zwei Story Points schätzt und der Kollege mit acht Story Points, entsteht eine wertvolle Diskussion darüber, was der eine eventuell übersehen oder der andere zu kompliziert eingeordnet hat.
- Größe von Product Backlog Items: Es hat sich bewährt, keine Story, die größer als die halbe Velocity ist, in den Sprint zu nehmen. Typischerweise ist die Story zu groß und sollte in kleinere Stories aufgeteilt werden. Zu große Stories haben das Potenzial, den Sprint zu sprengen, da sie zu viel Unsicherheit bergen. Hat das Team z.B. eine durchschnittliche Velocity von 20, müsste man eine 13er Story nochmal teilen.
- Priorisierung: Story Points helfen bei der Priorisierung von Aufgaben, indem sie den relativen Wert und Aufwand berücksichtigen. Liefert eine Story relativ wenig Wert für den Kunden, wird vom Team aber hoch geschätzt, investiert man vielleicht lieber in Stories mit einem umgekehrten Verhältnis (großer Wert und geringe Schätzung).
- Fortschrittsmessung/Releaseplanung: Die Velocity gibt Auskunft über den Fortschritt des Teams und ermöglicht es, frühzeitig Engpässe in einer Release zu erkennen.
- Adaptability: In der agilen Welt sind Änderungen unvermeidlich. Relative Schätzungen bieten Flexibilität, wenn neue Informationen auftauchen. Teams können Schätzungen leicht anpassen, wenn sie mehr über die Arbeit erfahren.
Einbeziehung des gesamten Teams in die Schätzung
Die Einbeziehung des gesamten Teams in den Schätzungsprozess ist von entscheidender Bedeutung. Das Team als Einheit, bestehend aus Mitgliedern mit unterschiedlichem Erfahrungsstand, trifft die Entscheidung. Die Schätzung steht daher nicht in direktem Zusammenhang mit den Kompetenzen oder der Erfahrung einer einzelnen Person, die an einem Teil des Product Backlog Items arbeitet. Das bietet folgende Vorteile:
- Vielfältige Perspektiven: Jedes Teammitglied bringt einzigartige Einsichten und Erfahrungen ein. Die Einbeziehung aller stellt sicher, dass diese vielfältigen Perspektiven bei der Schätzung berücksichtigt werden, was zu genaueren und abgerundeten Schätzungen führt.
- Gemeinsames Verständnis: Gemeinsames Schätzen fördert ein gemeinsames Verständnis der Arbeit. Teammitglieder können Fragen stellen, Zweifel klären und Erwartungen angleichen, wodurch das Risiko von Missverständnissen und Fehlkommunikation verringert wird.
- Verpflichtung: Wenn das gesamte Team an der Schätzung teilnimmt, fühlen sie ein Gefühl der Eigenverantwortung und Verpflichtung gegenüber der Arbeit. Diese Verpflichtung führt oft zu höherer Verantwortlichkeit und Motivation.
Warum relative Schätzung in komplexen Umgebungen glänzt
In komplexen Softwareentwicklungsprojekten, die durch hohe Unsicherheit und sich häufig ändernde Anforderungen gekennzeichnet sind, bietet die relative Schätzung wesentliche Vorteile gegenüber der absoluten Schätzung:
- Fokus auf Genauigkeit (accuracy) statt trügerischer Präzision (precision):
- Komplexe Projekte sind inhärent mit Unsicherheiten behaftet. Absolute Schätzungen, wie beispielsweise in Stunden oder Tagen, suggerieren eine Genauigkeit, die in solchen Umgebungen nicht gegeben ist.
- Relative Schätzung hingegen erkennt diese Unsicherheit an und konzentriert sich auf die Einschätzung der relativen Komplexität und des relativen Aufwands von Aufgaben. Dieser Fokus auf relative Verhältnisse führt zu realistischeren und damit genaueren Einschätzungen, da die Illusion einer exakten Vorhersage vermieden wird.
- Erhöhte Anpassungsfähigkeit an Veränderungen:
- Komplexe Projekte sind typischerweise durch Änderungen im Projektumfang und in den Anforderungen gekennzeichnet.
- Relative Schätzung ist in solchen Situationen anpassungsfähiger, da sie auf Vergleichen zwischen Aufgaben und nicht auf fixen Zeitwerten basiert. Wenn Änderungen auftreten, können Teams die Schätzungen leichter und schneller an die neuen Gegebenheiten anpassen, ohne dass eine komplette Neubewertung aller Aufgaben erforderlich ist.
Exkurs: Warum Story Points im Scrum Guide nicht vorkommen
Es ist bemerkenswert, dass der offiezielle Scrum Guide den Begriff ’schätzen‘ in der Version 2020 nicht einmal enthält und stattdessen die Formulierung ‘size’ (‚Größe‘) oder Beschreibungen der Planungs- und Ordnungsarbeit des Scrum Teams verwendet. Dahinter verbergen sich mehrere wesentliche Überlegungen:
- Förderung der Selbstorganisation: Der Scrum Guide legt großen Wert auf die Selbstorganisation der Scrum Teams. Dies bedeutet, dass die Teams die Freiheit haben sollen, ihre Arbeitsweise selbst zu gestalten. Die Nutzung des neutralen Begriffs ‚Größe‘ gibt den Teams mehr Spielraum bei der Wahl ihrer bevorzugten Methoden zur Einschätzung des Arbeitsaufwands.
- Vermeidung von trügerischer Präzision: ‚Schätzen‘ kann den Eindruck erwecken, dass es eine absolut genaue, vorherbestimmte Antwort gibt. In der komplexen Welt der Softwareentwicklung, in der sich Anforderungen und Umstände laufend ändern, ist dies oft nicht der Fall. Die Verwendung von ‚Größe‘ lenkt den Fokus auf die relative Bewertung des Arbeitsaufwands.
- Flexibilität des Frameworks: Der Scrum Guide ist bewusst allgemein gehalten, um in verschiedenen Branchen und Kontexten anwendbar zu sein. Die Vermeidung spezifischer Terminologie wie ’schätzen‘ ermöglicht es den Teams, das Framework an ihre individuellen Bedürfnisse anzupassen und ihre eigenen Schätzmethoden auszuwählen.
Achtung! Vermeidet die missbräuchliche Verwendung von Story Points
Story Points sind ein mächtiges Werkzeug, aber sie können, wie jedes Werkzeug, missbraucht werden.
Ein häufiger Fehler ist der direkte Leistungsvergleich zwischen Teams basierend auf ihrer Velocity. Da jedes Team seine eigene ‚Story-Point-Baseline‘ hat, sind solche Vergleiche irreführend und demotivierend. Ebenso kontraproduktiv ist der Versuch, Story Points in Zeiteinheiten umzurechnen: ‚Ein Story Point entspricht X Stunden‘ ist eine gefährliche Vereinfachung, die zu falschen Annahmen und unnötigem Druck führt.
Da Story Points kein lineares Verhältnis zur Zeit aufweisen, ist eine direkte Umrechnung in Stunden unmöglich. Der Versuch, eine solche Umrechnung vorzunehmen, führt zu einer falschen Annahme von Präzision.
Und nicht zuletzt: Werden Unsicherheiten und Risiken bei der Vergabe von Story Points ignoriert, werden Story Points zum Risiko. Story Points als starre Zusagen für Liefertermine zu behandeln, ignoriert die inhärente Unsicherheit in komplexen Softwareprojekten.
Fazit:
Die Welt der agilen Softwareentwicklung verlangt nach flexiblen und anpassungsfähigen Schätzmethoden. Wie dieser Artikel zeigt, haben sich Story Points als wirkungsvolles Instrument etabliert, um die relative Größe von Aufgaben zu bewerten und die Zusammenarbeit im Team zu fördern. Sie ermöglichen eine realistische Planung und Priorisierung, indem sie Komplexität, Unsicherheit und Arbeitsvolumen berücksichtigen. Doch wie bei jedem Werkzeug ist der richtige Umgang entscheidend. Die missbräuchliche Verwendung von Story Points, insbesondere der Versuch, sie in Zeiteinheiten umzurechnen, führt zu trügerischer Präzision und unnötigem Druck. Stattdessen sollten Teams die relative Schätzung als Mittel zur Förderung von Kommunikation, Transparenz und kontinuierlicher Verbesserung nutzen. Die Einbeziehung des gesamten Teams in den Schätzungsprozess ist dabei unerlässlich, um vielfältige Perspektiven zu berücksichtigen und ein gemeinsames Verständnis zu schaffen. Story Points sind somit mehr als nur Zahlen; sie sind ein Mittel zur Förderung einer agilen Kultur, die auf Flexibilität, Zusammenarbeit und kontinuierlichem Lernen basiert.
Wir unterstützen euch gerne
Als Agile Coaches bieten wir Unterstützung bei der Einführung und Anwendung von Story Points und anderen agilen Schätzmethoden. Perfekt geeignet ist unsere Agile Estimating and Planning Session. Kontaktiere uns für ein unverbindliches Beratungsgespräch, um mehr zu erfahren.
Das könnte dich auch interessieren:
Agile Coaching: Startschuss für eine zukunftssichere Karriere
In diesem Beitrag möchten wir dir einen Überblick geben, was ein Agile Coach genau macht, welche Fähigkeiten du als Agile Coach mitbringen solltest und wie du selbst diesen spannenden Karriereweg einschlagen kannst. Wir zeigen dir, warum Agile Coaching immer gefragter wird und wie du mit dieser Rolle nicht nur Teams, sondern auch deine eigene berufliche Zukunft voranbringen kannst.
Scrum Beratung: Warum externe Expertise den Unterschied macht
Unternehmen und auch einzelne Abteilungen sehen sich in der heutigen schnelllebigen Geschäftswelt der Herausforderung gegenüber, flexibel und effizient auf Veränderungen zu reagieren. Genau hier setzt eine Scrum Beratung an. Durch die Einführung agiler Methoden können Unternehmen oder IT-Abteilungen ihre Prozesse optimieren, die Zusammenarbeit im Team verbessern und ihre Projekte erfolgreicher umsetzen.
Teamnamen und was sie über die Agilität deines Teams aussagen
Nenne mir Deinen Teamnamen und ich sage Dir, wie agil ihr seid! Ist Dir schon mal aufgefallen, dass manche Teams Namen haben, die klingen, als wären sie direkt aus einem Superhelden-Comic entsprungen, während andere bei „Dev Team“ bleiben? In diesem Beitrag werfen wir gemeinsam einen augenzwinkernden Blick darauf, was Teamnamen über den Zusammenhalt eures Teams aussagt.
