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.

SprintSprint LängeSprint BacklogTechn./fachl. User StoriesAusreichend spezifiziert
11 Woche167/9Alle

In einem verlängerten Sprint Planning konnten User Stories geeignet geschnitten und die offenen Fragen geklärt werden.

22 Wochen3222/1010 fachliche User Stories sind nicht ausreichend spezifiziert, aber für den Sprint angenommen.
32 Wochen??Das Backlog ist unvollständig!
41 Woche??Das Backlog ist leer!

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?

Auch für diesen Fall gibt es nicht die richtige Lösung. Schick uns gerne Deine Antworten per Kontaktformular oder poste einen Kommentar unter diesen Beitrag, dann senden wir dir gerne die Musterlösung, das heißt unsere Empfehlung mit der Projektsituation umzugehen, per Mail zurück. Wir freuen uns auf deine Ideen!

 

Mehr agiles Projektmanagement bekommst du hier
Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*Pflichtfelder

*

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.