Vom langweiligen Meeting zur Sprint Planning II Werkstatt

Avatar von Florian Eibeck

„Im zweiten Teil der Sprint-Planung plant das Entwicklungsteam im Detail, welche Aufgaben (Tasks) zum Erreichen des Sprint-Ziels und zur Lieferung der prognostizierten Product-Backlog-Einträge notwendig sind. […] Ergebnis ist das Sprint Backlog: der detaillierte Plan für den nächsten Sprint. Er enthält die für den Sprint geplanten Product-Backlog-Einträge und die Aufgaben zu deren Umsetzung.” Aus dem Wikipedia-Artikel über Scrum.

sprintplanning

Das alte Planning II

Das Team sitzt im Konferenzraum um den großen Tisch und starrt auf eine User Story an der Beamerleinwand. Unser Scrum Master hat den Flipchartmarker gezückt; vor sich einen Stapel Karteikarten. Geduldig blickt er in die Runde und wartet darauf, dass ihm das Team einzelne Tasks diktiert, die zur Erledigung der Story nötig sind. Es dauert eine ganze Weile, bis der erste zögerlich ein „Datenmodell aufstellen” in den Raum murmelt.

Eine viertel Stunde später haben sich zwei Teammitglieder über den genauen Inhalt der Story gestritten, der Scrum Master ist sauer, weil er mit dem Schreiben nicht hinterherkommt und das restliche Team blickt sehnsüchtig in leere Kaffeetassen.

Das Meeting endet nach zwei bis drei Stunden mit einem Stapel wenig aussagender Karten mit Tasks zu jeder Story, einem genervten Team und einem enttäuschtem Scrum Master.

Planung des Planning

Wir haben das so oder so ähnlich über viele Sprints durchgezogen, aber irgendwann ging es nicht mehr weiter und wir haben uns ein neues Sprint Planning II einfallen lassen.

Aus der Erfahrung der alten Meetings war uns vor allem wichtig, dass sich alle im Team gleich an der Erstellung der Tasks beteiligen können. Der Scrum Master soll nicht mehr als Schreibknecht missbraucht werden und irgendwie soll Arbeit auch Spaß machen. Ach ja, bessere Tasks wären auch cool.

In mehreren Diskussionsrunden haben wir über das Problem geredet und schlussendlich eine gemeinsame Lösung erarbeitet. Hier wird nun unser neues Format, die „Sprint Planning II Werkstatt” vorgestellt.

[smartblock id=“8664″]

Sprint Planning II Werkstatt

Das Team trifft sich im Konferenzraum. An vier Stellen im Raum hat der Scrum Master Stationen für Tickets vorbereitet, an denen Karteikarten, Stifte und Tesafilm bereitstehen. An jeder Station hängt eine User Story mit allen verfügbaren Informationen. Das Team kann sich nun frei im Raum verteilen, sich mit den Stories beschäftigen und Tasks auf Karten schreiben und aufhängen.

Jeder kann so zu den Stories beitragen, bei denen er sich am besten auskennt. In kleinen Gruppen diskutiert das Team über einzelne Karten, hängt wieder welche ab (es gibt einen „Papierkorb” je Station) und ergänzt, was noch fehlt. Auf jeder Karte steht der Name des Autors, so dass man bei Unstimmigkeiten weiß, an wen man sich gezielt wenden kann.

sprintplanning2

Nach einer Timebox von 10 Minuten wird die Runde beendet. Das kann auch eher erfolgen, wenn das Team anzeigt, dass es mit allen Stories fertig ist. Man trifft sich gemeinsam an der ersten Station, wo die einzelnen Tasks nochmals für alle vorgelesen werden. Mit einem Daumenvoting wird entschieden, ob jeder im Team mit dem Ergebnis einverstanden ist. Zeigt ein Daumen nach unten, so bleibt die Story für die nächste Runde hängen, um nochmals bearbeitet zu werden. Es findet in dieser kurzen Abfrage keine Diskussion statt.

Alle fertigen Stories werden danach abgehängt und die Stationen werden neu gefüllt. Das Team hat wieder 10 Minuten Zeit um Tasks für die neuen Stories zu schreiben oder um über die unfertigen Stories aus der letzten Timebox zu diskutieren.

Das Meeting ist beendet, wenn keine weiteren Stories mehr zu bearbeiten sind und das Team für den kommenden Sprint ein gutes Gefühl hat. Im Schnitt dauert die Planung für einen Sprint nun zwischen 60 bis 90 Minuten.

Das Regelplakat

Um die Regeln jeden Teilnehmer immer vor Augen zu haben, hängt unser Scrum Master an jede Station ein kleines Regelplakat. Unsere aktuelle Version hier als Download.

Fazit

Mit unserer neuen Art der Schätzrunde haben wir für unsere Sprints viel erreicht. Wir gehen inzwischen mit Spaß in das Sprint Planning II und kommen mit verlässlichen Tasks wieder aus dem Konferenzraum. Das ganze Team beteiligt sich aktiv, und der Scrum Master wird nicht mehr als Schreibkraft missbraucht. Außerdem haben wir die benötigte Zeit für das Planning II dabei um die Hälfte reduziert und dabei die Qualität des Ergebnisses massiv gesteigert.

In eigener Sache …

Mit WebAssembly die Kosten für die Wartung Deiner Cloud-Anwendung sparen und die Wirtschaftlichkeit und Effizienz des Unternehmens steigern?

Am 26. September 2024 um 11:30 Uhr bieten Dir unsere Experten einen tiefen Einblick in ein spannendes R&D-Projekt.

Melde Dich jetzt kostenlos an!

Avatar von Florian Eibeck

Kommentare

13 Antworten zu „Vom langweiligen Meeting zur Sprint Planning II Werkstatt“

  1. Lesenswert: Vom langweiligen Meeting zur Sprint Planning II Werkstatt http://t.co/yhluHzSrJU

  2. Vom langweiligen Meeting zur Sprint Planning II Werkstatt http://t.co/aO2tQP2WEm via @mayflowerphp

  3. Sprint Planning 2 einmal anders #scrum http://t.co/01cErH83xY via @mayflowerphp

  4. Klasse! Vom langweiligen Meeting zur Sprint Planning II Werkstatt http://t.co/gIOVZBz9HI via @mayflowerphp

  5. Avatar von Andreas

    Hört sich sehr interessant an. Vor allem beim Teil „das alte Sprint Planning“ habe ich starke parallelen zu unserem Team entdeckt. Wir wollen das bei uns auch mal testen. Plant ihr bei euch im Sprint auch die Behebung von Bugs ein? Wie geht ihr mit Bugs beim Sprint Planning mit dieser Methode um?

    1. Avatar von Martin Ruprecht
      Martin Ruprecht

      Hallo Andreas,
      vielen Dank für deinen Kommentar. Wir haben bei Mayflower mehrere Teams und die Handhabung mit Bugs ist nicht immer zu 100% gleich. Generell kann man jedoch sagen, dass die Teams auch Bugs innerhalb der Sprints fixen, manche werden vorher mit eingeplant (meist Bugs bei denen ein Fix nicht auf die Stunde genau erfolgen muss) und manche kommen adhoc in den Sprint. Das wären dann sogenannte „Showstopper“, z.B. wenn der Warenkorb nicht mehr funktioniert oder die Seite komplett down ist. In diesem Fall ist es uns wichtiger den Fehler zu beheben als am Sprint-Goal zu arbeiten und das Team versucht alles um den Fehler zu beheben. Zum Glück kommt dies sehr sehr selten vor.

      Zu deiner zweiten Frage: Es würde dann neben den User Stories auch eine Beschreibung des Bugs auf einem Zettel stehen und das Team kann schon einmal erste Hinweise geben, welche Stellen im Code betroffen sein könnten. Hier geht es auch oft darum, wer sich sehr schnell um die Behebung kümmern kann weil vll. schon Wissen an der Stelle im Code vorhanden ist. Ich hoffe du kannst mit meinen Antworten etwas anfangen. Wenn du weitere Fragen hast, schreibe sie einfach als weiteren Kommentar, wir antworten dir gerne.

  6. Avatar von Andreas

    Wir haben diese Methode leicht abgeändert ausprobiert:
    – Unsere Stationen waren Laptops, so dass wir die Tasks gleich elektronisch erfassen konnten
    – Timbeox waren jeweils 5 Minuten.
    – Während einer Timebox waren die Gruppen an einer Station fix und haben nicht zwischen den Stationen geweschselt (vielleicht haben wir das auch falsch verstanden)

    Unsere positiven Erfahrungen:
    – Wir waren effizienter als normal
    – Den meisten hat es mehr Spass gemacht
    – Die Tasks waren einen Tick besser. Vielleicht auch die Zeitabschätzung der einzelnen Tasks etwas besser

    Negativ ist uns aufgefallen:
    – Da nicht jeder an jedem Ticket mitüberlegt hat, war das Daumenvoting hinterher oft schwierig, da man die Überlegungen der anderen nicht mitbekommen hat. Vor allem bei Bugs ist das schwierig gewesen, da diese in unserem Planning I (das immer in der Sprintmitte stattfindet nicht besprochen werden).
    – Oft wäre ein Experte an mehreren Stationen benötigt worden, da wir aber während einer Timbox nicht zwischen den Stationen wechseln wollten, war das nicht möglich
    – Gefühlt war es etwas chaotisch

    Alles in allem war es aber eine gute Erfahrung. Ich kann mir vorstellen, dass wir das nochmal ausprobieren und dabei versuchen die Idee für unsere Zwecke noch zu optimieren.

    1. Avatar von Florian Eibeck
      Florian Eibeck

      Hallo Andreas,

      Freut mich dass ihr das ausprobiert habt und vielen Dank für dein Feedback!

      Ich glaube die negativen Punkte die du beschreibst bekommst du in den Griff wenn du das Team frei zwischen den Stationen wechseln lässt. Leute mit einem Vertrauensproblem, die sich am Ende mit dem Daumenvoting schwer tun können so überall mit drauf schauen. So hast du auch eine gute Chance, dass sich die Experten zu den richtigen Tickets einfinden, oder andere aus dem Team können sich die Experten einfach holen.

      Für uns war gerade diese freie Entscheidungsmöglichkeit der größte Vorteil, weil jeder sich dort einbringen kann wo es am meisten Sinn macht. Was war denn für dich der Grund für feste Gruppen?

      Viele Grüße
      Florian

  7. Avatar von Andreas

    Ich hatte das beschriebene Konzept so verstanden, dass sich die Teammitglieder zu beginn einer Timebox entscheiden sollen, welches der verfügbaren Tickets sie bearbeiten wollen. Erst für die nächste Timebox können sie sich dann für eine andere Station entscheiden.

    Mir bzw. uns ist erst hinterher bewusst geworden, dass das von euch gar nicht so gedacht gedacht war. Letztendlich war es also ein Verständnisproblem.

    1. Avatar von Florian Eibeck
      Florian Eibeck

      Probiert es mal mit freiem Wechsel während der Timebox aus. Das wird dann viel besser :-)

  8. Hallo, ich finde dieses Format sehr interessant und würde es gern ausprobieren. Allerdings habe ich ein kleines Hindernis, wo ich derzeit nicht weiß, wie es am elegantesten zu umschiffen wäre: Kollegen die nur Remote verfügbar sind. Hast du bzw. habt ihr da eine Idee, wie man diese Kollegen mit einbeziehen kann?

    1. Avatar von Florian Eibeck
      Florian Eibeck

      Hallo Tobias!

      Remote-Kollegen sind bei diesem Format ein Problem, da es explizit für die persönliche Zusammenarbeit in einem Raum gestaltet ist. Wir hatten aber die Situation auch schon und mit gemeinsam editierbaren Dokumenten (Google Docs, Confluence, …) experimentiert. Ein paar Stories wurden in das Dokument kopiert und das Team hat begonnen gemeinsam Tasks unter die Stories zu schreiben. Eine Diskussion fand dann entweder als „Diskussion” direkt im Dokument statt, oder wurde im Chat geführt. Die Abstimmung wurde dann im gemeinsamen Videochat getätigt. Wie bei allen Remote-Situationen geht dabei ein sehr großer Teil der Zusammenarbeit und des Teamgefühls verloren, es war aber immer noch eine gute Alternative.

      Ich hoffe das hilft ein bisschen…
      Viele Grüße
      Flo

Schreibe einen Kommentar

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


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.