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.

PrioritätUser StoryStory PointsStatus
1Story D12Fertig, bis auf Teil „xy“. Die Story kann erst mit Story T fertiggestellt werden.
2Story E20Fertig, aber noch nicht getestet.
3Story F8Fertig.
4Defect zu Story B aus vorherigem SprintFertig.
5Defect zu Story C aus vorherigem SprintKonnte nicht reproduziert werden und muss zusammen mit dem PO analysiert werden.
Update auf der PROD Umgebung (Anforderung kam während des Sprints)Fertig und eingespielt.

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?

Auch für diesen Fall gibt es nicht die richtige Lösung. Sende 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 gibt es hier

 

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?

 

HIer kostenfrei unsere Magic Estimation Karten zur effizienten Scrum Aufwandsschätzung

Hier kostenfrei unsere Magic Estimation Karten bestellen

 

Agiles Projektmanagement Quiz – Part 3: Reporting – Ist unser Projekt erfolgreich?

Let’s Quiz

Herzlich willkommen zum Agile- Projektmanagement-Quiz – Part 3. Hier könnt Ihr eure Scrum-Kenntnisse und euer Projektmanagementwissen an realen Projektbeispielen testen. Wie in den letzten beiden Teilen unserer Quiz-Reihe geht es wieder um eine Projektsituation, die wir selbst erlebt haben und für die wir eine Lösung finden mussten.

Auch in diesem Fall stammt die Projektsituation aus einem agilen Projekt, in dem das Vorgehensmodell Scrum eingesetzt wurde. Falls Du noch nicht mit Scrum vertraut und auf der Suche nach weiteren Informationen bist, dann schau gerne in den ersten beiden Teilen unserer Quiz-Reihe vorbei. Dort wirst du sicher fündig!

In den ersten beiden Teilen haben wir uns mit dem Sprint Planning sowie dem Sprint Backlog beschäftigt. Nun ist der Sprint vorbei und es steht die Überprüfung aus, wie erfolgreich wir das Sprint Backlog abgearbeitet haben. Haben wir unser Sprint Ziel erreicht? Konnten wir alle User Stories erfolgreich umsetzen, die wir für den Sprint eingeplant hatten?

Reporting – Ist unser Projekt erfolgreich?

Ein konsequent umgesetztes Reporting ist unweigerlich mit dem Projekterfolg verbunden. Auch in agilen Projekten ist es daher wichtig den Projektfortschritt kontinuierlich zu überprüfen.

Im Optimalfall sind zum Sprintende alle User Stories vollständig abgearbeitet und umgesetzt. In der Praxis zeigt sich jedoch häufig auch ein anderes Bild und das Sprintziel konnte nicht erreicht werden. Die Gründe hierfür sind vielfältig. Möglicherweise haben Informationen zu einzelnen Arbeitspaketen gefehlt, oder aber es fehlten schlicht die personellen Kapazitäten im Team, um alle Aufgaben vollständig abzuarbeiten.

In jedem Fall lassen sich zum Ende eines Sprints wertvolle Erkenntnisse darüber gewinnen, wie erfolgreich gearbeitet wurde und was im kommenden Sprint Planning berücksichtigt werden muss, um das Sprintziel in Zukunft zu erreichen.

Da die Summe aller erreichten Sprintziele den Fortschritt des Projektes als Ganzes repräsentiert, eignen sich diese Informationen auch hervorragend, um den Gesamtfortschritt aufzuzeigen und zu dokumentieren.

Burndown Chart

Ein in der Praxis gängiges Instrument, um den Projekt- und oder Sprintfortschritt zu überprüfen, sind die sogenannten Burndown Charts. Sofern gewisse Rahmenbedingungen erfüllt sind, ist die Anwendung denkbar. Welche Rahmenbedingungen das sind, erfahrt Ihr gleich. Zunächst wollen wir uns das Prinzip eines Burndown Chart näher anschauen. Wie ist es aufgebaut? Was sagt es aus?

In einem Burndown Chart werden auf der y-Achse die Story Points der einzelnen User Stories aufgetragen, die noch abgearbeitet werden müssen. Die x-Achse weist die Sprints des Projektes aus. Mit jedem Sprint verringert sich der Vorrat an verbleibenden Story Points im Backlog. Im Idealfall fällt die Kurve linear bis zum Projektende ab, bis irgendwann keine Story Points mehr vorhanden sind und sämtlicher Arbeitsaufwand „verbrannt“ ist.

In der nachfolgenden Abbildung seht ihr ein exemplarisches Burndown Chart für den Burndown im Projekt. Der Verlauf des realen Burndowns ist zwar nicht ideal, dafür aber realistisch. Der Grund hierfür liegt in der schwankenden Velocity des Teams. Die Velocity gibt an, wie viele Story Points je Sprint durch das Team abgearbeitet wurden. Nach einer Eingewöhnungsphase steigt diese langsam an. Entsprechend schneller sinkt auch die rote Kurve (Real Burndown) ab. Der Estimated Burndown (blaue Kurve) zeigt den prognostizierten Zustand – eine linear abfallende Kurve, die von einer konstanten Velocity des Teams ausgeht.

Produkt Burndown
Burndown im Projekt – eigene Darstellung

Nun wollen wir auf die eingangs genannten Rahmenbedingungen zurückkommen. Welche Bedingungen müssen erfüllt sein, damit ein Burndown Chart funktioniert und aussagekräftig ist?
Das Burndown Chart funktioniert super, wenn…
• … die Teamstärke über alle Sprints stabil ist
• … die Sprintlänge gleich bleibt
• … das Product Backlog zu Projektstart vollständig gefüllt, mit Story Points geschätzt und priorisiert ist.

Sind diese Rahmenbedingungen nicht erfüllt steigt damit auch die Komplexität. Unmöglich ist die Arbeit mit dem Burndown Chart aber auch dann nicht.

Eine Anwendung des Charts ist auch auf einzelne Sprints denkbar. In diesem Fall gibt die y-Achse die Story Points eines Sprints an während die x-Achse Zeitpunkte innerhalb des Sprints ausweist.

Kombiniert man die beiden Charts hat man zwei sehr gute Instrumente, um ganz einfach den Projektfortschritt zu messen.

Burndown Chart
Burndown im Sprint – eigene Darstellung

Übrigens: Burndown Charts lassen sich auch in anderen Projekten anwenden, sofern man anstelle von Sprints in Meilensteinen und anstelle von User Stories in offenen Aufgaben denkt.

Der Praxisfall – ein magisches Dreieck

Im konkreten Praxisfall wurde im letzten Viertel eines agilen Projektes der Arbeitsfortschritt des Projektes im Rahmen des magischen Dreiecks durch den Projektleiter überprüft.

Magisches Dreieck
Magisches Dreieck – eigene Darstellung

Der Projektleiter stellte fest, dass…
85% der Zeit verstrichen ist,
35% des Scope umgesetzt wurden und
65% der geplanten Kosten bereits verbraucht wurden.

Jetzt seid Ihr an der Reihe!

Frage 1: Mit welchen Mitteln konnte der Projektleiter das feststellen?
Frage 2: Welche möglichen Ursachen kann dieser Projektstatus haben?
Frage 3: Was sollte der Projektleiter eurer Meinung nach tun, um die Situation zu verbessern?

Auch für diesen Fall gibt es nicht die richtige Lösung. Sende 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

 

Hier findest Du Teil 1, 2 und 4 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 4. Teil des PM Quiz – Sprint Review – Was haben wir geschafft?

 

HIer kostenfrei unsere Magic Estimation Karten zur effizienten Scrum Aufwandsschätzung

Hier kostenfrei unsere Magic Estimation Karten bestellen