Agile Story Points: Messen Sie Ihren Aufwand wie ein Profi

Storypoints können etwas verwirrend sein und werden oft missverstanden. Story Points sind ein wichtiger Bestandteil des User Story Mappings, und viele agile Teams verwenden sie bei der Planung ihrer Arbeit. Sie sind jedoch nicht so einfach wie das Hinzufügen von Zahlen zu Aufgaben oder das Abschätzen, wie lange ein Job dauern wird.

Selbst wenn Sie Story Points schon eine Weile verwenden, werden Sie feststellen, dass verschiedene Teams und Organisationen sie unterschiedlich verwenden.

Lassen Sie uns also Storypoints definieren, besprechen, warum sie für agile Teams so nützlich sind, und über einige der verschiedenen Arten sprechen, wie Teams sie beim Story-Mapping und der Sprint-Planung umsetzen.

Was sind User Story Points?

Story Points sind eine nützliche Maßeinheit in Agile und ein wichtiger Bestandteil der Prozess zur Zuordnung von User Storys. Sie weisen jeder User Story eine Zahl zu, um den Gesamtaufwand abzuschätzen, der erforderlich ist, um ein Feature oder eine Funktion zum Leben zu erwecken.

Wann sollten Storypoints geschätzt werden?

User Stories können während des User Story-Mappings, der Backlog-Verfeinerung oder während der Sprint-Planung geschätzt werden.

Sobald eine User Story definiert, dem Backbone zugeordnet und priorisiert wurde, ist es an der Zeit, die Storypoints abzuschätzen. Es ist eine gute Idee, dabei mit Ihrem Team zusammenzuarbeiten, da jedes Teammitglied in verschiedenen Storys eine andere Rolle spielt und die Arbeit kennt, die mit UX, Design, Entwicklung, Test und Markteinführung verbunden ist. Die Zusammenarbeit bei der Schätzung von Storypoints hilft dir auch dabei, Abhängigkeiten frühzeitig zu erkennen.

Es empfiehlt sich, jeder User Story Story Points zuzuweisen, bevor du sie in Releases oder Sprints aufteilst. Auf diese Weise können Sie die Komplexität, den Aufwand und die Ungewissheit jeder User Story im Vergleich zu anderen in ihrem Backlog einschätzen und fundierte Entscheidungen über die Arbeit treffen, die Sie für jeden Sprint oder Release aufwenden.

Wie schätzt man User Story Points ein

Bei der Schätzung von Story Points berücksichtigen Sie den Gesamtaufwand, der erforderlich ist, um dieses Feature oder diese Funktion verfügbar zu machen, damit sie dem Kunden einen Mehrwert bieten kann. Ihr Team muss Fragen wie die folgenden besprechen:

• Wie komplex ist die Arbeit?
• Wie viel Arbeit ist erforderlich?
• Was sind die technischen Fähigkeiten des Teams?
• Was sind die Risiken?
• Bei welchen Teilen sind wir uns nicht sicher?
• Was müssen wir an Ort und Stelle haben, bevor wir beginnen oder fertig werden können?
• Was könnte schief gehen?

Tipp: Wenn du Schwierigkeiten hast, eine Story einzuschätzen oder der Umfang der Arbeit überwältigend ist, musst du deine Story möglicherweise in kleinere Teile zerlegen, um mehrere User Stories zu erstellen.

Was ist ein Storypoint wert?

An dieser Stelle können Storypoints etwas verwirrend werden, da Storypoints keinen festgelegten universellen Wert haben. Du musst irgendwie herausfinden, was sie für dich und dein Team wert sind (ja, wirklich tiefgründiges und bedeutungsvolles Zeug).

So funktioniert das:

• Jeder Geschichte wird eine bestimmte Anzahl von Storypoints zugewiesen
• Punkte bedeuten für verschiedene Teams oder Organisationen unterschiedliche Dinge.
• Ein Storypoint für dein Team entspricht möglicherweise nicht dem gleichen Aufwand, der mit einem Storypoint für ein anderes Team verbunden ist
• Der Aufwand für 1 Story Point sollte stabil bleiben dein Teamarbeit bei jedem Sprint und es sollte von einer Story zur nächsten stabil bleiben
• 2 Story Points sollten dem doppelten Aufwand im Vergleich zu 1 Story Point entsprechen
• 3 Story Points sollten dem dreifachen Aufwand entsprechen im Vergleich zu 1 Story Point... und so weiter

Die Zahl, die Sie vergeben, spielt keine Rolle — was zählt, ist das Verhältnis. Die Story Points sollen dir dabei helfen, den relativen Aufwand zwischen jeder Story und jedem Sprint nachzuweisen.

Zum ersten Mal Storypoints einschätzen

Da Story Points relativ sind, müssen Sie sich einige grundlegende Schätzungen geben, wenn Sie zum ersten Mal eine Story Point-Schätzung durchführen. Dadurch erhalten Sie einen Bezugsrahmen für alle zukünftigen Geschichten.

Wählen Sie zunächst Geschichten in verschiedenen Größen aus:

• Eine sehr kleine Geschichte
• Eine mittelgroße Geschichte
• Eine große Geschichte

... ein bisschen wie T-Shirt-Größen.

Weisen Sie dann jeder dieser grundlegenden Geschichten Punkte zu. Ihre kleinste Geschichte könnte 1 sein. Wenn deine mittlere Geschichte dreimal mehr Aufwand erfordert, dann sollte es 3 sein. Wenn Ihre große Geschichte den 10-fachen Aufwand erfordert, sollte es das 10-fache sein. Diese Zahlen hängen von der Art der Geschichten ab, an denen Ihr Team normalerweise arbeitet, sodass Ihre grundlegenden Story-Zahlen möglicherweise anders aussehen als diese.

Das Wichtigste ist, dass Sie diese grundlegenden Geschichten verwenden können, um all Ihre zukünftigen Geschichten abzuschätzen, indem Sie den relativen Aufwand vergleichen.

Mit der Zeit werden Sie und Ihr Team feststellen, dass es einfacher wird, Nutzerberichte einzuschätzen, wenn sich Ihr gemeinsames Verständnis der Arbeit entwickelt. Hier werden Storypoints am wertvollsten. Sie helfen Ihrem Team dabei, die Erwartungen aufeinander abzustimmen und effektiver zu planen.

Vereinfachen Sie die Schätzung

Eine App für Jira wie Einfacher agiler Teamrhythmus macht es einfach, das Teamengagement für jeden Sprint oder jede Version zu sehen, mit geschätzten Gesamtwerten für jede Swimlane.

Verwendung der Fibonacci-Sequenz zur Story-Point-Schätzung

Einige Teams verwenden die Fibonacci-Sequenz (1, 2, 3, 5, 8, 13, 21, 34, 55, 89 usw.) für ihre Story-Point-Schätzungen, anstatt linear zu bleiben oder Teams zu erlauben, eine beliebige Zahl (1, 2, 3, 4, 5, 6, 7 usw.) zu verwenden.

Das hat seine Vorteile. Wenn Sie sich beispielsweise eine Geschichte ansehen und abschätzen möchten, ob es sich um eine 5, 8 oder 13 handelt, ist es viel schneller und einfacher, eine Antwort zu finden, als zu versuchen, auf der richtigen Zahl zwischen beispielsweise 4-15 zu landen. Sie werden wahrscheinlich viel schneller zu einem Konsens kommen.

Das bedeutet auch, dass ihr nicht in der Lage sein werdet, den Durchschnitt der Storypoints des Teams zu ermitteln, um die Schätzung abschliessen zu können. Stattdessen müsst ihr die Arbeit besprechen und euch für die beste Schätzung aus einer begrenzten Anzahl von Optionen entscheiden.

Aber es schränkt Ihre Möglichkeiten ein — wenn Sie eine Geschichte haben, die mehr Aufwand als 34, aber weniger als 55 erfordert, ist Ihre Schätzung möglicherweise weniger genau.

Verwendung von Story Points zur Schätzung der Geschwindigkeit

Nach einiger Zeit der Zusammenarbeit werden die meisten Teams eine gute Vorstellung davon haben, wie viel Aufwand in den einzelnen Storypoints steckt.

Natürlich ist das Timing nicht genau - es gibt eine Glockenkurve, und Story Points sind so konzipiert, dass sie eine Schätzung des Aufwands und nicht der Zeit sind.

Storypoints (und die Kenntnis ihres ungefähren Zeitpunkts) können jedoch hilfreich sein, wenn es darum geht, herauszufinden, wie viel Ihr Team in jedem Sprint erledigen kann.

Du solltest in der Lage sein, abzuschätzen, wie viele Storypoints dein Team während eines zweiwöchigen Sprints bewältigen kann, oder in welchem Zeitrahmen auch immer du gerade arbeitest.

Wenn dein Team beispielsweise in der Regel 3 Story Points pro Tag durchstehen kann, können sich in einem zweiwöchigen Sprint bis zu 30 Story Points summieren. Das ist deine Geschwindigkeit.

Velocity ist nützlich für das User Story Mapping und die Sprint-Planung. Wenn Sie Ihre User Stories Sprints oder Versionen zuordnen, können Sie die Gesamtzahl der Storypoints überprüfen und sicherstellen, dass sie mit Ihrer Geschwindigkeit übereinstimmt, damit Sie sich nicht zu sehr oder zu wenig engagieren.

Wie Sie sehen, gibt es verschiedene Methoden zur Schätzung der Arbeit. Der beste Rat ist, konservativ zu sein und das Team nicht zu überlasten.

Im Laufe der Zeit sollten Ihre Schätzungen genauer werden.

Verwendung von Story Points in Scrum, Kanban und Extreme Programming

Story Points sind in vielen agilen Methoden von zentraler Bedeutung für Schätzungs- und Planungsprozesse. Scrum und Extreme Programming (XP) stützen sich stark auf Story Points, um den Aufwand und die Komplexität von User Stories einzuschätzen.

Scrum-Teams verwenden während der Sprint-Planung Storypoints, um zu entscheiden, welche Aufgaben in den kommenden Sprint aufgenommen werden sollen, und fördern so Diskussionen, die zu einem gemeinsamen Kontext und einem gemeinsamen Verständnis der Arbeit führen.

Extreme Programming hingegen verwendet Story Points, um die Größe von Funktionen zu beurteilen, sodass Teams Ressourcen effektiv priorisieren und zuweisen können. Teams, die Kanban verwenden, können von Storypoints profitieren, indem sie sie nutzen, um Grenzen für laufende Aufgaben festzulegen und den gesamten Aufgabenablauf zu optimieren.

Die spezifischen Praktiken können sich zwar unterscheiden, aber Story Points können dazu beitragen, die Zusammenarbeit im Team und einen vorhersehbareren Arbeitsablauf zu fördern.

Es gibt viele gute Gründe, warum so viele Scrum- und Agile-Teams Storypoints einführen.

‍

1. Schnelle Schätzung

Mithilfe von User Story Points können Sie schnell abschätzen, wie viel Arbeit mit jedem Element in Ihrem Backlog verbunden ist und wie viel Arbeit Sie in einem Sprint oder Release erledigen können.

2. Sorgen Sie für Konsens und Zusammenarbeit

Wenn ein Teammitglied 5 Storypoints schätzt, ein anderes aber 12, ist das eine Gelegenheit für das Team, zu besprechen, welche Arbeit damit verbunden ist.

Eine Person hat möglicherweise eine effizientere Art, Dinge zu erledigen, oder die andere Person hat möglicherweise ein besseres Verständnis für die Schritte, die mit der Erledigung der Arbeit verbunden sind. Diese Diskussion hilft ihnen, Ideen auszutauschen, ein gemeinsames Verständnis zu erzielen, einen Konsens zu erzielen und eine genauere Schätzung vorzunehmen.

Vergleichen Sie dies mit der Schätzung der Zeit. Wenn Sie jedes Teammitglied bitten, den Zeitaufwand für eine Aufgabe abzuschätzen, erhalten Sie mehr als 5 verschiedene Antworten. Das Timing hängt von Erfahrung und Verständnis ab. Die meisten Teammitglieder sind sich jedoch einig, wie viel Aufwand erforderlich ist, um eine Story fertigzustellen. Das bedeutet, dass Sie einen Konsens erzielen und viel schneller mit Ihrem Story-Mapping oder Ihrer Sprint-Planung fortfahren können.

3. Keine künstlichen Fristen

Wenn Sie die Zeit anstelle von Story Points schätzen, müssen Sie sich eine künstliche Frist einfallen lassen, was zu unnötigem Druck führen kann (und wahrscheinlich nicht allzu genau ist).

Storypoints spiegeln die Realität genauer und praktischer wider. In den meisten Fällen gibt es keine feste Frist — es wird nur sichergestellt, dass Aufgaben effizient und in der richtigen Reihenfolge der Priorisierung erledigt werden.

4. Bessere Planung und Prognose

Story Points können dir helfen, besser im Voraus zu planen. Wenn du zum Beispiel weißt, dass Johnny für eine Woche in den Urlaub fährt, kannst du deinen Sprint so anpassen, dass dein Team nicht zu viel verlangt. Oder Sie können eine andere Möglichkeit finden, Ihre Kapazität zu erhöhen, indem Sie beispielsweise ein anderes Teammitglied einstellen oder den Umfang reduzieren.

5. Zoomen Sie auf die Details

Story Points zwingen dein Team dazu, die Arbeit eines bevorstehenden Sprints zu durchdenken und zu überlegen, was realistisch ist. Es ist eine Zeit, in der Ihre detailorientierten Teammitglieder glänzen — und eine Zeit, in der Ihre Querdenker verstehen, was passieren muss, um ihre Pläne in die Tat umzusetzen.

6. Holen Sie sich Engagement

Wenn Ihr Team weiß, dass es die geplanten Ziele erreichen kann und sich seiner Geschwindigkeit sicher ist, ist es einfacher, es dazu zu bringen, sich auf die Arbeit einzulassen und sie selbstbewusst umzusetzen.

7. Sei anpassungsfähiger

Wenn sich die Teamgröße ändert (vielleicht fügst du ein neues Mitglied hinzu oder jemand wechselt in eine andere Rolle), hast du ein integriertes System, um deine Geschwindigkeit zu aktualisieren (d. h. wie viele Stories du in einem Sprint abschließen kannst) und dein Workload entsprechend anzupassen.

8. Sei gerade genau genug

Mithilfe von Story Points können Sie einschätzen, was Ihr Team in einer bestimmten Zeit erledigen kann. Diese Genauigkeit sorgt für reibungslosere Releases, die nach Plan verlaufen — und ist besonders wertvoll, wenn Sie mehrere Teams mit mehreren Abhängigkeiten haben.

Aber gleichzeitig macht das Story Pointing deutlich, dass Ihre Arbeit nur eine Schätzung ist und Sie sich nicht verpflichten, X in Y Stunden zu erledigen. Sie werden nicht wissen, wie lange etwas dauern wird, bis Sie es tun - es tauchen fast immer unerwartete Dinge auf.

Andere Methoden geben dir vielleicht ein genaueres Timing, aber es ist nicht praktikabel, 30 Minuten damit zu verbringen, die Arbeit zu besprechen, die in jeder einzelnen Story deines Backlogs steckt. Es ist viel praktischer, eine Zahl zuzuweisen, die „genau genug“ ist, Ihren Sprint zu planen und sich an die Arbeit zu machen.

9. Bessere Kapazitätsplanung

Möglicherweise sind Sie nicht in der Lage, alle Ihre wichtigsten Prioritäten in einer Version unterzubringen, insbesondere wenn sie komplex, riskant oder zeitaufwändig sind. Story Points können Ihnen jedoch dabei helfen, auf einfache Weise eine oder zwei kleinere Storys zu identifizieren, um Ihre Kapazitäten bei jedem Sprint oder Release auszuschöpfen.

Die Verwendung von Story Points ermutigt Sie auch dazu, Wege zu finden erhöhen die Kapazität Ihres Teams (anstatt länger zu arbeiten). Wenn Sie Risiken minimieren, Wege finden, den Aufwand zu reduzieren, und die richtigen Leute in den Raum bringen können, um komplexe Aufgaben zu vereinfachen... werden Sie in der Lage sein, mehr Geschichten schneller zu bearbeiten.

10. Leistung messen und verbessern

Story Points können dir helfen, deine Leistung zu messen und zu verbessern, indem du deinem Team Fragen stellst wie:

• Hast du alle während des Sprints zugewiesenen Aufgaben erledigt?
• Steigt oder sinkt Ihre Geschwindigkeit mit der Zeit, wenn Sie agiler werden?
• War Ihre Schätzung der Story Points korrekt?
• Wenn nicht, wie könnten Sie die Leistung Ihres Teams optimieren und sicherstellen, dass Sie besser zusammenarbeiten oder planen?

Benötigt alles in deinem Backlog User-Story-Punkte?

Manche Teams weisen nicht jedem Gegenstand in ihrem Backlog Storypoints zu. Möglicherweise weisen sie sie einfach den User Stories zu. Sie könnten es vermeiden, Bugs, die während des Sprints auftauchen, User-Story-Punkte zuzuweisen, insbesondere wenn sie mit keiner der Geschichten zusammenhängen, die ursprünglich dem Sprint zugeordnet wurden. Das ist sinnvoll, da es oft schwierig ist, einen Bug einzuschätzen — einige sind mit sehr geringem Aufwand zu beheben, während andere recht komplex sind.

Ihr Backlog könnte auch kleinere Jobs oder technische Aufgaben beinhalten, deren Erledigung zwischen ein paar Minuten oder ein paar Stunden dauern würde. Diesen Aufgaben sind möglicherweise keine Story Points zugewiesen, wenn sie nur sehr wenig Aufwand erfordern.

Es ist jedoch wichtig zu beachten, dass diese Aufgaben immer noch wichtig sind. Sie bieten dem Benutzer immer noch einen Mehrwert. Und sie sind unverzichtbar, um Ihr Ziel zu erreichen: funktionierende Software zu liefern. Sie können sie jedoch nicht immer planen oder im Voraus abschätzen.

Also, wie integrieren Sie sie in Ihren Arbeitsablauf?

Möglicherweise müssen Sie mit Ihrem Team verschiedene Ideen und Strategien besprechen.

Sie könnten zum Beispiel einen Puffer in Ihrer Kapazität reservieren, um eine durchschnittliche Anzahl von Bugs und anderen Jobs zu berücksichtigen, die nicht auf die Geschichte eingehen. Auf diese Weise können Sie mit den Storys, die Sie dem Sprint zugewiesen haben, auf dem Laufenden bleiben und gleichzeitig andere Punkte von der Liste abhaken.

Wie auch immer, wenn Ihr Team an Aufgaben arbeitet, die keine Story Points haben, müssen Sie die Auswirkungen auf die Kapazität berücksichtigen. Sie müssen sich anpassen, beurteilen, ob das Sprintziel noch erreichbar ist, und Ihre Pläne entsprechend anpassen.

Was passiert, wenn Sie die Schätzung falsch verstehen?

Sie sollten zwar versuchen, Ihre Nutzer-Story-Point-Schätzungen so genau wie möglich zu machen, aber möglicherweise haben Sie das Risiko, den Aufwand und die Komplexität, die mit der Umsetzung einer Story verbunden sind, unter- oder überschätzt.

Dies kann bedeuten, dass Sie nicht die gesamte für Ihren Sprint geplante Arbeit erledigen. Vielleicht müssen Sie einen Teil davon auf den nächsten Sprint verschieben, was bedeutet, dass Sie Ihre User Story Map neu priorisieren und anpassen müssen.

Zum Glück ist dieser Prozess ziemlich einfach, wenn Sie digitale User Story Mapping-Software verwenden wie Einfacher agiler Teamrhythmus.

Retrospektiven oder Sprint-Bewertungen sind ein guter Zeitpunkt, um mit Ihrem Team alle Probleme zu besprechen, bei denen die Schätzungen falsch waren. Nehmen Sie sich etwas Zeit, um zu besprechen, was passiert ist, um zu verstehen, warum mehr oder weniger Aufwand erforderlich war, und zu besprechen, wie Sie in Zukunft genauere Schätzungen erstellen können.

Ordnen Sie Storypoints in Easy Agile TeamRhythm zu

Mit Easy Agile User Story Maps for Jira können Sie Story-Point-Schätzungen direkt auf Ihrer Story-Map hinzufügen und bearbeiten. Wählen Sie einfach die Story oder das Problem aus und bearbeiten Sie das Story-Point-Feld.

Es aktualisiert deine Sprint-/Versionsstatistiken automatisch mit neuen Gesamtwerten, sodass du deine Kapazität sehen, Storys in Sprint-/Versions-Swimlanes anordnen, sicherstellen kannst, dass du das Beste aus deiner Geschwindigkeit herausholst, und übertriebene Verpflichtungen vermeiden kannst.

Außerdem hat Ihr gesamtes Team Zugriff auf das User-Storyboard und die Kostenvoranschläge — perfekt für die interne oder externe Erfassung von Benutzergeschichten, die Online-Zusammenarbeit und die Aktualisierung von Schätzungen zu jedem Zeitpunkt des Prozesses.

Neugierig auf Easy Agile User Story Maps? Zu den Funktionen gehören so viel mehr als nur Storypoints, wie zum Beispiel:

• Priorisierung per Drag & Drop
• Visualisierte Kundenreisen in Jira
• Sprint-/Versions-Swimlanes zum Organisieren von Geschichten
• Fügen Sie ganz einfach Storys zu Ihrer Story-Map hinzu oder bearbeiten Sie sie
• Sehen Sie die Sprint-/Versionsstatistiken auf einen Blick
• Einfache Zusammenarbeit mit Teammitgliedern
  

Kostenlose Testversion: Easy Agile TeamRhythm

Eine Frage, die sich oft stellt, ist, „Was sind die Indikatoren für eine hocheffektiver Scrum Master?“ Wenn Sie danach streben, ein außergewöhnlicher Scrum Master zu werden, sollten Sie Folgendes berücksichtigen:

• Identifizieren Sie wiederholte Fehler: Gelegentliche Fehler werden zwar erwartet, aber es ist wichtig, dass der Scrum Master mit dem Team zusammenarbeitet, um wiederkehrende Fehler zu identifizieren. Durch die Implementierung von Richtlinien und Praktiken kann das Team verhindern, dass diese Fehler erneut passieren.
• Behandle systemische Probleme: Wenn das Team immer wieder auf dieselben Probleme stößt, muss der Scrum Master das Vorhandensein systemischer Probleme erkennen. In Zusammenarbeit mit dem Team kann der Scrum Master Gegenmaßnahmen ergreifen, um zu verhindern, dass diese Probleme erneut auftreten.
• Messen Sie Verbesserungen im Laufe der Zeit: Verbessern wir uns als Team kontinuierlich? Beurteilen Sie, ob das Team jetzt effektiver ist als in früheren Perioden, z. B. vor 6, 9 und 12 Monaten. Überlegen Sie auch, ob das Team in Zukunft besser sein wird. Wenn der Fortschritt ins Stocken gerät, kann es notwendig sein, die Effektivität des Scrum Masters neu zu bewerten.

Wenn Ihr Team in allen drei Bereichen Fortschritte macht, ist das ein gutes Zeichen dafür, dass der Scrum Master effektiv ist und dass das Team lernt und sich verbessert.

Um kontinuierliche Verbesserungen voranzutreiben, sollte der Scrum Master die Retrospektive nutzen. Bei der Retrospektive handelt es sich um eine Scrum-Veranstaltung, die nach dem Sprint Review durchgeführt wird, um den Prozess und die Fähigkeit des Teams, Produkte effektiv zu liefern, zu bewerten und anzupassen. Während dieser Sitzung leitet der Scrum Master das Team dabei, Erfolge zu feiern und Bereiche zu erkunden, in denen Verbesserungen möglich sind.

7-stufige Checkliste, die von Scrum Mastern bei Retrospektiven verwendet wird, um Probleme anzugehen:

1. Diskutieren Sie das Problem: In der Retrospektive moderiert der Scrum Master eine Diskussion, um die wichtigsten Herausforderungen zu identifizieren, vor denen das Team steht.
2. Auswirkungen abschätzen: Ermitteln Sie die Dringlichkeit und die Auswirkungen des Problems. Bei Problemen mit großer Tragweite können sofortige Maßnahmen erforderlich sein, während weniger dringende Angelegenheiten später behandelt werden können.
3. Identifizieren Sie die Hauptursachen: Das Verständnis der Grundursache ermöglicht es dem Team, tiefere Einblicke zu gewinnen und mögliche Lösungen zu entwickeln.
4. Generieren Sie Lösungen: Sobald ein erhebliches Problem erkannt wurde, leitet der Scrum Master das Team bei der Suche nach Lösungen zur Lösung des Problems.
5. Implementieren Sie Lösungen: Dieser Schritt wird in der nachfolgenden Retrospektive durchgeführt. Der Scrum Master stellt sicher, dass die vorgeschlagenen Lösungen erprobt und getestet werden.
6. Evaluieren Sie die ersten Ergebnisse: Beurteilen Sie die Effektivität der implementierten Lösung. Hat sie das Problem behoben, es noch schlimmer gemacht oder hatte sie keine Wirkung?
7. Legen Sie die nächsten Schritte fest: Entscheiden Sie anhand der Ergebnisse, ob das Problem behoben ist oder ob weitere Maßnahmen erforderlich sind. Dies kann bedeuten, mit der aktuellen Lösung fortzufahren oder zu einem anderen Ansatz überzugehen.

Stellen wir uns zum Beispiel ein Team vor, das mit hohen Fehlerraten zu kämpfen hat. Ihre Fehlerraten übertreffen sowohl den Durchschnitt des Unternehmens als auch die Industriestandards. So könnte die 7-stufige Checkliste angewendet werden:

Schritt 1: In der Retrospektive stellt der Scrum Master das Thema der hohen Fehlerraten zur Diskussion.

Schritt 2: Der Product Owner gibt Feedback vom Helpdesk-Team und hebt Kundenbeschwerden und die negativen Auswirkungen auf den Umsatz hervor.

Schritt 3: Nach reiflicher Überlegung stellt das Team fest, dass beim manuellen Testen viele Fehler übersehen werden, und identifiziert den Mangel an Testautomatisierung als einen Faktor, der dazu beigetragen hat.

Schritt 4: Ein Teammitglied mit Erfahrung in automatisierten Tests schlägt vor, automatisierte Testpraktiken auf Einheitenebene zu implementieren.

Schritt 5: In der darauffolgenden Retrospektive berichtet das Team, dass die neuen Unit-Test-Praktiken auf ihre gesamte Arbeit während des Sprints angewendet wurden.

Schritt 6: Das Team räumt ein, dass bei den automatisierten Tests sechs Fehler festgestellt wurden, die sonst übersehen worden wären.

Schritt 7: Das Team erklärt sich bereit, weiterhin automatisierte Komponententestpraktiken zu verwenden, und plant, auf Tests auf Integrationsebene auszuweiten, sobald ein größerer Teil der Codebasis abgedeckt ist.

Mithilfe dieser 7-stufigen Checkliste können Scrum Master Retrospektiven effektiv nutzen, um wiederkehrende Fehler zu beheben, laufende Probleme zu lösen und das kontinuierliche Wachstum und die Verbesserung ihrer Teams zu fördern.