So verwenden Sie Burndown-Charts für die agile Produktentwicklung
Wenn eines in der Produktentwicklung (oder im Leben) sicher ist, dann ist es, dass die Zeit immer vergeht und es immer Aufgaben gibt, die erledigt werden müssen. Es gibt keine einfachere Methode, diese beiden kritischen Kennzahlen zu berechnen als ein einfaches Burndown-Diagramm.
Burndown-Diagramme helfen agilen Teams dabei, Zeit und Aufgabenerledigung zu visualisieren. Das bedeutet, wie viel Arbeit noch übrig ist, verglichen mit der Zeit, die für die Entwicklung eines Produkts oder eines bestimmten Sprints geplant ist.
In diesem Beitrag erklären wir, was Burndown-Charts sind, welche Vorteile ihre Verwendung hat und wie sie von Entwicklungsteams verwendet werden. Wir erklären auch den Unterschied zwischen Burndown- und Burnup-Diagrammen, Produkt-Burndown-Diagrammen und Sprint-Burndown-Diagrammen und stellen hilfreiche Tools zur Integration kritischer Metriken in Jira vor. Lassen Sie uns nun die Y-Achse nach unten gleiten!
Was ist ein Burndown-Diagramm?
Ein Burndown-Diagramm visualisiert, wie viel Arbeit noch zu erledigen ist und wie viel Zeit für die Fertigstellung noch zur Verfügung steht. Diese grafische Darstellung ist für alle sichtbar und sagt voraus, wie viel Arbeit das Team innerhalb der vorgegebenen Zeit erledigen will. Burndown-Diagramme werden auch verwendet, um zu messen, wie schnell ein agiles Team die Nutzerberichte von Kunden bearbeitet und fertiggestellt hat. Sie eignen sich hervorragend, um das Team über jede Änderung des Arbeitsumfangs auf dem Laufenden zu halten.
Schauen wir uns an, was jeder Teil des Diagramms darstellt. Der verbleibende Arbeitsaufwand wird auf der vertikalen Achse angezeigt. Die Zeit, die seit dem Start des Projekts oder des Sprints vergangen ist, wird auf der horizontalen Achse angezeigt. Die X-Achse ist also die Zeitleiste des Projekts oder der Iteration, und die Y-Achse ist die Arbeit, die abgeschlossen werden muss.
Der gesamte Arbeitsaufwand für das Projekt befindet sich links oben auf der Y-Achse, und der Endpunkt ganz rechts auf der X-Achse steht für den letzten Tag des Projekts oder einer bestimmten Iteration. Die Start- und Endpunkte sind durch die ideale Arbeitslinie miteinander verbunden. Dabei handelt es sich um eine gerade Linie, die zeigt, was das Team innerhalb eines vorher festgelegten Zeitrahmens zu erreichen hofft. Eine weitere Linie, die eigentliche Arbeitslinie, zeigt, wie viel Arbeit noch übrig ist und wie schnell das Team tatsächlich arbeitet.
Tatsächliche Arbeitslinie im Vergleich zur idealen Arbeitslinie
Ein Burndown-Diagramm zeigt sowohl die tatsächliche Arbeitslinie als auch die ideale Arbeitslinie. Beide Linien beginnen am Startpunkt oben auf der Y-Achse. Im Laufe des Projekts oder der Iteration oszilliert die tatsächliche Arbeitslinie um die ideale Arbeitslinie, je nachdem, wie das Team voranschreitet.
Wenn das Team den Zeitplan einhält, weicht die tatsächliche Arbeitslinie nicht wesentlich von der idealen Arbeitslinie ab und bleibt anständig gerade. Wenn das Team während des Projekts oder Sprints auf viele zeitraubende Hindernisse stößt, wird die eigentliche Arbeitslinie eher ein wildes Kringel sein, und es kann sein, dass der Endpunkt der X-Achse nicht erreicht wird, bevor die Zeit abgelaufen ist.
Die Vorteile der Verwendung von Burndown-Charts
Burndown-Charts sind in vielerlei Hinsicht hilfreich. Diese Diagramme:
- Stellen Sie den Fortschritt der im Laufe der Zeit abgeschlossenen Arbeiten visuell dar.
- Halten Sie die Produktverantwortlichen über den Entwicklungsfortschritt eines Produkts oder eines bestimmten Sprints auf dem Laufenden.
- Sorgen Sie dafür, dass das gesamte Entwicklungsteam auf dem Laufenden ist, wie weit ein Produkt fortgeschritten ist.
- Werden regelmäßig aktualisiert, sobald die Arbeit abgeschlossen ist und die Zeit vergeht, um den Produktfortschritt in Echtzeit anzuzeigen.
- Informieren Sie im Voraus, wenn ein Produkt nicht schnell genug entwickelt wird.
- Erfassen Sie klare Kennzahlen, die im Nachhinein überprüft werden können.
Burndown-Diagramm im Vergleich zu Burnup-Diagramm
Ein Burndown-Diagramm zeigt, wie viel Arbeit noch übrig ist, indem es an der Spitze der Y-Achse beginnt und im Laufe der Zeit und Abschluss der Arbeit nach unten zu der Stelle führt, an der der Endpunkt auf die X-Achse trifft.
Ein Burnup-Diagramm bewirkt das Gegenteil. Der Startpunkt befindet sich in der unteren Ecke des Diagramms, ganz links von der X-Achse. Die ideale Arbeitslinie und die tatsächliche Arbeitslinie eines Burn-up-Diagramms verlaufen nach oben, wenn die Arbeit abgeschlossen ist und die Zeit vergeht. Oben auf der Y-Achse befindet sich eine weitere horizontale Linie, die den Umfang des Projekts darstellt, z. B. die Anzahl der Story Points, die für die Fertigstellung benötigt werden. Wenn der Umfang größer wird, z. B. wenn Story Points oder Sprint-Backlog Wenn Elemente hinzugefügt werden, erhöht sich die Umfangslinie, um dem erhöhten Ziel Rechnung zu tragen.
Wenn sich der Umfang eines Sprints oder Projekts aufgrund unerwarteter Entwicklungen oder Erkenntnisse der Stakeholder ändert, was im Laufe der Entwicklung unvermeidlich ist, werden diese Änderungen durch die Scope-Linie dargestellt. Dies kann Burnup-Charts zu einem etwas anpassungsfähigeren Tool machen.
Sowohl Burndown- als auch Burnup-Diagramme verfolgen die Geschwindigkeit, den Arbeitsablauf und den Fortschritt eines Teams. Die Umfangslinie eines Burnup-Diagramms berücksichtigt die Entwicklung der Softwareentwicklung und die Art und Weise, wie sich die Ziele im Laufe eines Projekts bewegen können, weshalb sie sich ideal für die Nachverfolgung eines Projekts als Ganzes eignen. Obwohl beide Tools effektiv sind, könnte ein Burndown-Diagramm während eines Sprints besser genutzt werden, da die Wahrscheinlichkeit, dass sich die Anzahl der Aufgaben in einem Sprint ändert, geringer ist.
Grafik zum Produkt-Burndown im Vergleich zum Sprint-Burndown
Es gibt zwei verschiedene Arten von Burndown-Charts. Ein Produkt-Burndown-Diagramm zeigt, wie viel Arbeit für das gesamte Projekt noch übrig ist, wohingegen ein Sprint-Burndown-Diagramm zeigt, wie viel Arbeit in einer bestimmten Iteration noch übrig ist.
Ein Produkt-Burndown-Diagramm erfasst eine größere Datenmenge. Es stellt alles dar, was an einem Produkt innerhalb des zu Beginn des Projekts vereinbarten spezifischen Zeitrahmens fertiggestellt werden muss.
Ein Sprint-Burndown-Diagramm hilft Scrum-Mastern dabei, zu visualisieren, wie schnell das agile Team die Arbeit erledigt und wie viel Arbeit während eines Sprints noch zu erledigen ist. Es zeigt den Fortschritt des Scrum-Teams, indem es anzeigt, wie viel Arbeit tatsächlich noch übrig ist, anstatt wie viel Zeit aufgewendet wurde. Im Laufe eines Sprints wird das Diagramm entlang der abgeschlossenen Storypoints nach unten geneigt sein.
Wenn die Burndown-Linie in einem Sprint-Burndown-Diagramm nicht bis zur Mitte des Sprints nach unten zeigt, ist das ein Zeichen dafür, dass der Sprint nicht gut läuft, und es ist Sache des Scrum Masters, das Team wieder auf Kurs zu bringen.
Arbeiten Sie an Ihrem nächsten Produktplan? Erfahren Sie häufige Fehler bei der agilen Planung und wie Ihr Team diese häufigen Fallstricke vermeiden kann.
Burndown-Charts in Jira
Kaputte Builds Agile Berichte und Gadgets beinhaltet Burndown- und Burnup-Charts für beide Scrum und Kanban.
Die Anwendung wurde für Jira entwickelt, sodass Sie die Berichterstattung in Echtzeit integrieren können. Der Zugriff auf sofortige Kennzahlen hilft Teams, Engpässe und Abhängigkeiten zu erkennen, sodass diese eher früher als später behoben werden können. Mit der Anwendung können Sie Diagramme und anpassbare Berichte exportieren, um sie mit Teammitgliedern und Stakeholdern zu teilen oder im Nachhinein zu überprüfen.
Wie Easy Agile Ihrem Team helfen kann
Unsere Leidenschaft ist es, agilen Teams dabei zu helfen, effizienter und effektiver zu arbeiten, wobei die Bedürfnisse des Kunden immer an erster Stelle stehen. Wir entwickeln Produkte, die speziell für Jira-Benutzer entwickelt wurden, darunter Einfacher agiler Teamrhythmus, Programme, Personas, und Straßenkarten.
Versuche Einfacher agiler Teamrhythmus um einfache und kollaborative Storymaps in Jira zu erstellen. Unser Tool hilft Ihnen dabei, Ihre Produkt-Backlogs in eine wirkungsvolle visuelle Darstellung der Kundenreise umzuwandeln. Es ist die Story-Mapping-App für Jira mit den höchsten Bewertungen, der über 120.000 Nutzer von Unternehmen wie Amazon, Twitter, Starbucks, Rolex und Adobe vertrauen.
Verwandte Artikel
WorkflowVerwenden Sie ein Sprint-Burndown-Diagramm, um Ihr Produkt auf Kurs zu halten
Die Stakeholder auf dem Laufenden zu halten, ist eine der Hauptaufgaben eines Product Owners. Hinter den Kulissen wird eine Menge Arbeit geleistet, bevor den Stakeholdern Informationen über die Ergebnisse und den Zeitplan eines Produkts präsentiert werden können. Wenn Sprints Ihr Framework für die Erledigung der Arbeit und die Prognose von Lieferterminen sind, muss das agile Entwicklungsteam sicherstellen, dass es den Produkt-Backlog im richtigen Tempo abarbeitet. Das Sprint-Burndown-Diagramm kann Ihnen den Weg weisen.
In diesem Beitrag werden wir darüber sprechen, wie Sie anhand eines Sprint-Burndown-Diagramms überwachen können, ob Ihr Team auf dem richtigen Weg ist, seine Arbeit abzuschließen, und wie die Einbindung von User Stories in Sprints und Epics mithilfe von User Story Maps zu noch besseren Erkenntnissen führt.
Was ist ein Sprint-Burndown-Diagramm?
Bildquelle: Atlassian
Zuerst eine Bewertung: A Sprint ist ein fester Zeitraum — in der Regel zwischen zwei und vier Wochen —, den ein agiles Softwareentwicklungsteam verwendet, um eine definierte Reihe von Arbeiten abzuschließen.
Ein Sprint-Burndown-Diagramm ist ein visueller Vergleich, wie viel Arbeit während eines Sprints abgeschlossen wurde und wie viel Arbeit insgesamt noch übrig ist. Es hilft dabei, den Fortschritt eines Scrum-Teams zu messen, und es bietet einen einfachen Überblick darüber, ob das Team Anpassungen vornehmen muss, um seine Arbeit für die aktuelle Sprint-Iteration abzuschließen.
Ein Burndown-Diagramm ist ein Graph mit einer Y-Achse und einer X-Achse 📉. Die vertikale Achse misst den Gesamtaufwand an Arbeit, den das Team nach Schätzungen im aktuellen Sprint erledigen wird. Die horizontale Achse zeigt die Anzahl der verbleibenden Tage bis zum Ende des Sprints. Auf dem Diagramm befinden sich zwei Linien: die tatsächliche Arbeitslinie (eine Linie, die den Fortschritt des Teams darstellt) und die ideale Arbeitslinie (eine gerade Linie vom oberen Ende der Y-Achse bis zum Ende der X-Achse).
Sie möchten, dass Ihre tatsächliche Arbeitslinie Ihrer idealen Arbeitslinie so genau wie möglich folgt. Das würde bedeuten, dass die Arbeit schrittweise und mit einer solchen Geschwindigkeit abgeschlossen wird, dass sie bis zum Ende des Sprints abgeschlossen werden kann. Sprintziel erreicht. 👍
Für den Product Owner eines Teams empfiehlt es sich, das Burndown-Diagramm täglich zu überprüfen. Auf diese Weise können Sie feststellen, ob während des Sprints Fortschrittsprobleme auftreten. Wenn Ihre tatsächliche Arbeitslinie beispielsweise tendenziell über der idealen Arbeitslinie liegt, bleibt zu viel Arbeit übrig, um bis zum Ende des Sprints im aktuellen Tempo erledigt zu werden. Wir werden später in diesem Beitrag einige Gründe aufschlüsseln, warum das passieren könnte. 😉
Das Sprint-Burndown-Diagramm ist auch ein großartiges Tool für die Verwendung während einer Sprint-Rückblick. Wenn man das als Team betrachtet, kann das helfen, Diskussionspunkte zu den drei wichtigsten Fragen der Sprint-Retrospektive zu generieren: Was lief im Sprint gut? Was lief nicht so gut, wie wir es uns erhofft hatten? Wie können wir im nächsten Sprint besser werden?
Eine Einführung in Schätzmethoden
Um den Kraftaufwand auf der vertikalen Achse zu messen, müssen wir eine Metrik wählen.
In der Vergangenheit nutzten traditionelle Softwareteams Zeit, um den Aufwand abzuschätzen, der für die Fertigstellung einer Aufgabe oder eines Projekts erforderlich war. Zum Beispiel: „Ich denke, ich werde drei Tage brauchen, um diese User Story fertigzustellen.“ Dieser Ansatz kann jedoch riskant sein, weil Menschen neigen dazu, zu unterschätzen die Zeit, die benötigt wird, um ein Projekt abzuschließen.
Die Maßeinheit auf der Y-Achse Ihres Sprint-Burndown-Diagramms hängt von Ihrem ab Schätzungsmetrik nach Wahl. Sehen wir uns zwei gängige Methoden an, die von agilen Sprint-Teams eingesetzt werden.
Ideale Tage
Ein idealer Tag ist eine Schätzung eines Softwareentwicklers, wie viele ununterbrochene Tage es dauern wird, eine Aufgabe zu erledigen. Unter der Annahme, dass ein idealer Arbeitstag aus acht Stunden unterbrechungsfreier Arbeit besteht, könnte die Schätzung wie folgt ausgedrückt werden: „Für diese Benutzergeschichte brauche ich idealerweise zwei Tage.“ Ein Vorteil dieses Ansatzes besteht darin, dass Arbeitsunterbrechungen berücksichtigt werden. Er kann jedoch problematisch sein, da Schätzungen häufig als Best-Case-Szenarien betrachtet werden.
Story-Punkte
Agile Teams nutzen Storypoints als relative Schätzung des Aufwands im Gegensatz zu einem zeitbasierten Ansatz. Anstatt zu sagen: „Ich glaube, ich werde zwei Tage brauchen, um diese Aufgabe zu erledigen“, würden Sie sagen: „Ich denke, diese Aufgabe ist zwei Storypoints wert.“ Bei dieser Schätzmethode sind zwei Storypoints doppelt so viel Aufwand wie ein Storypoint.
Teams können ideale Tage als Grundlage verwenden, um ihre Story-Point-Schätzungen zu kalibrieren. Ein idealer Tag kann beispielsweise einem Story Point entsprechen, zwei ideale Tage zwei Story Points usw.
Ein Hauptvorteil der Verwendung Storypoints Eine Schätzung bedeutet, dass Teams sich so auf den relativen Aufwand konzentrieren können, anstatt darüber nachzudenken, wie lange es dauern wird, eine Aufgabe zu erledigen.
Warum dein Sprint-Burndown aus dem Ruder laufen könnte
Eine perfekte echte Burndown-Linie ist wie Bigfoot — wenn sie beobachtet wurde, ist es wahrscheinlich ein Scherz. 😂
Kein Team kann seine Arbeit perfekt einschätzen und sich genau in dem Tempo entwickeln, das die Ideallinie vorgibt. Wenn Sie jedoch große Unterschiede zwischen Ihrer tatsächlichen Linie und der Ideallinie feststellen (d. h., Ihre tatsächliche Linie ist viel höher oder niedriger als die Ideallinie), können eine Reihe von Dingen passieren:
- Das Team hat sich zu viel oder zu wenig mit dem Arbeitsaufwand bei der Sprint-Planung beschäftigt
- Story Points wurden dem Sprint hinzugefügt oder daraus entfernt, nachdem er gestartet wurde (Scope Creep)
- Der geschätzte Aufwand für einige User Stories ist falsch
Wenn Sie als Product Owner nach Ihrer täglichen Überprüfung Ihres Diagramms feststellen, dass etwas an Ihrer Linie nicht stimmt, sollten Sie dies Ihren Teammitgliedern gegenüber erwähnen. Das tägliche Stand-up ist der perfekte Zeitpunkt dafür.
User Stories und Epen liefern das große Ganze
Geschichten von Nutzern beschreiben, wie ein funktionaler Teil eines Produkts aus der Sicht eines Benutzers funktionieren wird. Das übliche Format einer User Story lautet: „Als [Benutzerrolle] möchte ich [Benutzeraktivität], damit ich [Benutzerziele] erreichen kann.“ Zum Beispiel könnte man lesen: „Als neuer Kunde möchte ich mich für dieses Produkt registrieren, damit ich mein Profil erstellen kann.“
User Stories werden in Sprints platziert, um zu zeigen, welche Arbeiten (aus Nutzersicht) bis wann abgeschlossen sein werden. Sie können auch platziert werden Epen um sie innerhalb eines Produkts nach Themen zu gruppieren. Epics werden häufig von agilen Teams verwendet, um die Aktivitäten auf hohem Niveau darzustellen, die Benutzer bei der Verwendung eines Produkts ausführen.
In unserem Beispiel oben kann ein Epic alle Nutzerberichte erfassen, die sich auf die Benutzerregistrierung beziehen, z. B. die Registrierung, das Hinzufügen von Zahlungsinformationen, das Erstellen eines Benutzerprofils und das Konfigurieren von Benachrichtigungseinstellungen.
Wenn der Sprint-Burndown darauf hindeutet, dass das Team bei einem bestimmten Sprint nicht auf der Strecke ist, kann dir eine kombinierte Ansicht von Sprints und Epen dabei helfen, herauszufinden, welche Auswirkungen das auf das Gesamtbild haben könnte. Und wie wir als Nächstes sehen werden, kann eine interaktive User Story Map das Problem lösen.
User Story Maps: Ein Überblick über Epen und Sprints
Ein Sprint-Burndown-Diagramm ist eines der praktischsten Tools, die ein agiles Softwareentwicklungsteam verwenden kann, um sicherzustellen, dass es in einem soliden Tempo arbeitet und liefert. Das Burndown-Diagramm zeigt, ob Anpassungen an Ihrem Sprint vorgenommen werden müssen.
User-Story-Maps bieten weitere Einblicke in den Teamfortschritt, indem Sie:
- Sprints als vertikale Schwimmbahnen anzeigen
- Anzeige von Epen als Spalten, die die Benutzerreise durch das Produkt darstellen
Diese Kombination aus Swimlanes und Columns verringert deinen Sprint-Backlog. Es visualisiert, was das Team liefern wird und bis wann.
Mit Einfache Agile User Story Maps für Jira, kannst du deine Fähigkeit verbessern, Anpassungen an deinem Sprint vorzunehmen. Es kann dir helfen:
- Neue User Stories erstellen
- Story Points in einer User Story bearbeiten
- Ordne Gegenstände im Backlog einem Epic und einem Sprint zu
Mit diesem Tool können Teams ihre Sprint-Statistiken auf einen Blick einsehen und Maßnahmen ergreifen. Sie können sicherstellen, dass sie sich nicht zu sehr verpflichten und dass sie auf dem richtigen Weg sind, ihre Sprintziele zu erreichen. Es ist die umfassendste User-Story-Map-Lösung der Jira-Marktplatz dafür, dass Sie Maßnahmen ergriffen haben, um Ihre Sprints aus der Sicht des Gesamtbildes anzupassen.
Agile Best Practice9 Tipps, die Ihnen helfen, Ihre Sprint-Planungsmeetings zu meistern
Das Sprint-Planning-Meeting hilft agilen Teams dabei, jeden Sprint zu planen und auf derselben Wellenlänge zu sein. Es ist eine Gelegenheit, auf der Grundlage der Produktvision, der Dringlichkeit des Problems, des Feedbacks der Stakeholder und des Wissens aus dem vorherigen Sprint über die Priorisierung zu entscheiden.
Ziel des Treffens ist es, festzulegen, welche Backlog-Elemente im kommenden Sprint angegangen werden sollten. Das Team entscheidet unter der Leitung des Product Owners und des Scrum Masters, welche Elemente aus dem Produkt-Backlog in das Sprint-Backlog verschoben werden sollen, damit sie in den kommenden Wochen (Sprint-Dauer) hoffentlich abgeschlossen werden können.
Die Sprint-Planung spielt im Scrum-Prozess eine entscheidende Rolle. Das Meeting stellt sicher, dass die Teams vorbereitet in einen Sprint starten und die Arbeitsaufgaben sorgfältig ausgewählt werden. Das Endergebnis sollte ein gemeinsames Verständnis der Sprintziele sein, das als Richtschnur für den nächsten Sprint dienen wird.
Die Sprint-Planung sollte zwar vor jeder Art von Sprint erfolgen, aber für die Zwecke dieses Artikels werden wir uns auf Sprint-Planungssitzungen für Scrum-Teams konzentrieren. Lesen Sie weiter, um unsere wichtigsten Tipps für ein erfolgreiches Sprint-Planungsmeeting zu erfahren. 🎉
Wie passt das Sprint-Planungsmeeting in das Scrum-Framework?
Scrum ist eine äußerst beliebte agile Methode, die in der Produktentwicklung eingesetzt wird. Der Prozess umfasst eine Reihe von Sprints, die auf der Grundlage des kontinuierlichen Feedbacks von Kunden, Stakeholdern und Teammitgliedern verbessert und angepasst werden.
Beim Sprint-Planungsmeeting kommt das gesamte Team zusammen, um zu entscheiden, welche Arbeit es im kommenden Sprint erledigen möchte. Der Product Owner hilft bei der Entscheidung, welche wichtigen Artikel aus dem Produkt-Backlog in den Sprint-Backlog. Dies ist eine unglaublich wichtige Phase, die die Ziele des Teams in den nächsten zwei Wochen bestimmt.
Der Scrum Master fungiert als Scrum Guide. Sie helfen dem Entwicklungsteam, in jedem Sprint auf Kurs zu bleiben und stellen sicher, dass jeder das Beste aus dem Prozess herausholen kann. Das Scrum-Team arbeitet zusammen, um den Arbeitsaufwand zu erledigen, der bei der Sprint-Planung festgelegt wurde. Um sicherzustellen, dass alle auf dem richtigen Weg und auf derselben Seite bleiben, tägliche Stand-ups finden jeden Tag statt. Dies bietet den Teammitgliedern die Möglichkeit, Probleme oder potenzielle Engpässe zu lösen, die einen reibungslosen Arbeitsablauf verhindern könnten.
Im Anschluss an den Sprint findet ein Sprint-Review statt, das den Stakeholdern die Möglichkeit gibt, Feedback zu geben. Schließlich ein Sprint-Rückblick Das Treffen gibt dem Team die Möglichkeit, seinen Prozess zu bewerten und zu verbessern. Das Scrum endet und beginnt erneut mit einem weiteren Sprint-Planungsmeeting.
Hier sind einige Tipps, um sicherzustellen, dass jedes Sprint-Planungs-Meeting Sie auf Erfolgskurs bringt:
1. Reservieren Sie die gleiche Zeit für die Sprint-Planung ⏰
Buchen Sie Ihr Sprint-Planungstreffen alle zwei Wochen am selben Tag und zur gleichen Zeit, um sicherzustellen, dass Ihr gesamtes Team dieses Zeitfenster zur Verfügung hat. Die Sprint-Planung ist entscheidend für den Erfolg jedes Sprints — es ist ein Meeting, das nicht durcheinander gebracht werden sollte.
Wählen Sie eine Zeit, die für alle Beteiligten geeignet ist, und bitten Sie Ihr Team um Feedback, wann es am besten ist. Planen Sie die Besprechungen weit im Voraus in den Kalender aller Beteiligten ein, damit niemand sie vergisst oder andere Termine bucht.
2. Lege eine Sitzungsdauer für die Sprint-Planung fest und halte dich daran ⏳
Die Sprint-Planung ist wichtig, aber das heißt nicht, dass sie ewig dauern sollte. Legen Sie ein Zeitlimit für Ihr Meeting fest und tun Sie Ihr Bestes, um es einzuhalten. Wenn Sie mit einer Tagesordnung gut vorbereitet sind und verfeinerter Backlog, Sie sollten in der Lage sein, direkt mit der Planung zu beginnen.
Wir empfehlen, nicht mehr als 2-4 Stunden für die Sprint-Planung einzuplanen. Lassen Sie den Scrum Master dafür verantwortlich sein, dass das Team auf dem richtigen Weg bleibt und die Planung in der vorgesehenen Zeit abschließt.
3. Schließe die Backlog-Verfeinerung ab, bevor die Sprint-Planung beginnt 📝
Vervollständige deine Verfeinerung des Backlogs vor Ihrem Sprint-Planungsmeeting. Andernfalls werden Sie viel zu viel Zeit damit verbringen, Details hinzuzufügen, abzuschätzen oder die Arbeit aufzuteilen.
Das Sprint-Planungstreffen sollte der Planung und Zielsetzung vorbehalten sein. Das Backlog sollte zwar nicht in Stein gemeißelt sein, aber es sollte den Teammitgliedern genügend Details liefern, um mit der Planung statt mit der Verfeinerung fortzufahren.
4. Integrieren Sie das Feedback der Stakeholder aus dem Sprint Review 😍
Welche Erkenntnisse haben die Stakeholder während des Sprints oder während des Sprint Reviews geteilt? Sie entwickeln dieses Produkt für sie, daher ist es entscheidend, ihr Feedback einzubeziehen, um das Endergebnis zu erzielen.
Stellen Sie sicher, dass jede Entscheidung auf den Kundenbedürfnissen basiert. Teilen Sie Ihren Stakeholdern nach jedem Sprint Ihre Produkt- und Sprintziele mit und passen Sie sie an deren Feedback an.
5. Integrieren Sie Erkenntnisse aus der Sprint-Retrospektive 💡
Sprint-Retrospektiven sind ein wichtiger Teil des agilen Prozesses und bieten dem Team Zeit, um zu besprechen, wie es sich verbessern kann. Jedes Mal, wenn Sie einen Sprint oder eine Iteration abschließen, gibt es Lektionen zu lernen. Agile nutzt kontinuierlich das, was ein Team lernt, und setzt diese Erfahrungen in umsetzbare Verbesserungen um. Diese Lektionen zu ignorieren, wäre also sehr unagil von Ihnen. 🤔
Wie lief der letzte Sprint? War jedes Teammitglied mit dem Prozess zufrieden und was wurde erreicht? Welche Änderungen hat Ihr Team beschlossen, um den nächsten Sprint effektiver zu machen? Nutze diese Erkenntnisse, um jeden Sprint besser zu machen als den letzten.
6. Definiere klar, wie Erfolg aussieht ✅
Legen Sie klar definierte Ziele, Vorgaben und Kennzahlen fest. Was ist die Definition von erledigt? Woher weiß das Team, ob es erfolgreich ist? Sie sollten das Sprint-Planungs-Meeting mit einer klaren Vorstellung davon verlassen, was erledigt werden muss und wie Erfolg aussieht.
7. Verwenden Sie Schätzungen, um Entscheidungen auf der Grundlage der Teamkapazität zu treffen 📈
Die Überlastung Ihres Teams oder einer Einzelperson über ihre Kapazitäten hinaus schadet weit mehr als es nützt. Es ist wahrscheinlicher, dass das Team Fehler macht, und die Moral wird sinken, da die Ziele ständig außer Reichweite bleiben.
Benutzen agile Schätztechniken und Storypoints um Arbeitslast und Kapazität besser zu verstehen. Wie viel Arbeit und Mühe sind erforderlich, um Ihre Ziele zu erreichen? Stellen Sie sicher, dass Sie sich realistische und vernünftige Ziele setzen, die auf Ihren besten Schätzungen basieren.
8. Richten Sie die Sprintziele an den allgemeinen Produktzielen aus 🎉
Stellen Sie sicher, dass Sie ein Ziel für den Sprint haben und dass sich alle Backlog-Elemente auf das Endziel beziehen. Ihre Sprintziele sollten mit Ihren allgemeinen Produktzielen übereinstimmen.
Wenn Sie Ihre Ziele nicht priorisieren, kann dies zu einer zufälligen Auswahl von Aufgaben führen. Durch das Erledigen unzusammenhängender Backlog-Elemente wird zwar immer noch Arbeit erledigt, aber das führt zu unerwarteten Ergebnissen und einem geringen Erfolgserlebnis für das Team. Jedes Backlog-Element sollte mit einem klaren Zweck ausgewählt werden, der sich auf Ihre Produkt- und Sprintziele bezieht.
9. Lass Raum für Flexibilität 💫
Jede agile Methode ist von Natur aus flexibel, und Scrum ist da keine Ausnahme. Wenn es keinen Raum für Flexibilität gibt, ist etwas ernsthaft schief gelaufen.
Es ist wichtig anzuerkennen, dass nicht immer alles nach Plan läuft. Sie werden ständig neue Informationen, Erkenntnisse über Interessengruppen und Abhängigkeiten finden, an die sich das Team im Laufe der Zeit anpassen muss. Stellen Sie sicher, dass das Team versteht, dass es flexibel sein muss und dass es bei jedem Sprint unterstützt wird.
Sprint-Planung leicht gemacht
Die Effektivität der Sprint-Planung kann für ein Scrum-Team über den Erfolg oder Misserfolg der kommenden Woche entscheiden. Es ist wichtig, dass sich das Entwicklungsteam die nötige Zeit nimmt, um sich auf jeden bevorstehenden Sprint vorzubereiten. Das bedeutet, dass Sie mit klaren Zielen, dem Feedback der Stakeholder und einem verfeinerten Backlog in das Meeting gehen müssen.
Machen Sie das Beste aus Ihrer Sprint-Planung und erledigen Sie sie mit Leichtigkeit Einfacher agiler Teamrhythmus. Transformiere dein flache Produktkarten in dynamische, flexible und visuelle Repräsentationen der Kundenreise. Story Points helfen Ihrem Team dabei, Entscheidungen zu treffen und Kapazitäten zu berücksichtigen, während der Kunde stets im Mittelpunkt steht.
Erfahre mehr über die Vorteile von User Story Mapping und lesen Sie unsere ultimativer Leitfaden für User Story Maps.