Schlagwort-Archive: planning

4 bewährte Verfahren für Sprint Plannings

1 Antwort

In diesem Artikel gehen wir vier Grundsätze der Sprintplanung durch, die wir für besonders hilfreich halten.

Die agile Zeremonie des sogenannten Sprintplannings oder schlicht „Plannings“ dient in jedem Sprint dazu, die Ausführung neu zu fokussieren, Überraschungen zu minimieren und eine insgesamt höhere Codequalität zu garantieren.

Überprüfen Sie Ihre Roadmaps, bevor Sie sich treffen

Die Zeit vergeht schneller als wir denken. Daher ist es eine gute Idee, die Roadmap Ihres Projekts in den ersten zwei Wochen des neuen Jahres zu überprüfen. Die Roadmap bildet den Kontext für zwei wichtige agile Konzepte: Epics und Versionen, die das Rückgrat für die agile Programmplanung bilden und dabei helfen, die Lieferung längerfristiger Arbeit zu verfolgen. Vergewissern Sie sich, dass die Roadmap aktuell und für das gesamte Team sichtbar ist und dass Epics und Versionen vor dem Sprint Planning Meeting korrekt in Jira aufgelistet sind.

Halten Sie eine Besprechung vor der Besprechung ab

Die Sprintplanung umfasst zwei wichtige Aufgaben: die Pflege des Backlogs und die Entscheidung, welche Arbeiten im kommenden Sprint abgeschlossen werden sollen. Bei Atlassian haben wir die Erfahrung gemacht, dass das Backlog Grooming am besten in einem separaten Meeting mit dem Product Owner und dem Scrum Master vor dem eigentlichen Sprint Planning Meeting stattfindet. Für das gesamte Entwicklungsteam ist diese Vorbesprechung optional.

Was ist Backlog Grooming?

Backlog Grooming stellt sicher, dass das Backlog gesund ist. Wie sieht das aus? Gut, dass Sie fragen. Ein gesundes Backlog:

  • priorisiert jedes Arbeitselement, wobei die wichtigste Arbeit an erster Stelle steht
  • enthält vollständig ausgearbeitete User Stories, mit deren Umsetzung das Entwicklungsteam beginnen kann
  • Enthält eine aktuelle Schätzung für jedes Arbeitselement

Die Teams bei Atlassian halten einige Tage vor der Sprintplanung kurze Backlog Grooming Meetings ab. Planen Sie 30 Minuten für dieses Meeting ein, um die Aufgaben zu sichten, die Sie in den nächsten zwei Sprints am ehesten angehen werden. Manchmal werden Sie Punkte finden, die nicht detailliert genug sind, um ausgeführt zu werden, oder die mehr kontextbezogene Informationen vom Product Owner benötigen. Das ist das Schöne an der Erstellung des Backlogs im Voraus. Diese Lücken können zwischen den Meetings gefüllt werden, so dass sie während der eigentlichen Sprint-Planung keine Hindernisse (oder Zeitfresser) darstellen. Durch die Erstellung des Backlogs im Vorfeld hat das Team während der Sprintplanung mehr Zeit, seine Optionen für den Sprint zu prüfen und bei Bedarf Elemente für den nächsten Sprint zu markieren.

Team-Aktivität: Manche Teams haben Probleme mit der Schätzung. Story Points bieten einen soliden Rahmen für die Schätzung der Arbeit. Binden Sie das Team in eine Aktivität namens stille Schätzung ein. Legen Sie zu Beginn der Übung die Story-Point-Werte (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) in Spalten auf eine weiße Tafel. Bitten Sie dann das Team, die Benutzergeschichten in der Spalte zu platzieren, die sie für am genauesten halten. Die meisten Geschichten werden sich auf eine Zahl konzentrieren, und wenn es Unstimmigkeiten über den Punktwert der Geschichte gibt, ist es an der Zeit, eine Diskussion darüber zu eröffnen, warum. (Siehe auch unseren Artikel zu: Die 6 besten Planning Poker Tools zur freien Verfügung)

Informieren Sie die Sprintplanung mit Daten

Der Schwerpunkt des Sprint Planning Meetings liegt auf der Festlegung und Vereinbarung des Sprint-Ziels – der Menge an Arbeit, die das Team glaubt, während des Sprints erledigen zu können. Der Product Owner, der Scrum Master und das gesamte Entwicklungsteam müssen dabei anwesend sein. Wir bei Atlassian empfehlen ein Minimum von einer Stunde für jede Woche des Sprints, die Sie in der Besprechung abdecken wollen. Beginnen Sie beispielsweise mit einem zweistündigen Sprint Planning Meeting, um einen zweiwöchigen Sprint abzudecken. Idealerweise sollten Sie die Sprintplanung zu Beginn der Woche ansetzen. Dann werden der Kontext und der Arbeitsfluss des Teams weniger durch das Wochenende gestört.

Tipp: Planen Sie die Sprint-Retrospektive und das Sprint-Planning-Meeting nicht zusammen. Geben Sie dem Team genügend Zeit, um die Retrospektive zu verdauen und effektiv zur Sprintplanung beizutragen – vielleicht indem Sie dazwischen ein Teamessen einschieben.

Aus Erfahrung

Zu Beginn der Besprechung stellt der Scrum Master alle relevanten Aktionspunkte aus der Retrospektive des Teams vor. Als Nächstes gibt der Product Owner Produkt- oder Markt-Updates, damit alle auf dem gleichen Stand sind und den breiteren Kontext noch im Kopf haben.

Nach der Nachbesprechung ist es Aufgabe des Product Owners, das eigentliche Planungsgespräch zu beginnen. Zu Beginn verwendet der Product Owner die durchschnittliche Geschwindigkeit des Teams (die Menge an Arbeit, die typischerweise in einem Sprint abgeschlossen wird), um einen Vorschlag für eine Reihe von Storys für den Sprint, den so genannten „Sprint Forecast“, zusammenzustellen, der den Wert für den Kunden maximiert. Der Product Owner sollte auch diese drei Faktoren berücksichtigen:

  • Feiertage, persönlicher Urlaub und teamweite Ereignisse
  • Priorität der Stories im Backlog (idealerweise schlagen sie die am höchsten eingestuften Elemente vor)
  • Wie (und ob) diese Arbeit das Produkt seinem Endziel näher bringen wird

Tipp: Product Owner können den Sprint Marker verwenden, um die Velocity zu berechnen.

Wenn das Team neu ist und keine etablierte Geschwindigkeit hat, sollte der Product Owner keine Sprintprognose vorschlagen. Stattdessen sollte dies eine Übung für das gesamte Team sein, da es wichtig ist, dass jedes Mitglied zustimmt. Zunächst wird das Team die Vorhersage nach bestem Wissen und Gewissen treffen und ein paar Sprints nach dem Prinzip „Versuch und Irrtum“ durcharbeiten. Sobald die Geschwindigkeit des Teams – die durch das Velocitydiagramm in Jira sehr schön veranschaulicht wird – numerisch festgelegt ist, verwenden Sie diese Metrik, um die Sprint-Prognose zu erstellen.

Sobald der Product Owner seine Ideen für den Sprint Forecast vorgestellt hat, kann das Team diesen validieren (und/oder anpassen) und sich auf einen Aktionsplan für den Sprint einigen.

Tipp: Das Team sollte bei jedem Sprint darüber nachdenken, wie die technischen Schulden reduziert werden können. Die Erstellung eines Schnellfilters, der Bugs im Backlog des Teams hervorhebt, ist eine einfache Möglichkeit, wichtige Bugs zu markieren, die in den Sprint aufgenommen werden sollen, während das Team an User Stories in verschiedenen Bereichen der Codebasis arbeitet. Der Schnellfilter „tech debt“ verwendet die JQL-Abfrage „type in (bug)“, um die Ansicht auf Bugs zu beschränken. Erweitern Sie einfach die JQL-Abfrage, um bei Bedarf weitere Fehlertypen einzubeziehen.

Der nächste Schritt in der Sprint-Planung besteht darin, die Stories durchzugehen und zu beschreiben, welche Arbeiten zur Fertigstellung jeder Story erforderlich sind. Während das Team plant, sollten Sie sicherstellen, dass jemand die wichtigsten Punkte in jedem Jira-Ticket festhält. Auf diese Weise sind sowohl die Entscheidung als auch die Begründung später leicht zu erkennen. Das Team sollte sich Fragen stellen wie…

  • Hat sich die Definition der Story geändert, seit sie geschrieben wurde? Gibt es neue kontextbezogene Informationen, die das Team berücksichtigen muss?
  • Ist die Schätzung für die Story noch gültig? Ist das gesamte Team mit der Schätzung einverstanden? Wenn nicht, sollte der Scrum Master das Team bei der Neuschätzung anleiten.
  • Welche Aufgaben sind für die Fertigstellung dieser Story erforderlich? Verwenden Sie Teilaufgaben, um die Arbeit zu parallelisieren und den Ablauf zu optimieren. Wenn das Team bei der Aufteilung der Arbeit auf einzigartige Stories stößt, sollten diese Aufgaben zu völlig unabhängigen Stories erhoben werden.
  • Welche Auswirkungen hat das Testen auf diese Story? Wie können wir das Testen automatisieren? (Denken Sie daran, dass manuelle Testskripte im Wesentlichen technische Schulden sind).
  • Sind spezielle Fähigkeiten erforderlich? Wie können wir die Zeit des Spezialisten optimieren, ohne den Rest des Teams zu behindern?
  • Wie wirkt sich diese Geschichte auf die Architektur des Produkts aus? Gibt es bestimmte Personen, die das Team in den Entwurf und die Codeüberprüfung einbeziehen muss?
  • Gibt es Abhängigkeiten zwischen den Stories? Können wir angesichts dieser Abhängigkeiten die gesamte Arbeit während des Sprints abschließen?

Die Versuchung ist groß, diese detaillierte Übung überstürzt durchzuführen. Aber eine gute Planung zahlt sich aus, sobald der Sprint beginnt. Hier geht es vor allem darum, zu verstehen, wie die Arbeit erledigt werden soll, wobei der Scrum Master die Diskussion im Team fördert. Es ist wichtig, dass jeder gehört wird, damit sich das Team verantwortlich fühlt, sobald der Plan steht.

Tipp: Während der Sprint-Planung ist es einfach, Stories in den Sprint hinein- und wieder herauszuschieben, während das Team seine Sprint-Prognose erstellt. Klicken Sie einfach mit der rechten Maustaste auf ein Issue, um es in den oder aus dem Sprint zu verschieben.

Auf die Plätze, fertig, Sprint!

An diesem Punkt des Meetings sollte das Team mit dem Sprint Forecast zufrieden sein. Am Ende der Sprintplanung empfiehlt es sich, von allen Anwesenden mündlich zu bestätigen, was das Team am Ende des Sprints tatsächlich ausliefern wird. Stellen Sie außerdem sicher, dass jedes Teammitglied mindestens eine Aufgabe hat, mit der es beginnen kann, und dass niemand doppelte Arbeit leistet.

Das Engagement und die Moral des Teams schwanken natürlich von Sprint zu Sprint. Diese Schwankungen zeigen sich oft während der Sprint-Planung, aber widerstehen Sie der Versuchung, sich sofort damit zu befassen. Nutzen Sie stattdessen die Retrospektive des Teams, um alle Probleme zu verstehen, die sich auf die Moral auswirken. Teams, die schnell auf Kultur- und Entwicklungsprobleme reagieren, sind zufriedener, produktiver und schreiben besseren Code.

Was ist Magic Estimation?

Schreibe eine Antwort

Die Backlogs von Projekten sind oft voll und unübersichtlich. Um eine Struktur hineinzubringen, nehmen sich Scrum Teams Zeit, um die Items gemeinsam zu schätzen. Planning Poker ist eine beliebte Methode dafür, eine weitere Möglichkeit stellt aber auch Magic Estimation dar. Was daran so magisch ist und wie das Ganze funktioniert, erfahren Sie hier.

Wo liegt die Magie?

Warum sollten Sie Magic Estimation verwenden, wenn Planning Poker doch genauso zum Ziel führt und in den meisten Teams bereits im Einsatz ist? Die Magie des Schätzverfahrens liegt in der Zeiteinsparung!

Beim Planning Poker gibt es im Vorfeld viel zu klären. Erst wenn keine Fragen mehr offen sind, beginnt die verdeckte Schätzung. Dabei ist jedes Teammitglied an jeder einzelnen Schätzung beteiligt. Das hat zwar den Vorteil, dass jeder seine Stimme abgibt, es nimmt jedoch auch viel Zeit in Anspruch.

Nach jedem Durchgang kommt es zusätzlich zu einer Diskussion zwischen der höchsten und der niedrigsten Schätzung. Zielführend? Bestimmt. Aber wir wissen alle, dass Zeit in Projekten eine Mangelware darstellt.

Wie funktioniert es?

Magic Estimation soll den Zeitaufwand beim Schätzen reduzieren. Es ist wie Planning Poker ein relatives Schätzverfahren, das Team setzt die Items also in Verhältnis zu einer Referenzstory.

Was muss vorbereitet werden?

  • Die Fibonacci-Reihe sollte auf dem Tisch, an der Wand oder am Whiteboard angebracht sein – je nachdem, wo das Team arbeitet
  • Die Storys müssen auf einzelnen Kärtchen vorliegen
  • Im Vorfeld wird eine Story beispielsweise per Planning Poker geschätzt, welche dann als Referenz gilt
  • Die Items aus dem Backlog müssen klar verständlich sein

Nun kommen wir zum Ablauf. Zu Beginn eines Durchlaufes liegt die Referenzstory bereits an dem geschätzten Fibonacci-Wert. Jeder Teilnehmer erhält zufällig einige ausgedruckte Storys.

Wichtig: Beim Schätzen der Storys wird nicht gesprochen!

Schritt 1: Jeder Teilnehmer platziert seine Storys innerhalb der Fibonacci-Reihe. Er orientiert sich dabei an der Referenzstory und darf die Karten nur direkt, nicht zwischen den Werten platzieren.

Schritt 2: Die Teilnehmer erhalten jetzt einige Minuten Zeit, um zu schauen, wie die Teammitglieder andere Storys geschätzt haben. Stimmt man deren Ansicht zu, verändert man nichts. Ist der Teilnehmer jedoch der Ansicht, dass eine Story zu hoch oder zu niedrig geschätzt ist, kann er diese verschieben. Er braucht die Verschiebung nicht begründen, muss die Karte aber mit einem Punkt oder einem Strich versehen. Damit können auch andere erkennen, dass diese Karte schon mal verschoben wurde. Diese Phase endet, wenn es keine Bewegung mehr auf dem Board gibt.

Schritt 3: Eine Karte kann mehrfach die Position wechseln. Sind auf einer Karte jedoch 3 Punkte vorhanden, scheint es noch Gesprächsbedarf zu geben. Dies ist in Form einer Diskussion möglich. Alle Karten mit drei Markierungen werden für diese Diskussion herausgezogen. Ab jetzt dürfen die Teilnehmer natürlich wieder sprechen. Ziel der Diskussion ist es, die Story zufriedenstellend im Board zu platzieren.

Herausforderungen und Vorteile von Magic Estimation

Damit Magic Estimation funktioniert, müssen die Items aus dem Backlog klar definiert und für alle verständlich sein. Ist dies nicht der Fall, ist der Diskussionsbedarf sehr hoch.

Ist dies jedoch gegeben, liegt der größte Vorteil klar auf der Hand: Anstatt dass alle Items nacheinander von jedem Einzelnen geschätzt werden müssen, schätzen die Teammitglieder die Storys im Magic Estimation parallel. Anschließend überprüfen sie diese. Es kommt nur zu einem Gespräch, wenn abweichende Meinungen vorliegen. Ist ein Team in diesem Verfahren bereits eingespielt, ist die Zeitersparnis enorm. Aus der Praxis berichten einige Teams, dass sie anstelle von ein bis drei Stunden nur noch maximal eine halbe Stunde für einen Schätzvorgang benötigen.

Ein weiterer Vorteil: Es lässt sich schnell erkennen, welche Storys zu groß sind und weiter zerlegt und ausdefiniert werden müssen.

Planning-Poker-Tool bekommt neue Version

1 Antwort

Sprint Planning in Remoteteams ist an und für sich eine runde Sache. Als die Remotearbeit aufgrund der Pandemie anstieg, haben wir uns daran begeben und auch das Planning Poker runder gemacht. Jetzt haben wir unserem Agile Casino ein Update gegönnt. Mit dem Update kamen Features dazu, die Stabilität wurde erhöht. Im Folgenden gehen wir etwas ins Detail.

Hintergrund

Wir haben am Anfang der Pandemie einen Prototypen (eher schon ein MVP) für das Planning Poker. Was heißt hier „wir“? Das Team lässt mich an der Stelle mit Recht etwas im Stich, denn die haben Wichtigeres zu tun. Ich halte es allerdings für eine tolle Gelegenheit, auch mal zu demonstrieren, wie wir an die Entwicklung von modernen Cloudanwendungen herangehen.

Grundsätzlich – wenn auch klein – erfüllt es alle Eigenschaften einer Cloud-Anwendung (eine SaaS, Software as a Service). Es gibt zwar keine Abomodell (da es kostenlos ist), das könnte es aber geben (andere Scrumpoker online haben ja Pläne wie 8 Euro pro Monat etc.) und Abo ist ja ein Kennzeichen für eine Cloudanwendung. Unser Abomodell kostet quasi 0 Euro.

Das Update

In diesem Update ging es um ein paar Features und um Stabilität. Für den Betrieb im Cluster mussten wir Änderungen vornehmen. Auch die QS-Schritte haben wir auf ein professionelles Niveau gehoben, in dem wir die anfänglich rundimentären automatisierten Tests (sogenannte Integrationstests) erweitert haben.

An Features gibt es nun neben der Rolle des Entwicklers auch die Rolle des „Inspectors“. Denn es ist häufig der Fall, dass weitere Personen dem Planning beiwohnen, die den Entwicklern im Raum keinen Platz wegnehmen sollen. Inspektoren sind alle Nichtentwickler eines Scrumteams und Sonstige. Was bleibt also nach Scrum Guide noch? Genau: Der Scrum Master und der Product Owner. Sonstige können alle möglichen Stakeholder sein.

Es sind zwar weiterhin nur sieben Entwickler möglich (das es in einem Scrum Team nur maximal neun Personen geben darf, neun minus zwei ergibt sieben Entwickler). Ich finde diese Aussage im aktuellen Scrum Guide nicht mehr. Dahre denke ich, werde ich diese Begrenzung evtl. aufheben.

Außerdem habe ich den Invite Link verbessert. Der lässt sich jetzt einfacher in die Zwischenablage kopieren und ist professionell eingebunden.

Geplante Features

Jira: Ich ich denke bereits über eine Jira-Anbindung nach. Es wäre sehr nützlich, wenn geschätzte Werte gleich via Klick in die entsprechende Story im Jira übernommen werden könnte. Aber auch sehr aufwändig. Vielleicht packe ich das Feature mal in eine Art Premiumpaket, dass treue Leser und Kunden natürlich kostenlos erhalten.

Timer: Ein Timer wäre sehr nützlich, der für alle synchron läuft.

Score: Im Score-Board sollten die Spieler mit den Minimal- und Maximalwerten markiert werden. Die Spielergebnisse je Schätzrunde sollten auch hübscher dargestellt werden.

T-Shirt-Größen: Derzeit gibt es nur die vorgegebene Werteskala. Der User sollte weitere Skalen wählen können. Eventuell sollte er auch Skalen erstellen können.

Fazit

Der agile Ansatz funktioniert einmal mehr. Agile Casino bietet bereits jetzt eine gute Basis und den Nutzen, Schätzpoker in Remote-Teams störungsfrei und kostenlos durchzuführen.

Mit dem aktuellen Update kommen weitere Möglichkeit hinzu. Aus Qualitätssicherungssicht ist die Anwendung ab dieser Anwendung jetzt komplett stabil.

Was haltet ihr von dem ganzen Vorgang? Nutzt ihr das Tool oder wollt ihr es nutzen? Welche Features sollten wir noch reinbringen und was hat eurer Meinung nach Priorität? Schreibt es in die Kommentare.