Schlagwort-Archive: scrum

4 bewährte Verfahren für Sprint Plannings

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.

Scrum ausweiten – was ist SAFe?

Schreibe eine Antwort

Wenn ein Projekt immer größer wird und das Team stetig wächst, kann Scrum an seine Grenzen stoßen. Wie kann es dann weitergehen? Es gibt verschiedene Skalierungsframeworks, mit dessen Hilfe Sie Scrum ausweiten können. Zu den beliebten Frameworks dieser Art gehört SAFe. Wie die Skalierung damit funktioniert, erfahren Sie in diesem Artikel.

Warum sollte Scrum skaliert werden?

Scrum definiert eine feste Teamgröße. Nun ist es aber immer häufiger erforderlich, dass mehrere Teams zusammenarbeiten, da ein Projekt sonst nicht bewältigt werden kann oder sich richtig lange ziehen würde.

Skalierungsframeworks bieten den Vorteil, dass Teams agil weiterarbeiten können, das Unternehmen aber neue Strukturen zur Verfügung gestellt bekommt, um das Ganze zu steuern.

Es gibt verschiedene Skalierungsframeworks, die Scrum skalieren können. Scrum of Scrums haben wir Ihnen bereits vorgestellt, ein weiteres beliebtes Framework ist SAFe.

SAFe – ein neues Mindset

Das Skalierungsframework SAFe kommt in mehreren Versionen einher, je nach Projektgröße und Ziel greift eine andere Version. Dabei betrachtet es drei Ebenen: das Team, das Portfolio und das Programm. Was bedeutet das? Das Framework wird nicht einfach nur auf die Arbeit des Teams angewendet, sondern eben auf alle drei Betrachtungsebenen.

Eine der Versionen wird als Full Solution bezeichnet. In dieser Version eignet es sich, das gesamte Unternehmen umzustrukturieren. Anders als bei anderen Frameworks liegt der Fokus nicht auf den Inkrementen, die ein Team produziert, sondern auch in der Weiterentwicklung des Unternehmens. Die Ideensammlung, Reflektion und die Wertschöpfung bekommen ausreichend Raum.

Das klingt nach einem neuen Mindset? Auch darum geht es. Schließlich bekommt Führung hier eine neue Bedeutung und Prozesse und die Zusammenarbeit wird transparent. So viel Umstrukturierung und Arbeit kann auf Unternehmen abschreckend wirken. Auch dafür hat SAFe eine Lösung! Das Framework kommt mit einer Roadmap um die Ecke, die genau beschreibt, was in welchem Prozessschritt zu tun ist, damit die Implementierung stufenweise funktioniert. Und vor allem, damit alle verstehen, was vor sich geht und ein Teil der Transformation sein können.

Doch was hat es mit Scrum zu tun? Um das zu erklären, schauen wir uns an, wie SAFe funktioniert.

Ein Projekt mit SAFe auf die Schienen bringen

Was haben Projekte mit Zügen zu tun? In SAFe werden mehrere Scrum Teams zu einem übergeordneten Team zusammengefasst: dem Agile Release Train (ART). Jedes Scrum Team in diesem Zug beziehungsweise in diesem ART hat weiterhin jeweils einen Scrum Master und einen Product Owner, zusätzlich kommen drei neue Rollen hinzu:

Der Release Train Engineer (RTE): Er coacht die Art-Teams, ist als dienende Führungskraft zur Stelle und übernimmt die Stakeholderkommunikation.
Product Manager: Er kümmert sich um das Anforderungsmanagement, erstellt Produktdefinition und treibt das Design Thinking voran.
System Architect/Engineer: Er definiert sowohl eine architektonische als auch technische Lösung, die für das Projekt passend ist und kommuniziert/vernetzt diese in den Teams.

In einem ART können zwischen 50 und 125 Personen zusammenarbeiten, wenn es mehr sind, können die Scrum Teams auf mehrere ARTs aufgeteilt werden, die wiederum gemeinsam einen Solution Train bilden. In SAFe gibt es eine feste Länge für Product Increments (PI) und ein PI-Planning, bei welchem alle anwesend sind.

Vor- und Nachteile von Safe

Das Agile Framework bringt einige Vor- und Nachteile mit sich. Die Top 3 sind:

Vorteile:

Roadmap erleichtert die Implementierung
Ist auf das gesamte Unternehmen anwendbar
Die Möglichkeit zur Weiterentwicklung dadurch, dass Teams auch Organisationsziele behandeln können

Nachteile:

Ein guter Plan ist erforderlich und neue Prozesse müssen geschaffen werden
Das Top-Down Vorgehen steht in Konflikt zu den agilen Prinzipien
Komplexität erfordert Schulungen der Beteiligten

Fazit

Wenn Scrum an seine Grenzen kommt, steht SAFe schon parat. Je nach Personenanzahl lassen sich unterschiedlich viele Scrum Teams in ARTs zusammenfassen. So ist der Agilität auch in großen Projekten weiterhin kaum eine Grenze gesetzt.

Agiles Projektmanagement – warum nicht alles SMART sein kann

Schreibe eine Antwort

Ziele gehören zu einem Projekt wie das Amen in die Kirche. Es heißt immer wieder, dass Ziele SMART formuliert sein müssen. Ist das wirklich so? Was versteckt sich hinter der SMART-Formel und warum kann es von Vorteil sein, eher auf agile Methoden zu setzen? Genau diese Fragen werden wir nun behandeln.

SMART – was bedeutet das?

Um Ziele im klassischen Projektmanagement zu formulieren, setzen Projektleiter häufig auf die Smartformel. SMART ist ein Akronym und steht für:

S – Spezifisch

M – Messbar

A – Akzeptiert, Attraktiv

R – Realistisch

T – Terminiert

Das bedeutet, dass ein Ziel alle oben genannten Kriterien erfüllen muss. Entworfen wurde diese Formel, um Ziele zu konkretisieren und zu verhindern, dass diese schwammig formuliert sind.

Das ist logisch und natürlich sinnvoll, aber eben nicht überall. Was ist, wenn das Ziel eines Projektes offen ist? Es kommt außerdem oft genug vor, dass neue Anforderungen die Projektleitung dazu zwingen, die Richtung zu ändern.

Und hier zeigen sich auch die Nachteile der SMART-Formel. Die mangelnde Flexibilität.

Zudem sind realistische und akzeptierte Ziele nicht immer auch ambitioniert. Wer nach den Sternen greifen möchte, kommt mit der Formel also nicht an sein Ziel. Die smarte Formulierung lässt zudem kaum Spielraum für Auslegungen, sollten sich die Umstände verändern.

Ein weiteres Problem: Die Projektleitung formuliert die Ziele zu Projektbeginn und das Projekt nimmt seinen Lauf durch diverse Phasen hindurch. Ein Eingreifen oder Verändern der Phasen ist im klassischen Projektmanagement nicht möglich. Bei Zielverfehlung geht man zurück in die Phase der Zielsetzung und beginnt die Phasen von Neuem.

Vorteile vom agilen Projektmanagement

Agile Methoden sind im Vergleich zum klassischen Projektmanagement eher jung. Sie befriedigen aber das Bedürfnis, das durch die Digitalisierung und die damit veränderten Anforderungen entsteht.

Was sind diese Bedürfnisse? Ein Prozess und Ziele, die eine stetige Weiterentwicklung zulassen und die Möglichkeit, in den Prozess einzugreifen, um Änderung schnell herbeizuführen.

Im klassischen Projektmanagement scheitern viele Projekte daran, dass sie ihr Ziele nach mehreren Jahren nicht erreichen konnten. Die Ursachen dafür sind vielfältig. So können die Bedingungen zum Zeitpunkt der Zielsetzung anders gewesen, neue Anforderungen könnten erst im Laufe des Projektes dazugekommen sein. Smarte Ziele sind darauf nicht vorbereitet, während agile Methoden durchaus darauf reagieren können.

Wie schafft das agile Projektmanagement den Spagat zwischen Zielen und neuen Anforderungen? Zum einen hat es mit einer anderen Art der Zielsetzung zu tun. So setzt sich das Team kein spezifisches Ziel, welches sie beispielsweise in zwei Jahren erreichen wollen. Es betrachtet stattdessen kleinere Zeitperioden. Meistens gibt es zudem eine Rückkopplungsschleife, in welcher das Team den Ist-Zustand prüft und bei neuen Anforderungen die Zielsetzung anpasst.

Agiles Projektmanagement hebt sich also vom klassischen Projektmanagement durch seine Dynamik ab. Dabei gibt es verschiedene agile Methoden, die dem Team unterschiedlich viel Spielraum lassen.

Methoden im agilen Projektmanagement

Im agilen Projektmanagement bezeichnet man agile Methoden auch als Frameworks. Dieser Begriff ist durchaus treffend, denn sie geben Rahmenbedingungen und Leitlinien vor, die einen Rahmen für das Projektmanagement bilden.

Zu den beliebtesten Frameworks gehören Scrum und Kanban, die sich durch folgende Merkmale auszeichnen:

Scrum:

gibt eine klare Struktur mit festgelegten Terminen, Teamgröße, Rollen und Instrumenten vor
Grundgedanke: ein Produkt ist niemals fertig, als Ergebnis produziert das Team Inkremente
das Team arbeitet in Sprints, die nicht länger als vier Wochen dauern
das Team setzt sich Sprintziele, neue Anforderungen können nach Sprintende hinzugefügt werden

Kanban:

eine Methode zur Visualisierung von Aufgaben (offen, in Arbeit, erledigt) auf einem Board
das Team kann jederzeit neue Anforderungen hinzufügen
Rollen, Termine und Dauer sind nicht festgelegt
Hauptelement: Work-in-progress Limit, welcher festlegt, wie viele Aufgaben gleichzeitig in Bearbeitung sein dürfen

Fazit

Sowohl das klassische Projektmanagement mit seinen smarten Zielen, als auch das dynamische agile Projektmanagement haben natürlich ihre Daseinsberechtigung. Beide haben jedoch unterschiedliche Ansprüche und Ziele. Die verschiedenen agilen Methoden bieten aber zahlreiche Alternativen zum klassischen, smarten Vorgehen.

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.

Was ist Scrum of Scrums?

1 Antwort

Projekte werden zunehmend komplexer und immer mehr Personen sind in ein Projekt eingebunden. Das agile Framework Scrum definiert jedoch eine eindeutige Teamgröße, die nicht überschritten werden soll. Stößt Scrum bei Großprojekten also an seine Grenze? Ganz bestimmt nicht. Die Lösung liegt im Scrum of Scrums.

Worum handelt es sich?

Laut Scrum liegt die optimale Teamgröße bei nicht mehr als 9 Personen. Untersuchungen haben gezeigt, dass 4,6 Personen perfekt wären. Abgesehen davon, dass dieser Wert in der Praxis schwierig umzusetzen wäre, zeigt die Erfahrung, dass Teams eher größer statt kleiner sind.

Große Organisationen und Projekte können dann das Scrum of Scrums, auch SoS genannt, nutzen. Dieses Format dient der Vernetzung und der Kommunikation mehrerer Scrum Teams, die gemeinsam an einem großen Ziel oder Projekt arbeiten.

Kurz gesagt: SoS ist eine agile Methode zur Zusammenarbeit mehrerer Scrum Teams. Ziel ist die Vernetzung zwischen den Teams, die Kommunikation und Förderung der Zusammenarbeit. Abhängigkeiten können hier schnell sichtbar gemacht werden um Lösungen gemeinsam zu entwickeln.

Wie funktioniert es?

Das SoS ist vergleichbar mit dem Daily Scrum eines Scrum Teams, mit dem Unterschied, dass dieses nicht standardisiert ist. Die Frequenz, Dauer und die Teilnehmer des Meetings können die Teams selber bestimmen. Jedes Scrum Team entsendet einen Botschafter in dieses Meeting, welcher aber auch wechseln kann.

Im Daily Scrum beantworten die Teammitglieder die drei klassischen Fragen, die sich auf das Sprintziel beziehen:

Was habe ich seit gestern getan?
Was erledige ich bis morgen?
Was behindert meine Arbeit?

Im Scrum of Scrums sind die Fragen auf das Team bezogen, die Fragen werden also leicht umformuliert und ergänzt:

Was hat mein Team seit dem letzten Meeting geschafft?
Was wird mein Team bis zum nächsten Meeting erledigen?
Welche Hindernisse behindern mein Team?
Hat eine Tätigkeit meines Teams Auswirkung auf eines der anderen?

Ist SoS nun die Lösung für alle Großprojekte? Nicht ganz, denn auch diese Methode ist auf eine Größe beschränkt. Es sollten nicht mehr als 9 Scrum Teams zum Scrum of Scrum zusammenkommen. Was ist aber, wenn es mehr Teams gibt? Bei großen Unternehmen arbeiten auch schon mal mehr als 20 Scrum Teams an einem Projekt.

Scrum bietet auch hierfür eine Lösung – bitte festhalten: Das Scrum of Scrum of Scrums. So einfach wie es sich anhört, ist es doch kein Wunder, dass sich dieser Begriff nicht durchgesetzt hat. Es ist dennoch eine sinnvolle Methode, die Teams auf einer höheren Ebene miteinander zu vernetzen.

Herausforderungen und Vorteile von Scrum of Scrums

SoS erfordert neue Rollen wie einen Chief Product Owner und einen Scrum of Scrums Master. Natürlich sollte nicht verschwiegen werden, dass die Scrum Teams zunächst mit neuen Herausforderungen rechnen müssen:

Der Scrum Master muss stärker auf die Abhängigkeiten zu den anderen Teams achten, da sich diese auch auf das Sprint Planning auswirken. Die Kommunikation in solch großen Strukturen ist aufwendig aber umso wichtiger. Die Arbeitslast kann beim Scrum Master und auch beim Product Owner steigen.

Dem Aufwand stehen aber große Vorteile gegenüber:

Die Teams vernetzen sich stärker miteinander und können Abhängigkeiten reduzieren. Gleichzeitig ist der Projektfortschritt für alle Beteiligten sichtbar und die eigene Rolle transparent. Damit reduzieren sich Risiken, denn die Teams achten stärker darauf, mit ihrer Arbeit nicht die anderen Teams zu behindern oder sich einfach kopflos in die Entwicklung zu stürzen. Die Vorgänge sind gut aufeinander abgestimmt und sollten Probleme auftreten, werden sie gemeinsam gelöst.

Tipps für das Scrum of Scrums

Damit die Implementierung gelingt und nicht für Frust sorgt, hier ein paar Tipps und Fragen, die Sie vorher klären sollten:

Welche Frequenz und Dauer ist die Richtige und wer nimmt teil?
Halten Sie sich an die 4 Fragen – anders als beim Daily Scrum sollte dieser Rahmen auch genutzt werden um Probleme zu besprechen um Lösungen zu finden
Eine Retrospective of Retrospectives kann helfen gemeinsame Prozesse und Arbeitsweisen zu verbessern

Retro…was? Retrospektive und wie ein Team daran wächst

Schreibe eine Antwort

Schon Mal was von einer Retrospektive gehört? Im Scrum ist es jedenfalls ein gängiger Begriff. Die Retrospektive oder kurz „Retro“ hat dabei nichts mit einer Design- oder Musikrichtung zu tun, sondern ist ein wichtiger Termin. Es lohnt sich, einen Blick darauf zu werfen, da sich hinter diesem Begriff großes Potenzial versteckt.

Die Retro – Was ist das Ziel?

Die Retro ist ein Termin der regelmäßig wiederholt wird und in welchem das Team sich die Zeit nimmt, ihre Zusammenarbeit zu reflektieren. Was ist das Besondere daran?

Die meisten Teams sind völlig in die Projektarbeit versunken. Das ist verständlich, schließlich ist Zeit kostbar und die Aufgaben neigen dazu, stetig mehr anstatt weniger zu werden. Aber was macht ein erfolgreiches Team aus? Die gemeinsame Performance und Zusammenarbeit!

Wie aber soll ein Team sich verbessern, wenn es sich keine Zeit nimmt, die aktuelle Art und Weise zu bewerten und zu überprüfen? Genau hier setzt die Retrospektive an.

Nach jedem Sprint zieht sich das Team zurück, um gemeinsam zu besprechen, was gut lief und wo sich das Verbesserungspotenzial versteckt. Konflikte, die ein Team lähmen können, werden so bereits frühzeitig aufgedeckt. Das Team kann gemeinsam daran arbeiten, effizienter zu werden, Arbeitsabläufe zu verbessern und ihre Qualität zu steigern.

Aller Anfang ist schwer

Bei all den Vorteilen stellt sich die Frage, warum nicht alle Teams zu dieser Methode greifen. Die Antwort darauf ist simpel: Viele Führungskräfte legen mehr Wert darauf, dass Aufgaben schnell umgesetzt werden. Die Zeit, die sich das Team für die Reflektion nehmen würde, sehen sie an anderer Stelle besser eingesetzt.

Diese Auffassung ist gefährlich und zeigt eine kurzfristige Denkweise. Natürlich kann die Zeit für den Termin dazu genutzt werden, Themen weiter voranzutreiben. Langfristig gesehen bleibt das Team jedoch auf der Strecke und verpasst Gelegenheiten, sich zu verbessern. Außerdem wird hier etwas Wichtiges vergessen: Dadurch, dass sich ein Team stetig weiter entwickelt, steigt die Effizienz und Zeit kann sogar eingespart werden.

Widerstand kommt aber nicht immer von den Führungskräften, auch Teammitglieder können diese Argumente bringen.

Sie können mit Aussagen rechnen, wie:
– Unsere Zusammenarbeit ist doch schon super
– Dafür haben wir gerade keine Zeit

Sie sind dennoch von den Vorteilen der Retro überzeugt und wissen, dass sowohl Sie, das Team, aber auch das Projekt langfristig davon profitieren? Legen Sie die richtigen Grundsteine!

Nehmen Sie die Tür, anstatt durch die Wand zu brechen!

Führen Sie ein Auftaktmeeting durch, um das Team von der Retro zu überzeugen. Erklären Sie, was eine Retro ist und wie Sie gemeinsam davon profitieren können. Sie haben in der Regel mit weniger Widerstand zu rechnen, wenn Sie die Einführung gemeinsam planen, anstatt das Team vor vollendete Tatsachen zu stellen.

Wie sieht eine Retro aus?

Eine Retro wird immer vorbereitet, moderiert und hat Grundregeln, die jeder beachten muss:
– Las Vegas Regel: Alles, was in diesem Termin besprochen wird, bleibt im Termin!
– Goldene Regel: Wertschätzender und respektvoller Umgang ist das A und O!

Eine beliebte Retro, für die Sie nicht viel vorbereiten müssen, ist die 4-L-Retro (Liked, Learned, Lacked, Longed for).

Auf einem realen oder digitalen Whiteboard sind 4 Spalten oder Raster vorgezeichnet: Was lief gut? Was habe ich gelernt? Was hat gefehlt? Und was hätte ich mir gewünscht?

Geben Sie dem Team Zeit, kurz darüber nachzudenken und in jedes der Raster mindestens ein Post-it zu schreiben. Sind alle fertig, kann jeder seine Antwort vorstellen. Es hilft, wenn der Moderator zusammengehörende Themen schon mal clustert.

Nach einer Diskussion kommt der wichtigste Teil der Retro: Leiten Sie gemeinsam Maßnahmen ab, welche Sie nachhalten.

Es gibt unzählige Tools und Formen von Retros, Sie müssen nicht jedes Mal die gleichen Fragen verwenden. Ob kurz und effizient, oder etwas verspielter – schauen Sie, welche Methode besser beim Team ankommt. Mit etwas Abwechslung wird es garantiert nicht langweilig und Erfolge sind vorprogrammiert.

Planning Poker Regeln auf einer Seite erklärt [PDF]

3 Antworten

Die Planning Poker Regeln sind einfach. Planning Poker ist eine spielerische, aber durchaus ernstgemeinte Methode Aufwände in agilen Teams zu schätzen. Wir haben die Regeln mal zusammengefasst. Sechs einfache Phasen gibt es. Die Spielregln haben wir auf einer Seite zusammengefasst, zum Download. Auf einen Blick leicht verständlich. Daraus ist eine ganz nette Infografik, ein Cheat Sheet geworden, das sich gut im Team, bei der nächsten Remotesession teilen lässt. Auch ideal zum Ausdrucken und um es ins Office zu hängen.

Als Onlinetool für Planning Poker empfehlen wir das kostenfreie Agile Casino. Das online Planning Poker lässt sich ohne Registrierung in unbegrenzten Runden und mit mehr als 7 Spielern spielen.

Regeln für Schätzpoker

Schritt 1: Das Deck. Jeder Schätzer hält einen Stapel Planungspoker-Karten mit den Werten 0, 1, 2, 3, 5, 8, 13, 21 oder ? in der Hand, was der von uns empfohlenen Reihenfolge entspricht. Die Werte stehen für die Anzahl der Story Points, der idealen Tage oder anderer Einheiten, in denen das Team schätzt.

(Hier können natürlich andere Varianten bevorzugt werden. Zu erwähnen sind T-Shirtgrößen wie S, M, L, XL etc. oder „The Power of 2“, also 1, 2, 4, 16, etc.)

Schritt 2: Diskussion. Die Schätzer diskutieren ein Feature und stellen dem Product Owner bei Bedarf Fragen. Wenn die Funktion vollständig diskutiert wurde, wählt jeder Schätzer für sich eine Karte aus, die seine Schätzung darstellt.

Schritt 3: Aufdecken. Die Runde deckt alle Karten gleichzeitig auf.

Schritt 4: Fertig falls Konsens. Wenn alle Schätzer denselben Wert gewählt haben, wird dieser zum Schätzwert.

Schritt 5: Weiterdiskutieren. Wurde noch kein Konsens erzielt, diskutieren die Schätzer ihre Schätzungen. Insbesondere die Schätzer mit dem höchsten und dem niedrigsten Wert sollten ihre Gründe mitteilen. Nach einer weiteren Diskussion wählt jeder Schätzer erneut eine Schätzkarte aus und alle decken ihre Karten erneut gleichzeitig auf.

Schritt 6: Wiederholen: Der Prozess des Planning Poker wird so lange wiederholt, bis ein Konsens erreicht wurde. Ausnahme: Falls das Team zu der Einschätzung gelangt, über unzureichende Informationen zu Verfügen, kann es die Schätzung eines bestimmten Elements verschieben, bis zusätzliche Informationen vorliegen.

PDF zum kostenfreien Download

Kein Newsletterabo, keine Registrierung: Einfach so downloaden. Es wäre schön, wenn ihr das kostenfreie Scrum-Poker-Tool Agile Casino mal ausprobiert. Es gibt eine deutsche und eine englische Version. Schreibt gerne in die Kommentare, was ihr dazu denkt.

Vorschau Cheat Sheet Planning Poker — Vorschau des Cheat Sheets

scrum-poker-planning-infographic-cheat-sheet.pdf Download [EN-Version]

DE-scrum-poker-planning-infografik-cheat-sheet.pdf Download [DE-Version]

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.

Planning Poker online: „Agile Casino“ – Hübsch, funktional und kostenlos

Schreibe eine Antwort

Wir haben kein gutes kostenfreies Planning Poker für Remoteteams gefunden, daher haben wir selbst ein entwickelt. Auch im Businesskontext muss man nicht unbedingt für jede kleine Spielerei 9€ Abogebühr im Monat ausgeben.

Bei einem unserer anfangs eher improvisierten Sprintplannings im Homeoffice, war die erste klägliche Idee, „auf drei“ zu zählen und dann die Schätzung in den Chat zu tippen. Das war nicht die beste Idee. Also war ich auf der Suche nach einem kostenlosen online Planning-Poker-Tool oder Scrum Poker Online (Was ist Planning Poker). Ich benötigte ein vertrauensvolles, kostenfreies und am besten werbefreies Tool für unser Team. Eine Alternative zu den üblichen, mit Werbung überfrachteten, instabilen Freebies, die man sonst online so findet. Eine robuste, reife Open-Source-Lösung wäre ideal. Noch besser: Als SaaS-Variante.

Jetzt in diesem Coronazustand, in dem auch unsere Kunden vermehrt im Homeoffice in Deckung gehen, ist es eine zuverlässige Möglichkeit, uns in agilen Projektteams wie gewohnt selbst zu organisieren und effizient zu arbeiten. (Planning Poker ist nicht nur für das agile Projektmanagement geegnet.)

Die Kommunikation funktioniert mit den aktuellen Chat- und Videocallanwendungen wirklich gut. Aus dieser Situation heraus, wird das eigentlich erst richtig klar. Wir haben Slack und Microsoft Teams im Einsatz, je nach Projekt und Kunde.

Zuverlässige Software entwickeln können, deshalb haben wir selbst ein Tool entwickelt

Aus diesem Grunde haben wir uns über Ostern (2021) entschieden und ein Planning-Poker-Tool entwickelt. Es sollte vorerst nicht mehr und auch nicht weniger Funktion als gerade notwendig haben. Selbstverständlich haben wir natürlich auf Qualitätssicherung gesetzt.

Verfügbar zum gratis Losschätzen ist es auf https://agilecasino.kehrwasser.com. Wir verzichten auf eine Registrierung und es ist vollumfänglich kostenlos nutzbar.

Einfach Spielernamen eingeben und Raum erstellen oder mit bekannter Raumnummer einem bestehen Raum beitreten. Teamkollegen einladen und schon geht es im Multiplayerroom los.

Das Tool ist zu finden unter https://agilecasino.kehrwasser.com zum Schätzen und Planen. Entwickler und Codeenthusiasten sind eingeladen mitzuentwickeln. Sie finden den offenen Quellcode hier https://gitlab.com/heusinger-open-scrum-poker.

Viel Erfolg und Spaß damit.