Scrum ist ein faszinierend einfaches Vorgehensmodell in der Softwareentwicklung. Doch auch agile Methoden setzen zwingend voraus, dass man seine Anforderungen kennt.
Damit ein Scrum-Projekt gelingt, muss es eine Reihe von erfolgreichen Sprints (Iterationen) absolvieren. Der Schlüssel dazu sind verlässlich schätzbare Items im Product Backlog, der Sammlung aller Anforderungen.
Ungenaue Anforderungen hingegen führen zu unzuverlässigen Sprints.
Ich zeige, wie in großen Projekten die Anforderungsanalyse und das Product Backlog miteinander verzahnt werden können und wie der Product Owner die Anforderungen aus den verschiedenen Projektbereichen, den fachlichen Scope, die technischen Notwendigkeiten (zum Beispiel Refactorings und Security) sowie die Erfordernisse des Betriebs identifizieren und optimal im Product Backlog organisieren und priorisieren kann.
In Scrum ist der Product Owner verantwortlich für die Formulierung von Anforderungen. Ein großer Unterschied zu klassischen Vorgehensmodellen ist jedoch, dass durch Scrum nicht beschrieben wird, welche inhaltlichen Merkmale die Anforderungen erfüllen sollen. Sie müssen lediglich so formuliert sein, dass sie vom Product Owner mit einem »Business Value« versehen und priorisiert werden können.
Der Product Owner formuliert Anforderungen in Form von Items. Das Team detailliert diese Items, indem es ihnen Tätigkeiten, die so genannten Tasks, zuordnet. Die Aufwände der Tasks oder auch der Items werden dann vom Team geschätzt.
Scrum Checkliste:
- alle (fachlichen) Anforderungen sind bekannt –> Storie Map, Use Cases mit Abnahmekriterien
- Story ist in schätzbare Items (IT, Dev-Sicht) herunter gebrochen –> Sprint Planning 2, Story: – Feature, Task, SubTask
- Stories sind ready (verstanden, fertig) –> Story: Backlog Grooming, Reifegrad
- Stories sind eindeutig und lassen sich priorisieren –> Product backlog: Sprint Planning 1, Priorisierung
- Definition of Done DoD ist verständlich und erfüllt –> Done, erledigtDone
– implementiert
– getestet
– integriert
Schätzen von Anforderungen und Aufgaben
Es gibt verschiedene Arten, dokumentierte Anforderungen zu schätzen. In Scrum werden grundsätzlich zwei Arten verwendet.
Planning Poker
Die erste Variante ist das »Planning Poker«. Hier werden Aufwandskategorien definiert, die man den Items oder Tasks zuordnet. Nach der fachlichen Beschreibung der Aufwandskategorien ordnet man ihnen je nach Höhe des Aufwands Zahlen zu. Geeignet dafür ist zum Beispiel die Fibonacci-Reihe, da hier die Abstände zwischen den Zahlen immer größer werden und sich somit Unsicherheiten deutlicher offenbaren:
- 1 = sehr geringer Aufwand
- 2 = geringer Aufwand
- 3 = neutraler Aufwand
- 5 = höherer Aufwand
- 8 = sehr hoher Aufwand
- 13 = extrem hoher Aufwand.
Das Team trifft sich zum Planning Poker und bewertet einzelne Items mit einer Zahl der Fibonacci-Reihe. Der Erste versieht das Item beispielsweise mit 3; das zweite Teammitglied ordnet ihm eine 2 zu und das dritte Teammitglied eine 8. Somit variiert die Bewertung um einige Punkte. Dieses Beispiel zeigt, dass das Team offenbar Schwierigkeiten hat, sich einer gemeinsamen Aufwandskategorie anzunähern – hier besteht Klärungsbedarf. Das Team muss nun das Item oder die Task weiter detaillieren, um eine besser übereinstimmende und damit genauere Schätzung zu erreichen. Anschließend wird pro Sprint eine gewisse Anzahl von Tasks aufgenommen. Aufgrund der jeweils zugeordneten Aufwandskategorien findet das Team von Sprint zu Sprint heraus, wie viele Tasks nach den oben genannten Kategorien pro Sprint realisiert werden können.
Ein weiterer, von mir favorisierter Ansatz ist die T-Shirt Schätzung für die Komplexität einer Story.
- S = small, einfach
- M = medium, mittel
- L = large, gross
- X = extreme, zu gross
Balance verschiedener Anforderungen
Scrum definiert nicht die inhaltlichen Kriterien an Anforderungen, sondern sagt lediglich aus, dass allein der Product Owner für die Stellung der Anforderungen verantwortlich ist. Somit hat der Product Owner darauf zu achten, dass alle relevanten Anforderungen in die Liste der Anforderungen, das Product Backlog, einfließen. In der Realität ergeben sich hieraus einige Herausforderungen, da der Product Owner häufig Mitarbeiter einer Fachabteilung ist und die technischen Aspekte nur sehr schwer einschätzen kann.
Es ist daher sinnvoll, weitere relevante Anforderungssteller aus den Fachbereichen zu identifizieren und nicht einen einzelnen Product Owner zu benennen,
sondern ein Team für diese Rolle aufzustellen, das einen Chief Product Owner benennt, der die vollständige Verantwortung trägt und bei Uneinigkeit Entscheidungen trifft.
Im Product-Owner-Team sollten sich dann die folgenden Rollen wiederfinden:
- fachlicher Anforderungssteller,
- Verantwortlicher für den Betrieb des Systems,
- Unternehmensarchitekt,
- Prozessverantwortlicher,
- professioneller Anforderungsanalyst.
Ein Anforderungsanalyst hilft mit professionellen Methoden dem Product-Owner-Team, Anforderungen zu finden und diese zu formulieren. Eine wichtige Fähigkeit ist dabei das initiale Finden von Anforderungen: z.B. eignen sich hierzu besonders
- Interview-Techniken und auch
- moderierte Anforderungs-Workshops
Weiterhin hilft der Analyst dem Team, die Anforderungen in der Art festzuhalten, dass diese bestimmte inhaltliche Kriterien erfüllen, damit zumindest durch das Formulieren und schriftliche Festhalten der Anforderungen keine Informationen zwischen Anforderungssteller und dem Team verloren gehen.
Hierzu steht u.a. ein Applikations-, bzw. Use Case Template als Vorlage bereit –> Erstellen.Auswahl der Vorlage…
Einführung von Scrum
Folgende Dinge sollten u.a. bei der Einführung von SCRUM beachtet werden:
- Bereitschaft für Veränderungen –> CHANGE .
- Geben Sie dem Team Verantwortung und Vertrauen.
- Motivieren und unterstützen Sie das Team.
- Starten Sie mit kurzen Sprints, bzw. gönnen Sie sich 1-3 Sprints für die Einführungs-/Lernphase –> Sprint Review und vor allem Retrospektive.
- Schaffen Sie Transparenz zur Steuerung –> zielgerichte Dashboards / Reports für die jeweiligen Zielgruppen, z.B. Development, Testing, Management…
Der Umgang mit Anforderungen
Anforderungen ändern sich – das gilt für alle Projekte. Es ist also die Aufgabe eines Vorgehensmodells, dies zu berücksichtigen. In Scrum können sich Anforderungen verändern, jedoch nicht während eines Sprints – im Rahmen des Backlog Grooming können Anforderungen im Vorfeld, d.h. im Product Backlog und bevor diese in den aktiven Sprint gehen, wachsen und verfeinert werden.
Die Agilität und das kontinuierliche Reagieren auf Ereignisse finden in Scrum nur außerhalb von Sprints statt.
Die Projektjustierung kann zu jeder Zeit durch den Product Owner stattfinden, sie darf jedoch keine Auswirkung auf laufende Sprints haben. Sollten sich gravierende Auswirkungen auf einen Sprint ereignen, hat der ScrumMaster die Möglichkeit einer »Abnormal Sprint Termination«; er kann also unter besonderen Bedingungen den Sprint abbrechen.
Durch Scrum ist formuliert, dass das Schätzen der Aufgaben im Planning Meeting stattfindet. In manchen Projekten ist dies nicht immer möglich, da einige Items so umfangreich sind, dass sie vorab ausführlich organisiert werden müssen. Somit können auch Schätzaufgaben für komplexe Anforderungen Sprint-Tasks sein.
Diese Items werden in einem Sprint geschätzt und erst in weiteren Sprints realisiert. In einem einzigen Sprint finden nicht Schätzung und Umsetzung statt.
Jede funktionale Anforderung im Product Backlog (PBL) könnte detailliert sein durch UseCaseModelDocuments (UCMD), indem die funktionalen Anforderungen anhand von Anwendungsfällen beschrieben werden. Diese Anforderungen lassen sich um Screendesigns/Mockups/Pageflows zur Visualisierung der Anforderung erweitern.
Alle Items werden um Tasks erweitert, bei großen Tasks werden diese nach dem Prinzip »Work Breakdown Structure« (WBS) aufgebrochen und in den WBS-Dokumenten im Detail geschätzt.
Die Art der Dokumentation, sowie deren Umfang ist von der Anforderung abhängig. Eine Anforderung an Performance (NFR) lässt sich selbstverständlich nicht über ein Screendesign dokumentieren, jedoch textuell und in Form einer WBS.
Anforderungen werden im Laufe des Projekts weiter verfeinert (Reifegrad, POC, Prototype, Final).
Vor dem ersten Sprint eines Projektes ist zu entscheiden, mit welcher Vorgehensweise der Product Owner das initiale Product Backlog zusammenstellt –> Story/Release Map.
Es kann empfehlenswert sein selbst diese Aufgaben als Sprints zu organisieren oder aber auch eine Initialphase einzulegen, die von Scrum losgelöst ist und das initiale Product Backlog organisiert.
Organisation eines effektiven Product Backlogs
Dieser Abschnitt beschreibt den Aufbau und die Organisation eines effektiven Product Backlogs, das nicht nur zur Entwicklung und Organisation von Sprints verwendet werden kann, sondern ebenfalls zur Sammlung von Anforderungen verschiedener Detailierungsstufen. Der Weg führt über die Einführung eines Muli-Level Product Backlogs. Das Multi-Level Product Backlog ermöglicht es, Anforderungen zu sammeln, diese zu detaillieren und durch Qualitäts-Tore (Qualitygates) zwischen den Levels die Anforderungen in einen Zustand zu überführen, der den Anforderungen des Teams bezüglich präziser Schätzungen entspricht. Die Abbildung verdeutlicht den grundsätzlichen Aufbau eines dreistufigen Product Backlogs. Sie beschreibt, in welchem Zustand sich Anforderungen in der jeweiligen Stufe befinden. Ebenfalls wird skizziert, in welche Richtung oder aus welcher Richtung Informationen pro Stufe kommen und gehen.
Stufe 3 des Product Backlogs
Die dritte Stufe des Product Backlogs enthält Anforderungen, die durch das Product-Owner-Team formuliert sind. Diese Anforderungen sind in dieser Stufe keiner Qualitätssicherung unterzogen. Anforderungen sind hier sehr grob beschrieben, noch nicht ausdetailliert und nicht priorisiert. Es sind alle Arten von Anforderungen enthalten. In dieser Stufe werden Anforderungen und Änderungen (Change Requests) gesammelt.
Nach jedem Sprint findet ein Sprint-Review-Meeting mit dem Team, dem ScrumMaster und dem Product-Owner-Team statt. Ergebnisse hieraus, die als Items (Improvement) formuliert werden können, fließen ebenfalls in diese Stufe des Product Backlogs ein. In dieser Stufe des Product Backlogs ist für keines der Items klar, ob es je umgesetzt werden soll.
Stufe 2 des Product Backlogs
Ist ein Eintrag durch das Product-Owner-Team in die zweite Stufe übertragen worden, beginnt das Analyseteam oder der Analyst in Zusammenarbeit mit dem Product Owner und dem Team, diesen Eintrag aus zu detaillieren. Schätzaufgaben und technische Detaillierungen werden vom Team vorgenommen und müssen somit für Sprints als Aufgaben festgelegt werden. Funktionale Anforderungen in Form von Use Cases haben den Vorteil, dass eine Dokumentation erzeugt wird, die gleichzeitig von fachlichen Mitarbeitern und den technischen Mitarbeitern des Entwicklungsteams gelesen und verstanden wird und muss bis zum Sprint Start Ready/verstanden, vollständig sein
Sind alle Aufgaben zur Detaillierung und Dokumentation in der zweiten Stufe des PBL abgeschlossen und alle Tasks geschätzt, werden diese durch das Product-Owner-Team priorisiert. Die Items mit der höchsten Priorität werden dann nach Prüfung auf Vollständigkeit in die Stufe 1 des PBL durch das Product-Owner-Team verschoben.
Stufe 1 des Product Backlogs
Die Verschiebung der Items in die oberste Stufe ist gleich zu setzen mit einer Beauftragung durch den Product Owner an das Team, dieses Item zu realisieren. Bevor Items in die Stufe 1 verschoben werden, prüft der Product Owner diese auf Vollständigkeit. Das bedeutet, es existiert ein Qualitäts-Tor (Qualitygate) zwischen der zweiten und der ersten Stufe.
- Jeder Eintrag muss dieses Tor durchlaufen, um in die erste Stufe zu gelangen.
- Jeder Eintrag in dieser Stufe gilt gleichzeitig als vom Product-Owner Team freigegeben.
Die Erste Stufe ist die Sammlung der Beauftragungen für das Team. Aus dieser Stufe kann das Team Items für die nächste Iteration, den nächsten Sprint, entnehmen.
Im Planning Meeting muss sich das Team auf die Realisierung der Items im nächsten Sprint festlegen. Das geht aber nur dann, wenn das Team die Einträge durchdringt und versteht. Die Priorisierung der Einträge erfolgt durch das Product-Owner-Team jeweils vor dem nächsten Planning Meeting.
Das Planning Meeting kann durchgeführt werden und das Team kann sich auf die Realisierung auch von komplexen Aufgaben committen, da diese weitreichend genug beschrieben worden sind und sich das Team bereits in vergangenen Sprints mit den Details der Aufgaben auseinander gesetzt hat.
Fazit und Glossar
Wenn komplexe Systeme entwickelt werden sollen, bei denen sich die Anforderungen zu Beginn nicht oder nicht vollständig formulieren lassen, sind agile Vorgehensmodelle die richtige Wahl. Abhängig davon, wie viel Planbarkeit in Abhängigkeit zu den definierbaren Anforderungen sein soll, müssen agile Modelle um einige klassische Ansätze erweitert werden.
Scrum ist eine gute Alternative, um Planbarkeit mit agilen Ansätzen zu kombinieren. Durch die Bildung eines Product-Owner-Teams hat nicht ein einzelner Product Owner die Aufgabe, Anforderungsaspekte unterschiedlicher Unternehmensbereiche zu formulieren, sondern die unterschiedlichen Unternehmensbereiche sind im Team vertreten.
Der Chief Product Owner erhält dabei das Recht der finalen Entscheidung.
- Dies ist in der Praxis, gerade in größeren Projekten, unbedingt zu empfehlen.
Verlässliche Sprints ermöglichen das Organisieren von Release-Plänen und schaffen somit für Manager und Budget-Verantwortliche das nötige Vertrauen in die Entwicklung.
Das iterative Vorgehen und das kontinuierliche Überprüfen der Vorgehensweise – bei kurzen Feedback-Zyklen mit dem Kunden – helfen, Projekte zum Ziel zu führen.
Begriffe in Scrum
- Sprint: So werden Iterationen in Scrum genannt (maximal 30 Tage).
- Product Backlog: Sammlung der gesamten Anforderungen.
- Sprint Backlog: Anforderungen eines Sprints.
- Daily Scrum: Tägliches maximal 15-minütiges Team-Meeting.
- Burn Down Chart: Fortschritts-Graph mit Angaben zu Restaufwänden.
- ScrumMaster: Wahrt die Regeln aus Scrum in einem Projekt.
- Product Owner: Gesamtverantwortlicher Anforderungssteller.
- Sprint Review: Ergebnispräsentation nach einem Sprint durch das Team.
- Sprint Retrospektive: Analyse des vergangenen Sprints (Lessons Learned).
- Planning Poker: Methode zum Schätzen.
- Work Breakdown Structure: Hierarchische Unterteilung von Arbeitspaketen.
Dieter Langjahr
cert. Scrum Master Professional / agile PM Coach