Scrum ist eine agile Methode. Sie beinhaltet auch Planung. Statt ausführlicher und umfangreicher Planung zu Beginn eines Projekts werden das schrittweise Planen sowie die schnelle Abstimmung im Team gesucht. Mit einer Product-Roadmap legt der Product-Owner seine Ziele für das Produkt fest. Im Unterschied zu phasenorientierten Vorgehensweisen ist aber der Planungshorizont für eine detaillierte Planung kleiner. Der Product-Owner plant mit Hilfe seines Product-Backlog mindestens zwei bis drei Sprints im voraus. Das Entwicklungsteam plant seinen nächsten Sprint.

Jede Art der Planung erfordert immer eine Abschätzung der Aufgaben hinsichtlich Komplexität und Machbarkeit im Rahmen des Projektes.

02d-inkrementell-schatzen

Die Entwickler planen und schätzen

Im Planning-Meeting zerlegen Entwickler und Tester jede Story in konkrete Aufgaben, um den Sprint einzuschätzen. Sie machen aus einem komplizierten Problem (Story) ein offensichtliches Problem (Task). Einfache Schätzmethoden wie der “Planning Poker” oder das “Estimation Game” helfen dem Team, die Größe eines Task zu beurteilen.

Das Scrum-Team trifft sich zum Planning Poker und bewertet die einzelnen Stories aus dem Sprint-Backlog. Ziel der Bewertung ist eine Einteilung der Stories in Kategorien, mit denen eine relative Komplexität ausgedrückt wird. Diesen Kategorien teilt man dann die Zahlen der unechten Fibonacci-Reihe zu, da hier die Abstände zwischen den Zahlen immer größer werden. In den meisten Fällen reichen die Werte 0, 1, 2, 3, 5, 8 und 13, für Unentschlossene noch das Fragezeichen, wahlweise als Kartenspiel oder App. Jede Story wird vom Product-Owner vorgestellt und vom Team besprochen. Jedes Teammitglied wählt eine Zahl aus, hält sie aber verdeckt, bis alle bereit sind. Gleichzeitig decken sie die Werte auf. Im besten Fall sind sich alle Teammitglieder einig und zeigen den gleichen Wert. Häufig gibt es aber unterschiedliche Schätzungen. Das erste Teammitglied bewertet beispielsweise einen Story mit drei, das zweite Teammitglied mit zwei und das dritte Teammitglied mit acht. Das Teammitglied mit dem höchsten und niedrigsten Wert verteidigen ihre Einschätzung. In einer sachlichen Diskussion einigt sich das Team auf einen Wert, mit dem jedes Teammitglied einverstanden ist. Dieses Verfahren wird wiederholt, bis der Sprint nach Einschätzung des Teams “voll” ist.

Es wird wie ein Spiel durchgeführt. Die Regeln für das Spiel sind sehr einfach gehalten. Das Team ist komplett vertreten. Der Product Owner ist anwesend. Der Scrum Master moderiert das Meeting. Alle Stories liegen auf einzelnen Karten ausgedruckt und verdeckt auf einem Stapel. Das erste Teammitglied nimmt sich die oberste Karte, liest sie laut vor und hängt sie an eine Wand. Das zweite Teammitglied nimmt die nächste Karte, liest sie laut vor und hängt sie ebenfalls an die Wand. Es gibt drei Möglichkeiten:

  • Die Story ist seiner Meinung nach ähnlich komplex wie die erste Story. Dann hängt er sie neben die bereits an der Wand hängende Story.
  • Die Story ist seiner Meinung nach weniger komplex als die erste Story. Dann hängt er sie unter die bereits an der Wand hängende Story.
  • Die Story ist seiner Meinung nach komplexer als die erste Story. Dann hängt er sie über die bereits an der Wand hängende Story.

In den weiteren Runden hat jedes Teammitglied noch folgende zusätzliche Optionen:

  • Eine bereits hängende Story wird umgehängt, verbunden mit einer (kurzen) Erklärung, ohne Diskussion. Jedes Umhängen einer Story wird mit einem Punkt markiert.
  • Aussetzen

Das Spiel ist beendet, wenn keine Karten mehr auf dem Tisch liegen bzw. alle Teammitglieder aussetzen.

Am Ende des Meetings muss das Team die Sicherheit haben, ein Commitment für das Sprint-Backlog abzugeben. Der Planungshorizont ist das Sprintende.

Der Baustein Case ist zentraler Bestandteil einer Story. Im Abschnitt Ausgangslage wird das zu lösende Problem beschrieben. Mit den Essenzschritten wird die Lösung skizziert. Die Kommentarfunktion des Wiki verwendet das Team, um wichtige Annahmen und Vermutungen aus den Diskussionen für alle transparent festzuhalten. Die Kommentare werden am Ende eines erfolgreichen Sprints gelöscht. Werden die Ziele nicht erreicht, sind die Kommentare möglicherweise hilfreich, um das Problem zu lösen. Zumindest verhindern die Kommentare, dass die gleichen offensichtlich falschen Annahmen für den nächsten Sprint getroffen werden.

Das gleiche gilt auch für die Bausteine Service, Event und Entity, die in den Essenzschritten der Lösung erwähnt werden. Die Bausteine nutzt das Team als weitere Grundlage für ihre Schätzung. Die Bausteine sind ein Maß für die Komplexität der technischen Lösung. Je mehr Services oder Events in einer Lösung verändert werden, desto mehr muss das Team auf die Akzeptanzkriterien (z.B. Testabdeckung, Automatisierung von Test und Deployment, Dokumentation) achten bei ihrem Commitment.

Der Product-Owner plant

Der Product-Owner ist verantwortlich für den Erfolg des Produktes, inhaltlich und wirtschaftlich. Er muss dafür sorgen, dass das Team immer mit den für das Produkt wichtigsten Stories aus dem Product-Backlog beschäftigt ist. Der Product-Owner hat einen Planungshorizont, der über die Dauer von mindestestens zwei bis drei Sprints geht.

Das Team (bzw. einzelne Mitglieder) und der Product-Owner nutzen ein Refinement-Meeting, um zukünftige Stories aus dem Product-Backlog zu schätzen. Jede dieser Stories hat eine hohe Priorität beim Product-Owner und besitzt einen ausreichenden Reifegrad. Die Story bezieht sich auf einen Case mit einer Beschreibung der Ausgangslage, was vor allem wichtig für ein gemeinsames Verständnis im Team ist. Hilfreich sind auch konkrete Beispiele oder in Prosa formulierte Testfälle, die der Product-Owner bei der Anforderungsanalyse berücksichtigt hat. Die Lösung im Case kann jedoch offen sein und wird gemeinsam im Refinement-Meeting erarbeitet.

Geschätzt wird nicht der Aufwand, sondern die Komplexität einer Story. Das Schätzverfahren “Magic Estimation” wird eingesetzt, weil wir viele Stories aus zeitlichen Gründen schnell schätzen wollen.

Alle Stories werden als Karten ausgedruckt und auf einem Tisch aufgelegt. Das komplette Team hat 10 Minuten Zeit, die Karten in einer Reihenfolge zu platzieren. Jedes Teammitglied nimmt eine Karte und schätzt die Komplexität aus seiner Sicht mit einer Fibonacci-Zahl. Auf diese Art werden alle Karten geschätzt und am Tisch nach den Zahlen gruppiert. Während dieser Zeit gibt es keine Diskussionen untereinander und es findet auch kein Austausch der Karten statt. In allen weiteren Runden hat jedes Teammitglied das Recht, eine von einem anderen gelegte Karte zu einer anderen Zahl am Tisch zu legen. Eine Veränderung der Einschätzung wird auf der Karte vermerkt. Folgende Erkenntnisse gewinnen wir durch diese Methode:

  • Karten, die nicht umgelegt wurden, hat offensichtlich jedes Teammitglied verstanden und gleich eingeschätzt.
  • Karten, deren Wert in jeder Runde verändert wurde, müssen noch einmal intensiv besprochen werden.
  • Karten, die niemand schätzen könnte, müssen geklärt werden.

Wichtig ist hier jedoch, dass auf jeden Fall später noch einmal eine genauere Schätzung durchgeführt wird, um dann hinsichtlich des tatsächlichen Zeitaufwands genauer zu werden.

Diese Einschätzung der Komplexität versetzt den Product-Owner in die Lage, einen groben Plan für die kommenden Sprints zu entwickeln.

Die Bausteine Epic und Case sind zentrale Bestandteile des Product-Backlog. Sie enthalten das Wissen über das Produkt. Jede Story ist mit einem Case verknüpft. Das Epic dient der Strukturierung von Backlog und Systembeschreibung.

Der Product-Owner schätzt

Abhängig vom Unternehmen und der Größe des Projektes muss ein Product-Owner eine langfristige Planung machen, um die finanziellen Mittel für das Projekt zu bekommen. Der Planungshorizont kann ein Jahr oder länger sein. Mit einer Product-Roadmap kann ein Product-Owner die großen Ziele darstellen, die er mit dem Produkt verfolgt. Häufig muss er so eine Roadmap mit Zahlen hinterlegen. Dafür nutzt der Product-Owner Expertenschätzungen mit Verfahren mit Namen wie “Function Point” oder “Use Case Point“. Alle diese Schätzverfahren gleichen sich in einem Punkt: Die “Größe” eines Systems wird durch eine einheitenlose Punktezahl gemessen.

Die Methode von Stephan Frohnhoff ist ein moderner Lösungsansatz für eine anwendungsfallbezogene Aufwandsschätzung für komplexe Software-Produkte. Sie basiert auf Kennzahlen zur Bewertung der Komplexität des Systems, die experimentell ermittelt und mit einer Reihe von Projekten validiert wurden. Der Aufwand wird getrennt nach Use Case (Funktionen) und Actor (Nutzer einer Funktion) erhoben. Use Case und Actor werden den Kategorien “einfach”,  “mittel” oder “komplex” zugeordnet. Jede Kategorie hat ein Gewicht, das Einfluss auf die Berechnung der Use Case Points nimmt.

Der Baustein Epic ist für diese sehr grobe Abschätzung eine gute Grundlage. Ein Product-Owner ist ohne Unterstützung durch das Team in der Lage, ein Epic zu formulieren. Er braucht dazu nur die Anforderungen der Nutzer des Systems. Das Epic wird später bei der Umsetzung helfen, die Funktionalität des Produktes mit dem Baustein Case zu strukturieren.

Fazit

Im Zusammenhang mit agiler Software-Entwicklung wird viel geplant und geschätzt. Im Unterschied zu phasen-orientierten Vorgehensmodellen planen wir in unterschiedlicher Genauigkeit. Eine exakte Planung gibt es nur für den nächsten Sprint. Eine etwas gröbere Planung auf Basis des Product-Backlog gibt es für die nächsten zwei bis drei Sprints. Erst mit der Product-Roadmap geben wir einen Ausblick auf einen längeren Zeitraum. Die Roadmap ist dabei aber nicht als Plan mit Terminen und Zusagen zum Produkt zu verstehen. Es ist mehr eine etwas konkretere Darstellung der Vision für das Produkt. Sowohl Product-Backlog als auch Product-Roadmap müssen regelmäßig überprüft und neu bewertet werden aufgrund der Erkenntnisse bei der Umsetzung in den Sprints.

Die Methode CARDS+ hat für jedes Schätzverfahren einen passenden Baustein. Das Wiki ist eine große Hilfe bei der Darstellung und Vermittlung des Problemraums des Produktes und der Sicherung wertvollen Produktwissens, dass in jeder Art von Schätzklausur gebraucht wird.