Sprint Planning - Meeting im Scrum-Projekt

Fred, Product Owner in einem fiktiven Unternehmen, hatte alles organisiert: die Einladungen versendet, Getränke und Obst bestellt, Flipchart und Stifte besorgt und die Tische im Teamraum zusammengeschoben. Es roch nach Kräutertee, Keksen und Weintrauben.

Jonas und andere Software-Entwickler saßen bereits am Tisch. Auch jeweils ein Kollege von Marketing und Vertrieb waren pünktlich erschienen. In letzter Minute stürmte Bernd, der Scrum Master, durch die Tür. Nun waren das gesamte Scrum Team sowie einige Stakeholder versammelt, um mit der Planung des nächsten Sprints zu beginnen.

„Also, liebe Leute“, begann Bernd. „Wir fangen an. Herzlich willkommen zu unserem Sprint Planning Meeting. Ich denke, wir brauchen sechs Stunden (Time boxed). Also nicht mehr als beim letzten Mal, dann sind wir durch. Wie gewohnt splitten wir unser Meeting in zwei Teile. Im ersten Teil besprechen wir die Inhalte. Im zweiten Teil legen wir die Vorgehensweise fest.“

Dann wandte er sich an Fred: „Kannst du uns bitte das Sprintziel erläutern?“ Bernd nickte Fred freundlich zu. „Ja, sehr gern. Ich habe alles vorbereitet“, antwortete dieser.

Das Sprint-Planning ist das Planungsmeeting in Scrum

Zeitpunkt: Zu Beginn jedes Sprints
Teilnehmer aktiv: Entwicklungsteam, Scrum-Master, Product-Owner
Teilnehmer passiv: Stakeholder, Gäste
Organisator: Product-Owner

„Welche Funktionen liefern unseren Kunden den größten Nutzen?“, begann Fred und klappte den Laptop auf. Und ohne auf eine Antwort zu warten, fügte er hinzu: „Die wichtigsten User Stories im Product Backlog findet ihr ganz oben.

Ich habe die Einträge der Wichtigkeit nach sortiert. An den ersten Positionen stehen die Funktionen, die dem Kunden den größten Mehrwert versprechen.“

Fred verband seinen Laptop mit dem Beamer, und sofort erschien das Product Backlog an der Projektwand. „Im nächsten Sprint müssen wir die Shop-Komponente bereitstellen. Dann können unsere Kunden hochwertigen Inhalt kaufen.“ Während Fred sprach, flog er mit der Maus über die Backlog-Einträge.

Er klickte hier und da auf die Stichworte: Warenkorb, Preisregeln, Filtermechanismen, Promo-Codes, Sonderangebote, Staffelpreise für bestimmte Kundengruppen sowie Newsletter-Abonnement.

Der Scrum Master bediente sich unterdessen mit Getränken und sagte: „Danke Fred. Ist nun allen klar, WAS wir im nächsten Sprint implementieren wollen? Über welche User Stories müssen wir uns genauer unterhalten?“

„Yep, also für mich ist klar, wo es langgeht“, erwiderte Jonas. Er streckte den Rücken, ließ die Finger knacken und blickte zu seinen Kollegen.

„Na ja, ich bin mir nicht sicher“, entgegnete ein anderer. „Die Newsletter-Funktion passt dort nicht. Sie muss raus. Das können wir doch mit den anderen Dingen im übernächsten Sprint machen. Lass uns das nicht zweimal anpacken.“

Es begann eine lebhafte Diskussion zwischen den Entwicklern. Dann entschieden sie sich, den Newsletter in den übernächsten Sprint zu schieben.

„Was haben wir noch? Gibt es weitere Dinge?“, erkundigte sich Bernd.

Aufmerksam verfolgten die Kollegen aus Marketing und Vertrieb die Diskussion. Dann sagte einer: „Passt schon. Hauptsache, wir bekommen alles andere. Aber sagt mal, schafft ihr das überhaupt?“

Jonas sah die Mitglieder des Scrum Teams ungläubig an. „Was? Klar schaffen wir das!“, erwiderte er entrüstet.

„Sorry, Leute. Ich wollte euch nicht ärgern. Aber wieso seid ihr euch da so sicher? Woher wisst ihr, wie viel Aufwand hinter jeder User Story steckt?“, beschwichtigte ihn der Vertriebler.

Jonas hatte sich wieder beruhigt. Ihm wurde klar, dass die Fragen aus Unwissenheit gestellt wurden. Er nahm seine Stimme zurück und begann zu erklären: „Kurz vor dem Sprint Planning Meeting trafen wir uns zum Kartenspielen. Kein Witz. Wir spielten Planning Poker, um die Aufwände für jede User Story zu ermitteln. Falls jemand möchte, erkläre ich das gern nach dem Sprint Planning.“

„Gute Idee“, brachte sich Bernd wieder ein. „Doch lasst uns weitermachen. Um das Pokern kümmere ich mich später gern.“

„Ok, nun sehe ich klarer“, sagte der Vertriebler. „Darf ich kurz zusammenfassen? Nur das ich das besser verstehe.“ Bernd nickte.

„Der Product Owner definiert das Sprint-Ziel. Er beantwortet Fragen, damit deutlich wird, wohin die Reise geht. Das Team entscheidet, was es entwickelt. Und der Scrum Master passt auf, dass die Regeln eingehalten werden.“

„Passt!“, bestätigte Bernd.

„Das nenne ich Selbstverantwortung“, erwiderte der Vertriebler begeistert.

Auch Bernd war froh über ihre Entscheidung, noch vor dem Sprint Planning Meeting die Aufwände zu schätzen. So konnten sie sich auf die inhaltliche Ausgestaltung konzentrieren. Und falls es notwendig werden würde, passten sie die Schätzungen nochmal an.

Bernd schaute auf die Uhr. „Dann sind wir wieder ein kleines Stückchen weiter. Sehr schön! Nun kommt Teil zwei. Wie wollen wir vorgehen, um das Sprintziel zu erreichen?“

Jonas begann: „Wir zerlegen jede User Story in kleine, handhabbare Einheiten. Also alles, was zum Entwerfen, Programmieren, Implementieren, Testen und Dokumentieren gehört. So haben wir alle Bestandteile für ein Sprint Backlog, die Aufgabenliste für unseren Sprint, zusammen.“

Leise schüttelte sich sein Telefon auf der Tischplatte. Jonas warf nur einen Blick auf das Display, ohne ranzugehen. „Gerade habe ich eine Störung bekommen. Das Logfile von einem Server hat den Schwellwert erreicht. Blöd. Ich muss mich darum kümmern.“

Er rieb sich nachdenklich das Kinn. „Leute, so was passiert immer mal wieder. Die Störungen Kosten wertvolle Zeit, die uns dann im Sprint fehlen. Ich schlage vor, dass wir in unsere Planungen kleine Puffer einbauen. Wenn wir in vier Wochen liefern wollen, dann auch alles das, was wir uns vorgenommen haben.“

Marketing und Vertrieb nickten zustimmend auf der anderen Seite des Tisches.

Bernd warf ein: „Bitte achtet darauf. Nicht zu viel, aber auch nicht zu knapp. Eine realistische Planung sollte es schon sein.“

Nach einer weiteren halben Stunde hatten die Teilnehmer das Sprint Backlog fertiggestellt.

„Klasse, das hätten wir geschafft“, sagte Bernd. „Lief doch richtig gut. Hiermit beende ich unser Sprint Planning Meeting. Wer mag einen Tee?“

• Das Treffen liefert Antworten auf zwei Fragen: Was soll im kommenden Sprint erledigt werden? Wie soll die erforderliche Arbeit erledigt werden?
• Der Scrum Master ist für die Organisation des Sprint Planning Meetings verantwortlich.
• Team und Product Owner erarbeiten ein gemeinsames Verständnis über den Sprintinhalt und legen das Sprintziel fest.
• Aus dem Product Backlog werden Inhalte für den Sprint extrahiert.
• Die aktuellste Schätzung zur Leistungsfähigkeit des Teams wird vor dem Sprint Planning Meeting erstellt.
• Das Team selbst beurteilt und entscheidet, was es im kommenden Sprint fertigstellen kann.
• Es plant die Tätigkeiten in kleinen Einheiten – idealerweise auf Tagesebene.
• Sollte das Team feststellen, dass zu viel (oder zu wenig) Arbeit geplant wurde, handelt es die ausgewählten Product-Backlog-Einträge neu mit dem Product Owner aus.