Agiles Projektmanagement Quiz – Part 4: Sprint Review – Was haben wir geschafft?

Let’s Quiz

Herzlich willkommen zum Agile- Projektmanagement-Quiz – Part 4. Auch dieses Mal wird es um eine reale Projektsituation gehen, die wir selbst erlebt haben und für die wir eine Lösung finden mussten.

Wie in den vergangenen drei Teilen unserer Quizreihe könnt ihr hier erneut eure Scrum-Kenntnisse und euer Projektmanagementwissen an realen Projektbeispielen testen. Du hast einen oder mehrere Teile unserer Quizreihe verpasst? Kein Problem, du findest diese weiterhin auf unserem Blog. In den ersten drei Teilen haben wir uns mit dem Sprint Planning, dem Sprint Backlog sowie dem Reporting auseinandergesetzt.

Im letzten Quiz haben wir uns das Reporting näher angeschaut. Es ging um die Fragen, wie erfolgreich unser Team ist, wie viele Story Points (User Stories) abgearbeitet wurden und welche Möglichkeiten es gibt dies übersichtlich darzustellen – Stichwort Burndownchart. Doch wann sind User Stories eigentlich abgearbeitet? Wie wird dies definiert und wer entscheidet das? Unser heutiges Quiz beschäftigt sich genau damit. Viel Spaß!

Sprint Review – Was haben wir geschafft?

Scrum sieht zum Ende jedes Sprints ein sogenanntes Sprint Review vor. In diesem Meeting präsentiert das Entwicklungsteam dem Product Owner (PO) die Ergebnisse seiner Arbeit aus dem letzten Sprint. Zusätzlich nehmen auch weitere interessierte Stakeholder an diesem Termin teil – beispielsweise Vertreter aus dem Fachbereich oder die Autoren der entwickelten User Stories. Die Resultate werden live am System präsentiert. Zusätzlich ist es dem Team möglich Feedback zu sammeln, Verbesserungsvorschläge vorzubringen sowie Lob und Kritik auszutauschen. Auf Basis des Gezeigten entscheidet schließlich der PO, ob die entsprechende User Story als fertig (engl. done) angesehen werden kann oder ob nochmal nachgebessert werden muss. Bei dieser Einschätzung hilft dem PO ein weiteres Scrum-Artefakt. Die sogenannte Definition of Done (DoD).

Definition of Done – Was ist das?

Die „Definition of Done (DoD)“ beschreibt die Vorgaben des Product Owners an das Produkt. Sie ist maßgeblich dafür verantwortlich, ob eine User Story nach der (vermeintlichen) Umsetzung als done gekennzeichnet werden kann. Für die Einhaltung der DoD ist das Scrum-Team verantwortlich, welches die DoD sowohl bei der Sprintplanung, als auch bei der Umsetzung von User Stories immer berücksichtigen muss. Eine typische Definition of Done, aus Sicht des Product Owners, kann beispielsweise so aussehen:

• Akzeptanzkriterien sind erfüllt
• Tests sind erfolgreich
• Software ist auf Integrationsumgebung ausgeliefert
• Constraints sind eingehalten (z.B. Design Vorgaben, Usability Vorgaben)
• Benutzerdokumentation ist fortgeschrieben

Oftmals werden die Kriterien des Product Owners noch durch zusätzliche Aspekte aus Betriebs- oder IT-Sicht ergänzt. So könnte die DoD beispielsweise zusätzlich beinhalten, dass neben dem Benutzer- auch das Betriebshandbuch fortgeschrieben ist und die Testabdeckung mindestens 80% beträgt.

Es ist wichtig, dass die DoD allen Beteiligten klar kommuniziert und verständlich ist. Die DoD ist in gewisser Weiße ein Bestandteil jeder User Story, welcher in der Aufwandsschätzung berücksichtigt werden muss. Bei nicht klar definierten oder nicht ausreichend kommunizierten Kriterien besteht die Gefahr, dass der Aufwand für die Umsetzung einer User Story unterschätzt wird. Als Resultat werden zu viele User Stories in den Sprint eingeplant, von denen letztendlich vielleicht keine die DoD erfüllt und im Sprint Review nicht vom Product Owner abgenommen wird.

In einem solchen Fall klingt es verlockend, die DoD zum Sprintende aufzuweichen, um doch noch ein paar User Stories abzuschließen. Dies ist jedoch nicht ratsam, da hierdurch das Projekt mit der Zeit eine immer größere „Schuld“ aufbaut. Am Ende kann es einen ganzen Sprint kosten beispielsweise fehlende Tests und Dokumentationen entsprechend nachzuziehen. In der Praxis passiert dies häufig und ist auch nicht gänzlich zu vermeiden. Dennoch: die DoD ist der Qualitätsanspruch an das Projekt – welchen es nach Möglichkeit immer einzuhalten gilt.

Der Praxisfall – ein Sprint Review Meeting

Als Praxisfall für unser heutiges Quiz dient uns folgendes Beispiel. Im Sprint Review Meeting eines agilen Projektes werden die Ergebnisse des Sprints vorgestellt.

Die Definition of Done des Projektes ist:

• Software wird auf Testumgebung ausgeliefert
• Akzeptanztests sind durchgeführt und alle erfolgreich
• Betriebsreife Index ist erfüllt

Teilnehmer des Meetings sind:

• Team
• Scrum Master
• Product Owner
• Gesamtprojektleiter
• Testmanager
• Inbetriebnahme Manager
• Agiler Coach

Die Ergebnisse werden direkt im System gezeigt und vorgeführt. Zu Beginn des Meetings wird zudem eine Liste mit den Sprintergebnissen präsentiert.

Die Präsentation der Sprint Ergebnisse auf dem System wird vom Entwickler mit den folgenden Worten eingeleitet:

„Wundert euch nicht über die komischen Daten. Auf der Entwicklungsumgebung haben wir keinen Abzug der Echtdaten. Die Funktionen kann ich euch aber alle zeigen.“

Jetzt seid ihr an der Reihe!

Frage 1: Wie viele User Stories können im Burndown Chart als fertig eingetragen werden?

Frage 2: Welche User Stories können in die Produktionsumgebung eingespielt werden?

Frage 3: Welche Tipps habt Ihr für das Team, um im nächsten Sprint mehr User Stories fertig zu bekommen?

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

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

Zum 2. Teil des PM Quiz  – Sprint Backlog – Der Sprint kann los gehen!

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