Agiles Projektmanagement Quiz – Part 2: Sprint Backlog – Der Sprint kann los gehen!

Let’s Quiz

Herzlich willkommen zum Agiles-Projektmanagement-Quiz – Part 2. Hier kannst Du Deine Scrum-Kenntnisse und Dein Projektmanagementwissen an realen Projektbeispielen testen. Es geht es um eine konkrete Projektsituation, die wir selbst erlebt haben und für die wir eine Lösung finden mussten.

Das heutige Quiz beschreibt eine Projektsituation aus einem agilen Projekt, in dem das Vorgehensmodell Scrum eingesetzt wurde. Scrum beschreibt einen iterativen Prozess für die Softwareentwicklung, die Planung erfolgt in Sprints. Weitere Informationen gibt es in der Quiz-Beschreibung zum ersten Quiz.

Im ersten Teil der vierteiligen Quizreihe „Sprint Planning – Aller Anfang ist schwer“ ging es um die Planung des Sprints. Dies erfolgt im Rahmen eines Sprint Planning Meetings, in dem die Arbeitspakete festgelegt und geplant werden, die in diesem Sprint umgesetzt werden. Diese User Stories bilden das Sprint Backlog.

Die Stories im Sprint Backlog müssen so spezifiziert sein, dass sie umgesetzt werden können. Denn nur, wenn alle benötigten Informationen in einer User Story enthalten sind, darf diese im Sprint Planning in den Sprint gezogen werden.

Sprint Backlog – Bereit zur Umsetzung

Im heutigen Quiz geht es um dieses Sprint Backlog. Wir haben im Sprint Planning 1 geklärt, welche der fertig spezifizierten User Stories in diesem Sprint umgesetzt werden müssen. Aus dem Sprint Planning 2 geht hervor, wie sich die Stories konkret umsetzen lassen. Daraus ist unser Sprint Backlog entstanden.

Das wäre zumindest die Idealvorstellung. Häufig ist es jedoch so, dass Stories im Sprint landen, die nicht ausreichend spezifiziert sind, so dass eine konkrete Planung der Umsetzung nicht möglich ist. Doch wie lässt sich dies verhindern?

Im Scrum Guide ist beschrieben, dass eine Story „ready“ sein sollte, um im Sprint Planning durch das Entwicklungsteam ausgewählt werden zu können. Deshalb ist es von zentraler Wichtigkeit, dass alle Projektbeteiligten ein gemeinsames Verständnis davon haben, was „ready“ bedeutet. Um dies sicherzustellen, ist es hilfreich eine „Definition of Ready (DoR)“ festzulegen, die genau dies definiert. Es handelt sich dabei um eine Liste von Kriterien, die an User Stories gestellt werden. Die DoR ist die Anforderung des Scrum-Teams an die Qualität und an die Informationen einer User Story. Der Product Owner sorgt dafür, dass diese Qualität im Product Backlog gewahrt ist. Die Idee dahinter ist, dass nur vage beschriebene User Stories nicht in einen Sprint gelangen können, sondern nur solche, die der DoR entsprechen.

Typische Anforderungen in einer DoR sind:

• User Story ist User-zentriert beschrieben
• Akzeptanzkriterien (funktional und nicht funktional) sind beschrieben
• Abhängigkeiten sind beschrieben
• Rahmenbedingungen und Voraussetzungen sind beschrieben
• Alle Referenzen für die Umsetzung liegen vor (z.B. CI-Guidelines, Usability-Guidlines)
• Der Business Value ist bewertet
• Die Schätzung liegt vor
• Testfälle liegen vor

Der Praxisfall – ein Prototyp für eine Messe

Die Projektsituation entstand im Kontext Condition Monitoring und Predictive Maintenance. Im konkreten Projekt hat das Team in vier Sprints einen Prototyp für eine Messe realisiert. Da der Prototyp auf der Messe vorgestellt werden sollte, war es entscheidend, am Tag der Messe eine funktionsfähige Anwendung zur Verfügung zu haben. Es musste also in möglichst kurzer Zeit eine Anwendung fertiggestellt werden, die zwar noch nicht produktiv einsetzbar ist, aber potenziellen Endanwendern einen möglichst großen Funktionsumfang präsentiert.

Im ersten Sprint war die Qualität der fachlichen User Stories, nach Coaching der Product Owner durch doubleSlash, recht gut, und die Arbeit schritt voran. In der Tabelle siehst Du den aktuellen Stand.

Das Projekt befindet sich jetzt einen Tag vor Abschluss von Sprint 2. Es fehlen immer noch einige der Nachspezifikationen für die angenommenen 10 fachlichen User Stories.
Ein erneutes Coaching-Angebot, um beim Verfassen der User Stories zu unterstützen, haben die Product Owner aus Kapazitätsgründen abgelehnt.

Fragen:

Frage 1: Welche Auswirkungen haben die fehlenden Spezifikationen auf das Ergebnis des laufenden Sprints?

Frage 2: Welche Risiken siehst Du für das Projektergebnis?

Frage 3: Was kann der Projektleiter tun, um das Projekt erfolgreich abzuschließen?

Hier findest Du Teil 1, 3 und 4 der Projektmanagement-Reihe:

Zum 1. Teil des PM Quiz – Sprint Planning – Aller Anfang ist schwer

Zum 3. Teil des PM Quiz – Reporting – Ist unser Projekt erfolgreich?

Zum 4. Teil des PM Quiz – Sprint Review – Was haben wir geschafft?