Die 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, diesen Eintrag im Detail zu beschreiben.

Die Stufe 3 des Product Backlogs


Schätzaufgaben und technische Detailbeschreibungen werden durch das Team durchgeführt und müssen somit für Sprints als Aufgaben festgelegt werden. Diese Aufgaben werden für das nächste Planning Meeting bereitgestellt. Damit Sprints planbar bleiben, werden diese Aufgaben mit Zeitfenstern (festgelegter Maximalaufwand für einen Task) versehen. Scrum hat für die Arbeit an der Verbesserung und Ausgestaltung des Product Backlog den Begriff „refinement“. Das Team sollte ca. 10% seiner Zeit dazu verwenden, die Items des Product Backlogs zu verstehen und gemeinsamen mit dem Product Owner Team zu verbessern.

Abbildung 26 beschreibt die Inhalte und Hauptbestandteile der zweiten Stufe.

Scrum Product Backlog Stufe 2 - Arbeitspool für Analyse- und Schätzteam: zu bewerten, zu vervollständigen (UCM, WBS, linked docs, ...); Gate zu Stufe 1: Der Product Owner lässt nur ausdetaillierte und geschätzte Tasks zu; Beispiel: [RE-No. 8765.1] Kontaktformular bearbeiten

Abbildung 26 – Product Backlog Stufe 2


In die Stufe 2 des Product Backlogs gelangen Items ausschließlich aus der Stufe 3. Sollten sich gravierende Änderungen an Items ereignen, kann es möglich sein, ein Item aus der Stufe 1 auch zurück in die Stufe 2 zu stellen. Dies sollte jedoch nur in besonderen Ausnahmen passieren.

Alle Elemente dieser zweiten Stufe sind somit zunächst Aufgaben für das Analyseteam oder den Analysten. Der Analyst hat die Aufgabe, die funktionalen Anforderungen durch UseCases (Anwendungsfall) zu beschreiben und wenn Benutzerschnittstellen, also grafische Oberflächen, betroffen sind, diese Items auch mit Screens zu beschreiben.

Funktionale Anforderungen werden vom Anforderungssteller interpretationsfrei mit »UseCases« beschrieben. Diese können gleichzeitig von fachlichen und technischen Mitarbeitern gelesen und verstanden werden. Der Aufwand, einen Fließtext für das Entwicklungsteam technisch zu übersetzen, entfällt. Die erzeugte Dokumentation stellt Anwendungsfälle grafisch dar und formuliert sie schriftlich aus.

Die Eigenschaften eines Anwendungsfalls bestehen aus einer eindeutigen Nummer, Name, Beschreibung, Eingangsbedingung, Ausgangsbedingung, Detailablauf, Status, erstellt am und erstellt von.

Tabelle 5 – Eigenschaften eines Anwendungsfalls


Die Tabelle beschreibt die Eigenschaften, die ein Anwendungsfall mindestens enthalten muss. Die Tabelle kann um weitere Eigenschaften ergänzt werden, dies ist jedoch eine projektspezifische Entscheidung.

Durch den Detailablauf und die Bedingungen wird vom Anforderungssteller festgelegt, wie diese Anforderung getestet werden kann. Hieraus kann der Entwickler dann direkt seine eigenen technischen Tests ableiten. Aus der Gesamtheit aller Anwendungsfallbeschreibungen kann der Anforderungssteller sein Abnahmedokument generieren.

Die Screendesigns unterliegen den allgemeinen, für das Projekt definierten grafischen Richtlinien, die zu Beginn formuliert worden sind, oder sich in das Corporate Design eines Unternehmens oder einer Unternehmenssoftware eingliedern.

Durch das Definieren der Screendesigns hat der Anforderungssteller sehr frühzeitig im Projekt die Möglichkeit, seine formulierten Anforderungen zu sichten und zu prüfen. Zu einer ersten Prüfung eignet sich besonders das sogenannte Paper-Based-Design. Das bedeutet, dass während der Anforderungsaufnahme das Analyseteam oder der Analyst die besprochenen funktionalen Anforderungen mit Papier und Stift in Screenskizzen aufmalt und somit den ersten Screenflow (Ablauf der Funktionen auf den Masken) visualisiert.

Weiterhin werden alle Anforderungen, auch die nicht-funktionalen, um eine Work Breakdown Structure (WBS) erweitert. Die WBS unterteilt Items in kleine, überschaubare und testbare Pakete, sodass diese vom Team geschätzt werden können. Die Erstellung der WBS erfolgt hauptsächlich durch das Team. Das Team hat im Planning Meeting die Aufgabe, einen Plan für die Realisierung zu erstellen.

Zu diesem Schritt, dem Commitment oder Forecast, gibt es in Scrum eine Analogie:

Ein Huhn schlägt einem Schwein eine Geschäftsidee vor. Sie wollen ein Frühstücksrestaurant eröffnen. Als Angebot soll es Eier mit Speck geben. Das Schwein lehnt ab, denn für das Huhn wäre es ein Leichtes gewesen, durch das Eierlegen ist es nur »involved«, das Schwein jedoch ist »committet«, denn es muss sich selbst hergeben für den Speck.

Es gilt also in Scrum, dass die Aussage zum Aufwand nur von denjenigen durchgeführt werden darf, die auch »committet« sind, und das ist das Team.

In der jüngeren Vergangenheit wird allerdings nur noch der Begriff Forecast verwendet, da in der Praxis das Commitment des Teams häufig für Mehrarbeit missbraucht wurde und das Team im Falle von Problemen dazu angehalten ist, jederzeit den Dialog zum Product Owner zu suchen.

Die folgenden Grafiken, Abbildung 27 und 28, zeigen Möglichkeiten der grafischen Darstellung des Kontaktformulars, der UseCases oder auch der Screenbeschreibung.

Scrum Product Backlog Stufe2 UML Use Cases

Abbildung 27 – Product Backlog Stufe 2, UML Use Cases


Die Use Cases werden zur besseren Übersicht grafisch dargestellt und enthalten zusätzlich, wie oben beschrieben, noch einige weitere Details.

Scrum Product Backlog Stufe2 Screendesign

Abbildung 28 – Product Backlog Stufe 2, Screendesign


Die Grafik stellt sehr detailliert die fachlichen Wünsche dar und ist somit für den Entwickler eine präzise Anleitung. Sollten sich während der Entwicklung Änderungen ergeben, kann diese Darstellung als Diskussionsgrundlage verwendet werden. Die grafische Darstellung von Anforderungen ist interpretationsfrei und hilft so dem Anforderungssteller und den Entwicklern bei der Umsetzung.

In Abbildung 29 ist ein Beispiel einer WBS aufgeführt.

Scrum Product Backlog Stufe2 WBS

Abbildung 29 – Product Backlog Stufe 2, WBS


Diese WBS enthält Hauptaufgaben und deren Präzisierung. Wie im Abschnitt »Planung« beschrieben, enthält hier jeder Task eine drei-Punkte-Schätzung, für die Fälle Best Case, Average Case und Worst Case. Der oder die Schätzer tragen hier die angenommenen drei Fälle ein. Der PERT-Wert (Program Evaluation and Review Technique), also die Beta-Verteilung, errechnet dann den geschätzten Aufwand. Über die Varianz wird ein Überblick über die Schätzabweichung gegeben, hierauf kann dann gesondert durch das Team reagiert werden. Durch Berücksichtigung der Standardabweichung (siehe Abschnitt Reale Tage und die Beta-Verteilung) kann die Schätzgenauigkeit verbessert werden.

Sind alle Aufgaben zur Detailbeschreibung 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 nach Prüfung auf Vollständigkeit in die Stufe 1 des PBL durch das Product Owner Team verschoben.

Das Verschieben in die Stufe 1 ist gleichzusetzen mit einem Auftrag an das Entwicklungsteam. Dieses Item wird dann gemäß Priorität in den nächsten Planning-Meetings in Sprints vom Team geplant und realisiert.


Die Stufe 1 des Product Backlogs

Diesen Artikel weiterempfehlen

    

Über den Autor

Die itemis AG ist ein unabhängiges IT-Beratungs­unternehmen, das leistungsfähige Software für Unternehmens­anwendungen, eingebettete Systeme und mobile Applikationen entwickelt – und über diese Themen bloggt.