Projekt-Praktikum: Product-Backlog-Meeting

Bärbel de BouvierNach dem die CeBIT-Woche endlich rum ist und alle an meinem Projekt beteiligten Mitarbeiter wieder verfügbar sind, konnte ich letztens mein erstes Product Backlog Meeting abhalten. Zuvor hatte ich einen initialen Backlog mit den Anforderungen des Kunden zusammengestellt, der als Arbeitsgrundlage gedient hat. Die Aufgabe in diesem Meeting: Zusammen mit den Entwicklern eine erste Zeiteinschätzung, sowie generell eine Präzisierung der notwendigen Arbeitsschritte auszuarbeiten.

Da mein Projekt relativ überschaubar und das Team  recht klein ist, haben wir das Meeting an meinem Schreibtisch abgehalten. Den Input des Teams habe ich gleich in ein Merlin-Dokument eingetragen (siehe Bild). Bei größeren Projekten und Teams sind unter Umständen ausgefeiltere Techniken ratsam, etwas das Brainstorming mit Ideenkarten und einem Whiteboard. Doch dazu werde ich später ein eigenes Posting machen.

Wichtig ist, dass ich jetzt eine Grundlage für meine Arbeit habe. Ich habe schon während des Meetings eine Priorisierung durchgeführt und die Aufgaben entsprechend geordnet. Damit ist die Grundlage für das erste Sprint-Planning-Meeting schon mal geschafft.

Product Backlog

Projekt-Praktikum: Der Product Backlog (Teil 2)

Bärbel de BouvierIn der Theorie schaut ja alles ganz einfach aus: Der Product Owner bastelt den ersten Product Backlog, lässt sich vom Team eine Einschätzung des Aufwands geben, priorisiert die User Stories und schon ist das Produkt so gut wie fertig. Wie gesagt, so steht es im Lehrbuch. Aber wie sieht das ganze in der Praxis aus und wie wird es organisiert?

In der Regel fällt irgendwann einmal der Entschluss ein neues Projekt anzugehen und es wird ein Verantwortlicher dafür bestimmt. Das ist normalerweise der zukünftige Product Owner. Seine erste Aufgabe ist die Formulierung der Zieldefinition und die Erstellung der ersten Version des Product Backlogs.

  1. Er wird im ersten Schritt nicht umhinkommen eine Grobversion zunächst selbst zu erstellen. Dazu kann er sich bei Bedarf mit Fachleuten, also Entwicklern etc. besprechen. Das Ergebnis ist die Grundlage für den nächsten Schritt.
  2. Zeit für ein erstes Meeting. Dazu versammelt der Product Owner alle verfügbaren bzw. notwendigen Fachleute. Ziel ist es, eine erste realistische Aufwandseinschätzung für die User Stories zu erhalten. Je nach Umfang des Projektes kann dieses Meeting mehrere Stunden in Anspruch nehmen.
  3. Sobald der erste, realistische Product Backlog steht, kann der Product Owner die Kosten des Projektes einschätzen. Kommt Anschließend das Go vom Management, kann es losgehen.
  4. Spätestens jetzt kommt der Scrum Master ins Spiel. Der Product Owner muss in Zusammenspiel mit ihm dafür sorgen, dass der folgende Prozess korrekt, sprich also Scrum-konform aufgesetzt wird.
  5. Jetzt gilt es das passende Team zusammenzustellen. Dessen erste Aufgabe: Noch ein Product Backlog Meeting, dieses mal aber mit den konkret Beteiligten, also den Machern des Projekts. Ziel ist es die Aufwandschätzung nochmals zu optimieren, gegebenenfalls die User Stories zu ergänzen und zu präzisieren.
  6. Nun muss der Product Owner die User Stories priorisieren und damit die Grundlage für das erste Sprint Planning schaffen.

Im nächsten Beitrag schauen wir uns an, wie ein Product Backlog inhaltlich aussieht.

Projekt-Praktikum: Der Product Backlog

Bärbel de BouvierSo, nach einer kleinen Pause geht es weiter mit meinen Erkenntnissen über Scrum. Es wird an der Zeit mit einem Projekt zu beginnen und das erste Product Backlog zu erstellen.

Dazu müssen wir zunächst einmal das Product Backlog genauer erklären:

Das Product Backlog (PB) ist das zentrale Steuerungsinstrument in Scrum und es wird einzig und allein vom Project Owner (PO) geführt. Wichtig ist dabei, das dass Product Backlog ständig im Fluss ist und einer  permanenten Änderung unterliegt.

Einfach gesagt ist das PB eine priorisierte Liste mit allen funktionalen und nichtfunktionalen Anforderungen an das Produkt (User Stories). Auch Probleme, Risiken und alles, was sonst noch zu tun und zu beachten ist kommt in das Product Backlog.

Die Priorisierung erfolgt dabei durch den Product Owner. Ausserdem gehört zu jedem Punkt im Backlog eine Einschätzung der benötigten Arbeitsdauer. Diese erfolgt durch das Team.

Die Arbeitsschritte sind also:

  1. Zieldefinition (was wollen wir machen?)
  2. Sammlung der Anforderungen bzw. User Stories
  3. Einschätzung des jeweiligen Arbeitsaufwands durch das Team
  4. Priorisierung der User Stories durch den Product Owner

Wie das in der Praxis aussieht, zeige ich euch im nächsten Beitrag. Dann geht es nämlich ans Eingemachte.

Für meine ersten Schritte in Scrum habe ich mir ausserdem schon mal ein rudimentäres Product Backlog in Merlin angelegt.:

Product-Backlog Beispieldatei für Merlin

Projekt-Praktikum: So läuft Scrum

Bärbel de BouvierNach dem wir in den letzten Beiträgen die wichtigsten Begriffe gelernt haben, geht es jetzt darum, wie ein Scrum-Projekt prinzipiell abläuft. Drei Punkte sind dabei wesentlich und decken sich weitestgehend mit den grundsätzlichen Prinzipien des agilen Projektmanagements:

  1. Die Idee von Scrum beruht darauf, dass die Entwicklung von Software, aber auch generell von komplexen Produkten nicht in dem Maße planbar ist, wie andere typische Projekte, etwa der Bau eines Gebäudes oder die Einrichtung einer neuen Produktionslinie in einer Fabrik.
  2. Ein Scrum-Projekt wird iterativ er- und abgearbeitet. Die Devise lautet, lieber in kleinen Schritten schnell voran kommen, als bei einem großen Schritt zu stolpern, sich dabei zu verletzen und deshalb nie ans Ziel zu kommen.
  3. Es gilt die Erkenntnis, dass das Team besser weiß als eine zentrale Planungsstelle (Projektmanager), was es wann und wie tun kann und welche Schritte dazu notwendig sind. Scrum formalisiert diesen Prozess jedoch und macht ihn dadurch planbar.

Der Ablauf:

Aus dem Product-Backlog werden die am höchsten priorisierten Anforderungen in den Sprint-Backlog übernommen. Das ist die Arbeitsgrundlage bzw. der Projektplan für den folgenden Sprint. Ein Sprint dauert typischerweise zwei bis vier Wochen. Die Basis für die tägliche Arbeit bildet dabei das (in der Regel 15-Minuten kurze) Daily-Scrum-Meeting. Am Endes eines Sprints folgt das Sprint-Review.

Das Ziel von Scrum wird damit klar: In möglichst kurzer Zeit zu einem funktionierenden, wenn auch nicht mit allen Features versehenen Produkt zu kommen. Fehlende Features werden in nachfolgenden Sprints hinzugefügt.

Am Beginn eines Scrum-Projektes steht das Product Backlog. Den schauen wir uns in der nächsten Folge genauer an.