Entwicklung

Anforderungs-Management in großen Projekten - mit Scrum

15.05.2013
Von Sebastian Neus und Martin Wrangel

Organisation eines effektiven Product Backlogs

Dreistufiges Product Backlog
Dreistufiges Product Backlog

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 formuliert werden können, fließen ebenfalls in diese Stufe des Product Backlogs ein. Jeder hier enthaltene Eintrag erhält eine eindeutige Nummer. 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.

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

Product Backlog Stufe 1
Product Backlog Stufe 1

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.