Entwicklung

Anforderungs-Management in großen Projekten - mit Scrum

15.05.2013
Von Sebastian Neus und Martin Wrangel

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. 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.

Vorschlag für eine Dokumentationsform von Anforderungen.
Vorschlag für eine Dokumentationsform von Anforderungen.

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 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 mit einer Dreipunktschätzung geschätzt. Die Art der Dokumentation ist von der Anforderung abhängig. Eine Anforderung an Performance 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. Vor dem ersten Sprint eines Projektes ist zu entscheiden, mit welcher Vorgehensweise der Product Owner das initiale Product Backlog zusammenstellt. 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.