Scoping

Ein Artikel über das Scoping in der agilen Softwareentwicklung. Von der Story zum Aufwand.

Die Kapazität bestimmt die tägliche Arbeit der einzelnen Teams. „Was können wir tun? Wie viel können wir schaffen? Werden wir es rechtzeitig schaffen?“ Eine vernünftige Kapazitätsplanung (Scoping) ist wichtig – ohne einen guten Umfang wird Ihr Projekt das Budget, die Zeit oder beides sprengen. Und niemand mag einen unmöglichen Fertigstellungstermin. Das Problem ist, dass kein Termin unmöglich erscheint, wenn er zum ersten Mal festgelegt wird. „Das kriegen wir schon hin“ habe ich bei vielen Teams, mit denen ich zusammengearbeitet habe, erstaunlich oft gehört. Allzu oft war dies jedoch nicht mehr als eine Hoffnung.

Dieser Artikel für Ihre tägliche Arbeit relevant. Ich gehe auf keine Methoden wie Scrum, Lean oder XP ein. Solange Sie einen iterativen Prozess verwenden, sind die bekannten Methoden Nebensache. Außerdem berücksichtige ich in diesem Artikel weder die Iterationslänge noch die Release-Zyklen – sie sind in der Regel zu projektspezifisch, um sie in einem allgemeinen Artikel wie diesem zu behandeln. Wenn Sie zum Beispiel Scrum verwenden, können Ihre Sprints so lang oder so kurz sein, wie Sie wollen.

Ich zeige Ihnen jedoch, wie Sie die richtige Anzahl von Planungselementen (z. B. User Stories oder Aufgaben) in das Backlog Ihrer aktuellen Iteration einfügen und demonstriere drei Arten der Kapazitätsplanung: Zeitschätzungen, Story-Points und Reverse-Scoping. Dieser Artikel gibt Ihnen auch einen guten Überblick über die Unzulänglichkeiten der beiden Arten von numerischen Schätzungen – Zeitschätzungen und Story-Points -, die nach wie vor die beliebtesten Methoden des Scopings sind. Außerdem erhalten Sie eine Reihe von Vorschlägen, wie Sie Ihre Kapazitätsplanung mit alternativen Methoden verbessern können. Lesen Sie weiter, um herauszufinden, welche Methode am effektivsten ist und wann.

Verwenden Sie keine numerischen Schätzungen zur Bestimmung des Umfangs

Es gibt zwei Arten von numerischen Schätzungen, die ich hier erörtern möchte:

1. Zeitbasierte Schätzungen
2. Story-Points

Zeitbasierte Schätzungen

Beginnen wir mit Zeitschätzungen – viele Projektmanager, die ich kenne, mich eingeschlossen, begannen ihre Laufbahn in der Softwareentwicklung in dem Glauben, dass diese spezielle Schätzmethode die einzige Wahl sei. In einigen Projekten mag sie ihren Zweck erfüllen, aber ich stelle einige Mängel fest. Hier ist ein Beispiel. Wenn ein Projektleiter fragt: „Wie lange wird es dauern?“, denkt ein Entwickler eine Weile darüber nach und antwortet: „Ich denke, vier Stunden oder so.“ Das war’s. Wir können zum nächsten Punkt auf der Tagesordnung übergehen. Diese Methode beruht also auf bloßen Vermutungen, die manchmal weit von der Realität entfernt sind, was man aber erst hinterher herausfindet. Bei ähnlichen Aufgaben, die regelmäßig anfallen, kennt man die vorgeschlagene Zeit und das Problem wird weniger lästig

Ein Manager, der Zeitschätzungen verwendet, wird oft versucht sein, ein Gantt-Diagramm zu verwenden, eine Art Balkendiagramm, das einen Projektzeitplan veranschaulicht. Gantt-Diagramme veranschaulichen die Start- und Endtermine der End- und Zusammenfassungselemente eines Projekts.

Moderne Gantt-Diagramme zeigen auch die Abhängigkeiten zwischen den einzelnen Aktivitäten auf und geben an, welche Aktivitäten welchen vorausgehen. Das Problem mit Gantt-Diagrammen ist, dass Komplexität und Abhängigkeiten fast immer wie Dominosteine umfallen. Das liegt vor allem daran, dass die Wasserfallmethode in der Welt der agilen Methoden nicht gut funktioniert. Daher würde ich sie nur für gut spezifizierte, kurzlebige Projekte (weniger als sechs Monate) empfehlen, die auf einen stabilen Markt ausgerichtet sind und auf einer bewährten Technologie aufbauen. Sie kann Wunder bewirken, aber nur in einem Umfeld ohne Unbekannte. Ein ziemlicher Wunschtraum, oder?

Mir ist zwar klar, dass Gantt-Diagramme in modernen Projekten immer seltener verwendet werden als früher, aber ich möchte hier dennoch auf die kausalen Abhängigkeiten zwischen den Backlog-Elementen hinweisen, die oft in die Denkweise von Zeitschätzungen eingebaut werden. Das liegt vor allem daran, dass es sich nicht um eine sehr ausgefeilte Methode der Kapazitätsanalyse handelt.

Story-Points

Story-Points sind eine Maßeinheit für die Schätzung des Aufwands, der für die Implementierung eines Product-Backlog-Elements erforderlich ist. Bei der Schätzung mit Story-Points weisen Sie jedem Element einen Punktwert zu, wobei der Wert selbst ein Maß für die Schwierigkeit und nicht für die Zeit ist. Wenn beispielsweise zwei Backlog-Elemente jeweils zwei Story-Punkte erhalten, sind sie ähnlich schwierig zu implementieren. Sie sind auch schwieriger zu implementieren als Elemente mit einem Story Point und weniger schwierig als Elemente mit drei Story Points. Klingt einfach, aber hinter diesen offensichtlichen Fakten verbirgt sich eine wichtige Schlussfolgerung. Während stündliche Zeitschätzungen absolut sind, sind Story Points relativ. Ein auf Story-Points basierendes System, das von einem Team ausgearbeitet wurde, kann für ein anderes bedeutungslos sein.

Geschwindigkeitsaspekte

Die Relativität bringt uns zur Geschwindigkeit, einem äußerst wichtigen Konzept in der Welt der Story Points. Ein weiteres erfundenes, teamspezifisches Maß dafür, wie viel Arbeit das Team leisten kann. Velocity ist die Anzahl der Story Points, die das Team in einer einzigen Version umsetzen kann. Es handelt sich dabei auch um einen Durchschnittswert – wir messen, wie viele Story Points das Team in der ersten Iteration erfolgreich umsetzen konnte, und passen die Zahl dann nach jeder Iteration an, so dass die Zahl im Laufe der Zeit genauer wird. Wenn wir also zum Beispiel ein Teammitglied verlieren, sinkt unsere Geschwindigkeit mit der Zeit. Wenn wir ein zusätzliches Teammitglied gewinnen, erhöht sich die Anschlagsgeschwindigkeit. Die Geschwindigkeit passt sich also automatisch an die Bedingungen an, mit denen das Team konfrontiert ist, was an sich schon eine große Verbesserung gegenüber absoluten Schätzungen darstellt.

Letztendlich habe ich mich aber auch gegen Story-Points entschieden. Leute, die Story-Points verwenden, tun dies in der Regel in Verbindung mit so etwas wie Burn-Down-Diagrammen, also einer grafischen Darstellung der noch zu erledigenden Arbeit im Verhältnis zur Zeit. Der ausstehende Arbeitsrückstand wird in der Regel auf der vertikalen Achse dargestellt, während die Zeit auf der horizontalen Achse verläuft. Da Story-Points relativ und nicht absolut sind und sich Start- oder Enddaten nicht eindeutig ableiten lassen, wird der Fortschritt eher mit Burn-Down-Diagrammen als mit Hilfsmitteln wie dem Gantt-Diagramm verfolgt.

Dennoch sind Burn-down-Diagramme leicht zu manipulieren. Sie sind ähnlich wie Gewinnprognosen und neigen dazu, sich in die Richtung der Träume oder Absichten ihrer Verfasser zu bewegen. Projektmanager, die sie verwenden, sollten sich dieser Gefahr bewusst sein und sie eher als Richtschnur denn als „ideales“ zuverlässiges Diagramm betrachten. Die mathematische Natur der Velocity macht sie zu einem eher schwerfälligen Instrument, auch wenn Tools wie JIRA bei der Berechnung des Ergebnisses helfen. Außerdem funktioniert die Mittelwertbildung nur über längere Zeiträume – jede Änderung der Bedingungen, mit denen Ihr Team gerade konfrontiert ist, wird die Velocity für einige Iterationen destabilisieren.

Reverse Scoping verwenden

Hier ist eine dritte Alternative, die ich Reverse-Scoping heißt, weil sie den üblichen Kapazitätsplanungsprozess umkehrt.

Normalerweise würde ein Planer die Kapazität auf der Grundlage von Schätzungen der Product-Backlog-Items planen. Wenn in einen Sprint zwanzig Story-Punkte passen, sucht das Team nach Backlog-Elementen mit Schätzungen, die sich zu zwanzig Punkten addieren. Zum Beispiel: zwei Elemente mit fünf Story Points; drei Elemente mit drei Story Points; ein Element mit einem Story Point.

Beim Reverse Scoping hingegen müssen Sie Folgendes tun:

Wählen Sie ein Product Backlog Item aus, das Sie erledigen wollen, ohne es zu schätzen;
Sie müssen im Voraus entscheiden, wie viel Zeit oder Geld Sie für die Erledigung aufwenden können;
Entweder Sie kürzen den Umfang oder Sie erweitern ihn je nach Ihrem Budget.
Mit anderen Worten: Sie bekommen, was Sie ausgeben können. Wenn Sie zu viel ausgeben, kürzen Sie den Umfang. Wenn Sie aber zu wenig ausgeben, können Sie neue Komplexitätsebenen hinzufügen, weil Sie noch Ressourcen dafür haben. In jedem Fall ist am Ende der Iteration etwas fertig, aber es gibt kein böses Blut zwischen dem Lieferteam und den Geschäftsinteressenten, denn das einzige Versprechen war eine Version, die das Budget nicht überschreitet. Höhere Budgets bedeuten mehr Qualität oder Komplexität. Niedrigere Budgets bedeuten das Gegenteil.

Sie können entweder Zeit oder Geld budgetieren. Im letzteren Fall beschließen Sie, dass Sie bis zu €XX.XXX für das Projekt ausgeben können, und passen den Umfang im Laufe des Projekts entsprechend der aktuellen Verwendungsrate an. Bei Zeitbudgets legen Sie im Voraus eine Frist fest und passen dann den Projektumfang an, um die Frist einzuhalten.

Geld vs. Zeit

Beim Reverse Scoping auf Geldbasis ist es viel einfacher, Prioritäten zu setzen. Die Entscheidung zwischen den Projekten A und B fällt leicht, wenn Sie wissen, dass Projekt A 5.000 Euro kosten wird, um einen prognostizierten Wert von 6.000 Dollar zu erzielen, und dass Projekt B 7.000 Euro kosten wird, aber 10.000 Euro an Wert einbringt. Dies ist eine äußerst effektive Methode, um den Umfang mit nicht-technischen Interessengruppen zu verhandeln. Nicht-technische Stakeholder verstehen Budgets besser als abstrakte Story Points. Und mit genügend gutem Willen kann jede Zeitschätzung angefochten werden. Budgets hingegen suggerieren Wert. Das ist die wertorientierte Planung.

Das zeitbasierte Reverse-Scoping erkennt an, dass Fristen gut sind. Menschen denken von Natur aus in Fristen. Auch ein Großteil der Geschäftswelt ist terminorientiert. Für viele Unternehmen, die Hardwareprodukte verkaufen, ist beispielsweise die Urlaubssaison ein natürlicher Stichtag. Wenn wir bei der Einhaltung des Termins einen flexiblen Umfang zulassen, kann das Lieferteam eigenständig entscheiden, wo es den Umfang kürzen möchte, und gleichzeitig sicher sein, dass die Interessengruppen des Unternehmens mit dem Ergebnis zufrieden sein werden. Und warum? Weil alles andere entweder zu viel Zeit in Anspruch nehmen würde oder zu teuer wäre. Meiner Erfahrung nach sind Geschäftsinhaber oft frustriert, wenn Teams den Umfang einfrieren. Aber ich habe noch nie erlebt, dass ein Geschäftsmann wütend war, weil er das Budget eingefroren hat. Wenn Sie selbstbewusst sind und die magischen Worte sagen: „Wenn wir den Umfang erweitern, werden wir das Budget überschreiten“, werden sie das normalerweise akzeptieren.

Beginnen wir mit der Planung
Mir persönlich gefällt das Reverse-Scoping am besten, aber ich schlage vor, dass Sie Ihre Scoping-Methode von Zeit zu Zeit ändern, wenn das möglich ist. Und warum? Um die Routine zu durchbrechen. Routine und Annahmen über den Umfang sind die größten Feinde eines jeden Planers.

Wenn Aufgabe A ähnlich aussieht wie Aufgabe B, wird sie eine ähnliche Schätzung hervorbringen; die technische Herausforderung kann jedoch am Ende ganz anders sein, so dass solche Vergleiche in der Regel falsch sind. Ein Team, das bereit ist, Neues zu lernen, wird sich nicht an der Umstellung stören, wenn sie vernünftig und geplant erfolgt. Sie werden die neue Perspektive sogar zu schätzen wissen.