Sprint Planning

TL; DR

‍Bei agilen Schätzproblemen geht es selten um die Anzahl. Planungspoker ist nützlich, wenn Teams Stimmenunterschiede als Signale über Umfang, Risiko und Abhängigkeiten betrachten. Die Abstimmung der Softwareteams bei der Schätzung verbessert die Vorhersagbarkeit des Sprints stärker als die Verfolgung der Geschwindigkeit. Geschwindigkeit allein kann die Kapazität nicht vorhersagen, da sich der Kontext bei jedem Sprint ändert. Die Koordinationsarbeit muss in Jira als erstklassige Elemente gespeichert werden, sonst werden keine Retro-Aktionen ausgeführt. Mit Easy Agile TeamRhythm bleiben Planung und Schätzung an einem Ort: Story-Mapping für die Reihenfolge, Planungspoker zum Thema für den gemeinsamen Kontext und rückwirkende Aktionen, die in nachträgliche Arbeit umgewandelt werden. Das neue E-Book, Guide to Building Predictable Delivery with Jira im Jahr 2026, erklärt, wie man klar plant, den Aufwand koordiniert und Probleme in Fortschritte umsetzt. Das Ergebnis sind weniger Rollovers, klarere Übergaben und eine zuverlässigere Lieferung.

---

Schätzung in Softwareteams ist zu einem Aufführungsritual geworden. Die Planung von Pokersitzungen läuft reibungslos, Storypoints werden zugewiesen und selbst Velocity-Charts tendieren nach oben.

Doch Forschung, die 82 Studien analysiert gefunden fünf wiederkehrende Gründe, warum Schätzungen scheitern: Informationsqualität, Teamdynamik, Schätzungspraktiken, Projektmanagement und Geschäftseinflüsse.

Der Punkt ist, dass das Problem mit Schätzungen tiefer geht als die Genauigkeit — es geht darum, was Teams übersehen, wenn sie sich auf die Zahl konzentrieren.

Wenn ein Team schätzt eine Geschichte und drei Leute sagen, es ist eine 3, während zwei sagen, es ist eine 8, dieser Spread enthält mehr Wert als die endgültige Zahl, auf die sie sich einigen. Die Uneinigkeit signalisiert unterschiedliche Annahmen über den Umfang, deckt versteckte Abhängigkeiten auf und deckt Risiken auf, bevor der Code geschrieben wird. Aber die meisten Teams betrachten die Ausbreitung als ein Problem, das es zu lösen gilt, und nicht als Informationen, die es zu extrahieren gilt. Sie diskutieren gerade lange genug, um einen Konsens zu erzielen, die Zahl aufzuzeichnen und weiterzumachen.

Das Schätzritual läuft perfekt ab, während die Koordination, die die Schätzung ermöglichen sollte, niemals stattfindet.

Warum die Zahl den Punkt verfehlt

Kommunikation, Teamkompetenz und Zusammensetzung entscheiden darüber, wie zuverlässig eine Schätzung wird weit mehr sein als die Technik selbst.

Ein Team von erfahrenen Ingenieuren, die jahrelang zusammengearbeitet haben, wird andere Schätzungen erstellen als ein neu gebildetes Team mit gemischter Erfahrung, das sogar identische Arbeiten betrachtet. Keine der beiden Zahlen ist falsch — sie spiegeln unterschiedliche Realitäten wider.

Probleme entstehen, wenn Unternehmen diesen Kontext ignorieren und Schätzungen als objektive Messwerte behandeln.

Storypoints werden teamübergreifend zusammengefasst. Die Geschwindigkeit wird zwischen den Trupps verglichen. Schätzungen, die einer Gruppe helfen sollten, sich zu koordinieren, werden zu Datenpunkten in Dashboards, ohne dass das gemeinsame Verständnis verloren geht, das ihnen ihre Bedeutung verlieh.

Was Planungspoker eigentlich verrät

Poker planen funktioniert wenn Teams es nutzen, um die Zusammenarbeit zu fördern, Risiken aufzudecken und Unsicherheiten proaktiv anzugehen. Diese Vorteile verschwinden, wenn Teams schnell über Meinungsverschiedenheiten hinwegkommen, um eine Zahl zu erreichen.

Jemand, der niedrige Macht schätzt:

• Kennen Sie eine Abkürzung aus früheren Arbeiten
• Habe schon einmal etwas Ähnliches gelöst
• Verstehen Sie einen technischen Ansatz, den andere nicht in Betracht gezogen haben

Jemand, der hohe Macht schätzt:

• Habe eine Integrationsherausforderung entdeckt
• Eine Annahme in den Anforderungen in Frage gestellt
• Ich habe mich an etwas erinnert, das letztes Mal kaputt gegangen ist
• Fehlende Abhängigkeit identifiziert

Beide Erkenntnisse sind wichtiger als die Aufteilung des Unterschieds.

Teams, die dieses Verhör überspringen, verlieren ihren einzig zuverlässigen Weg, herauszufinden, was sie noch nicht wissen. Später, wenn die Arbeit länger dauert als erwartet, geben sie der Schätztechnik die Schuld. Sie sollten dem Koordinationsfehler, der während der Schätzung passiert ist, die Schuld geben.

So fügen Teammitglieder Kontext hinzu

Recherche zeigt an dass sogar Teammitglieder, deren Fähigkeiten für einen Gegenstand nicht benötigt werden, bei der Pokerplanung wertvolle Fragen stellen.

Die Datenbankperson fragt nach dem Datenvolumen. Der Designer bemerkt ein fehlendes Randgehäuse. Der Plattformbetreuer weist auf eine Versionsinkompatibilität hin.

Keiner von ihnen versucht, die Schätzung zu erhöhen, um sich selbst zu schützen. Sie werfen legitime technische Überlegungen auf, die sich darauf auswirken, wie viel Arbeit tatsächlich damit verbunden ist. Diese Fragen offenbaren eine echte Komplexität, der das Team Rechnung tragen muss. Das ist etwas anderes, als wenn jemand ohne einen bestimmten Grund sagt: „Nennen wir es eine 8 statt 5, nur um sicher zu gehen“ (das nennt man „Padding“, und das muss ein Team um jeden Preis vermeiden).

Wenn die Schätzung zu einer Einzeltätigkeit oder einer schnellen Managemententscheidung wird, verschwindet der gesamte Kontext. Die Arbeit sieht einfacher aus als sie ist, nicht weil irgendjemand gelogen hat, sondern weil wichtige Stimmen nie gehört wurden.

Warum Teamkoordination im großen Maßstab wichtiger ist

Koordination zählt zu den größte Herausforderungen in großen Softwareprojekten, insbesondere mit komplexen Codebasen und mehreren Teams, die gleichzeitig arbeiten. Mit zunehmender Größe von Organisationen nehmen die Koordinationsprobleme zu:

• Abhängigkeiten multiplizieren sich teamübergreifend. Was früher ein Gespräch zwischen zwei Personen im selben Raum war, erfordert heute, die Roadmap eines anderen Teams zu überprüfen, herauszufinden, wem eine Komponente gehört, und darauf zu warten, dass ihr Sprint mit Ihrem übereinstimmt.
• Übergaben zwischen Spezialisten nehmen zu. Ein Feature, das ein Full-Stack-Entwickler erstellen könnte, benötigt jetzt einen Frontend-Spezialisten, einen Backend-Spezialisten, einen Plattformingenieur und einen Datenanalysten — jeder arbeitet nach unterschiedlichen Zeitplänen mit unterschiedlichen Prioritäten.
• Die Fehlerquote schrumpft. Wenn Sie die Arbeit in fünf Teams statt in einem koordinieren, kann eine einzige Fehlkommunikation oder fehlende Abhängigkeit mehrere Teams gleichzeitig blockieren und nicht nur ein Arbeitselement verzögern.
• Annahmen entfernen sich weiter von ihrer Quelle. Der Produktmanager, der mit dem Kunden gesprochen hat, ist nicht im Raum, wenn der Backend-Entwickler eine technische Entscheidung trifft. Der Kontext, der die ursprüngliche Anforderung geprägt hat, geht durch die vielen Übergaben und Dokumentationen verloren.

Kalkulationsgespräche sind oft der einzige Moment, in dem alle, die an der Ausführung der Arbeit beteiligt sind, tatsächlich darüber sprechen, bevor sie beginnen. Diese Zeit als eine Übung zur Erstellung von Geschwindigkeitsdaten zu betrachten, ist einer der größten Fehler, den Sie als Team machen könnten.

Wenn Schätzungen Pläne schützen, anstatt Risiken aufzudecken

Schauen wir uns ein bekanntes Szenario an. Ein Team legt sich auf der Grundlage der historischen Geschwindigkeit auf acht Features fest. Nach drei Sprints werden zwei Features ausgeliefert und der Rest benötigt einen weiteren Monat. Marketingkampagnen verzögern sich. Pilotprojekte für Kunden werden verschoben. Präsentationen von Führungskräften müssen neu geschrieben werden.

Das Team „hat das Engagement verpasst“, sodass die Stakeholder das Vertrauen verlieren.

Im nächsten Quartal fügen Produktmanager aus Sicherheitsgründen jedem Zeitplan zusätzliche Wochen hinzu. Führungskräfte im technischen Bereich geben längere Prognosen ab, von denen sie wissen, dass sie sie übertreffen können, und nicht ihre ehrliche, beste Schätzung. Jeder schützt sich selbst, das System verlangsamt sich, das Vertrauen schwindet weiter.

Machen Sie jetzt einen Schritt zurück — warum hat sich das Team überhaupt auf acht Funktionen festgelegt? Normalerweise, weil die Geschwindigkeit nahelegt, dass sie sie fertigstellen könnten.

Die Geschwindigkeitszahl spiegelte wider, was sie in der Vergangenheit geliefert hatten. Es spiegelte jedoch nicht wider, ob sie aus diesen Sprints etwas gelernt hatten, ob sich die Abhängigkeiten verschärften, ob sich die technischen Schulden verschärften oder ob die vor ihnen liegende Arbeit der Arbeit ähnelte, die hinter ihnen lag.

Warum Geschwindigkeitszahlen irreführen

Geschwindigkeit behandelt die Lieferkapazität als stabil, wenn sie dynamisch ist.

Teams werden schneller, wenn sie Reibungen beseitigen, und langsamer, wenn die Komplexität zunimmt. Die Zahl des letzten Sprints ist bereits veraltet, aber in den Sprintplanungssitzungen wird sie als zuverlässige Prognose behandelt.

Überlegen Sie, was Ihnen die Geschwindigkeit nicht sagen kann:

• Ob das Team aus früheren Fehlern gelernt hat
• Ob technische Schulden neue Arbeiten verlangsamen
• Ob Abhängigkeiten komplexer geworden sind
• Ob die bevorstehende Arbeit ungewohnte Technologie erfordert
• Ob wichtige Teammitglieder verfügbar sein werden

Bessere agile Schätztechniken lösen Koordinationsprobleme nicht. Teams können Koordinationsprobleme jedoch lösen, wenn sie die Koordination selbst als Arbeit betrachten, die Aufmerksamkeit verdient.

Warum die Behebung von Koordinationsproblemen für die Schätzung wichtig ist

Teams, die chaotische Schätzungssitzungen haben, wissen in der Regel genau, was falsch ist.

Jemand wird es im Standup sagen: „Wir sollten Geschichten wirklich verfeinern, bevor wir planen.“

Eine andere Person erwähnt es in Slack: „Wir müssen die Abhängigkeiten früher überprüfen.“

In der Retrospektive kommt es sogar zur Sprache: „Unsere Schätzungen sind überall, weil wir die Arbeit nicht verstehen.“

Die Erkenntnisse sind da. Was fehlt, ist die Umsetzung.

Schau dir deine letzten drei Rückblicke an. Wie viele Aktionspunkte wurden vor dem nächsten abgeschlossen?

Die durchschnittliche Abschlussrate für Retro-Actionartikel liegt bei etwa 0,33% — Teams schaffen im Grunde fast keines davon ab. Und das liegt hauptsächlich daran, dass die Verbesserungsmaßnahmen außerhalb des Systems existieren, das die Arbeit plant.

In Retrospektiven identifizieren die Teams reale Probleme:

• „Unsere Schätzungssitzungen dauern zu lang, weil wir die Geschichten nicht vorher verfeinern“
• „Wir werden immer wieder von Infrastrukturarbeiten überrascht, die nicht in unserem Backlog enthalten sind“
• „Wir verfolgen niemals die Spikes, die wir erzeugen“
• „Abhängigkeiten blockieren uns mitten im Sprint, weil wir die Kapazität nicht mit anderen Teams überprüft haben“

Alles wahr. Alles wichtig. Dann endet die Retrospektive, jeder kehrt zu seinem Sprint-Board zurück und diese Erkenntnisse können nirgendwohin gehen.

Das Backlog enthält Funktionen. Der Sprint enthält Geschichten. Und wenn überhaupt, wird die Arbeit in Sitzungsnotizen verbessert. Es konkurriert also nicht um Kapazitäten, es wird kein Eigentümer zugewiesen, es wird nicht nachverfolgt und es wird nicht erledigt.

So machen Sie Verbesserungsarbeit sichtbar

Nutzungsdaten von Easy Agile TeamRhythm zeigte, dass Teams nur 40-50% ihrer rückwirkenden Aktionspunkte abgeschlossen haben. Nach der Veröffentlichung von Funktionen zum Aufdecken und Nachverfolgen unvollständiger Aktionen stieg die Abschlussrate auf 65%.

Der Mechanismus war einfach:

1. Wandle rückblickende Erkenntnisse in JIRA-Arbeitselemente um
2. Gib jedem einen Besitzer
3. Setzt sie wie jede andere Arbeit in kommende Sprints ein
4. Machen Sie unvollständige Aktionspunkte aus den vorherigen Retros sichtbarer

Wenn Teams ihre rückblickenden Maßnahmen tatsächlich abschließen, verbessert sich die Schätzung, ohne dass die Schätzmethode geändert wird. Die Geschichten werden vor der Planung verfeinert, sodass es weniger Rätselraten gibt. Abhängigkeiten werden früher überprüft, sodass es weniger Überraschungen gibt. Das Team baut im Laufe der Zeit ein gemeinsames Verständnis auf, sodass die Spreads beim Planungspoker enger und die Diskussionen kürzer werden.

Wie Sie sehen können, handelt es sich um einen Welleneffekt.

Koordinationsprobleme verschärfen sich, wenn sie ignoriert werden, aber sie verbessern sich auch, wenn sie als echte Arbeit behandelt werden.

Ein Team, das seine Planungsprobleme nie löst, wird im nächsten Quartal und im darauffolgenden Quartal chaotische Schätzungen abhalten. Ein Team, das bewusst die Koordination verbessert, benötigt nach und nach weniger Zeit, um die Softwareteams besser aufeinander abzustimmen, und nebenbei werden die Schätzungen zuverlässiger.

Was das für Tools und Praxis bedeutet

Die meisten Planungstools wurden für die Verwaltung von Aufgaben entwickelt und unterstützen nicht die Konversationen, die Teams bei der Koordination dieser Aufgaben unterstützen. Die Herausforderung besteht nun darin, die Koordination an derselben Stelle, an der die Lieferarbeiten stattfinden, sichtbar und nachverfolgbar zu machen.

Einfacher agiler Teamrhythmus führt die Koordinationsarbeit neben den Lieferarbeiten durch.

✅ Die User Story Map zeigt, wie Arbeit und Ziele miteinander verknüpft sind. So wird die Reihenfolge zu einer gemeinsamen Diskussion und nicht zu einer privaten Tabelle.

✅ Planungspoker findet in der Jira-Ausgabe statt, wo jeder die gleichen Akzeptanzkriterien und Anlagen sieht — so wird die Streuung der Schätzungen zu einem Gesprächsstoff und nicht zu einer Zahl, auf die man sich einigen kann.

✅ Rückwirkende Maßnahmen werden direkt in Backlog-Elemente umgewandelt, die in kommenden Sprints hinzugefügt werden, sodass Verbesserungsarbeiten die Aufmerksamkeit erhalten, die sie verdienen.

Es steht immer mehr auf dem Spiel, um das richtig zu machen. Atlassians Streben nach KI-Unterstützung bedeutet, dass deine Planungsdokumente von mehr Personen gelesen und von mehr Systemen verarbeitet werden. Wenn Rovo deine Jira-Instanz durchsucht, wird alles angezeigt, was du geschrieben hast — klare Ziele und explizite Abhängigkeiten oder vage Titel und versteckte Annahmen.

Ein unscharfes Sprintziel verwirrt nicht nur dein Team. Es verwirrt das Dutzend Leute aus drei Zeitzonen, die dein Board asynchron lesen, die Automatisierung versucht, relevante Arbeiten zu identifizieren, der KI-Assistent versucht, Status-Updates zu generieren, und die Stakeholder, die versuchen, den Fortschritt zu verstehen.

Wo das hinführt

Die Teams, die in den nächsten Jahren erfolgreich sein werden, werden nicht diejenigen sein, die über die ausgefeiltesten agilen Schätztechniken oder die höchsten Geschwindigkeitswerte verfügen.

Es werden Teams sein, in denen bei der Pokerplanung Risiken aufgedeckt werden, anstatt Verpflichtungen einzugehen. Wo Retrospektiven zu Arbeitselementen führen, anstatt Wunschdenken zu erzeugen. Wo die Koordination in Jira auftaucht, anstatt in Konversationen besprochen zu werden, die verschwinden.

Es werden Teams sein, die herausgefunden haben, dass es bei Schätzungen nie um Zahlen geht. Es ging immer darum, dass alle mit offenen Augen in dieselbe Richtung zeigen, bevor die Arbeit beginnt.

Die Zahl ist nur das, was aufgeschrieben wird. In der Konversation, die das Team zur Nummer führt, liegt die eigentliche Arbeit.

TL; DR‍

Die Sprint-Planung fühlt sich schwieriger an, weil verteilte/asynchrone Arbeit, Toolkonsolidierung und Atlassian-KI zu Prioritätsproblemen, Software-Schätzproblemen und versteckten Abhängigkeiten führen. In diesem Leitfaden werden drei bewährte Methoden für die Teamplanung vorgestellt: Lege eine klare Arbeitsreihenfolge fest, schätze gemeinsam, um Risiken aufzudecken, und schließe den Kreislauf mit handlungsorientierten Rückblicken, damit die Abstimmung und Zusammenarbeit im Team verbessert wird und die Pläne Bestand haben.

---

Die Sprintplanung sollte sich nicht wie ein Geschrei anfühlen, bei dem die lauteste Stimme gewinnt. Für viele Teams ist es jedoch ein langes Meeting geworden, das Energie verbraucht, einen schwachen Plan erstellt und am Mittwoch auseinanderfällt.

Das Problem ist nicht, dass Ihr Team vergessen hat, wie man plant. Die Welt rund um den Plan hat sich geändert. Die Leute arbeiten in verschiedenen Zeitzonen. In Kommentaren und Tickets werden mehr Entscheidungen getroffen als in Räumen. Und der Plan steckt in Tools, die andere Leute (und die KI-gestützte Suche) später lesen werden. Wenn das Publikum von „Wer war an der Besprechung“ zu „jedem, der die Arbeit berührt“ wechselt, muss der Plan klarer und besser organisiert sein.

Einerseits KI und asynchrone Zusammenarbeit sind auf dem Vormarsch. Auf der anderen Seite haben wir eine direkter Link zwischen starken Lieferfähigkeiten und besserer Leistung. Und diese beiden Linien treffen bei der Planung aufeinander — wenn die Eingaben unklar sind, macht man einfach schneller die falschen Dinge.

Wir glauben, dass sich die Planung schwieriger anfühlt, weil drei grundlegende Elemente zusammengebrochen sind:

• Wie aus Prioritäten eine Arbeitsreihenfolge wird,
• wie Schätzungen das Risiko anzeigen (nicht nur Zahlen), und
• Wie aus Verbesserungsvorschlägen echte Arbeit wird.

Wenn diese schwach sind, wird Planung zu einer Übung zur Bewältigung der Metallüberflutung, anstatt einen klaren Weg in die Zukunft zu finden.

In diesem Artikel wird untersucht, warum die Sprint-Planung so schwierig geworden ist, was sich 2025 geändert hat, um es noch schlimmer zu machen, und vor allem, wie Teams diese drei Grundlagen korrigieren können, sodass Ihr Plan immer noch Sinn macht, wenn jemand, der das Meeting verpasst hat, ihn zwei Tage später liest.

Die mentale Belastung moderner Planung

„Kognitive Belastung“ ist einfach die Menge an geistiger Anstrengung, die eine Person gleichzeitig bewältigen kann. Jedes Team hat ein Limit, wie viele Informationen es zu einem bestimmten Zeitpunkt speichern kann, und die Planung von Besprechungen geht jetzt weit darüber hinaus.

Gleichzeitig werden die Teams gebeten:

• Rangieren Sie Funktionen gegen unklare Ziele,
• Schätzen Sie die Arbeit, die sie noch nicht vollständig erforscht haben,
• Stelle dich mit Plattformteams zusammen, deren Zeit ungewiss ist,
• Balancieren Sie die Anforderungen verschiedener Interessengruppen,
• Finden Sie Abhängigkeiten zwischen Systemen heraus, die sie nicht kontrollieren, und
• Versprich Termine, die andere genau verfolgen werden.

Oft werden Pläne so gemacht, als ob alle voll verfügbar sind und nicht auch an bestehenden Projekten und Aufgaben arbeiten. Und wir alle wissen ganz genau, dass das niemals der Fall ist. Wenn die mentale Belastung zu hoch ist, können Teams die Software, an der sie arbeiten, nicht sicher besitzen oder ändern.

Die Planung wird dann zu einem Engpass, bei dem Teams mehr Zeit damit verbringen, die Komplexität der Koordination zu bewältigen als mit der eigentlichen Koordination. Entscheidungen scheitern, Annahmen werden nicht überprüft, und der Plan, der herauskommt, ist kein geteiltes Verständnis aber ein schwacher Kompromiss, der niemanden zufrieden stellt.

Wo Prioritäten scheitern

In den meisten Planungssitzungen hat „Priorität“ an Bedeutung verloren. Alles ist P0. Alles ist dringend. Alles muss in diesem Sprint passieren. Wenn alles oberste Priorität hat, ist es nichts.

Teams haben Schwierigkeiten, Prioritäten zu setzen, weil es zu viele bewegliche Teile gleichzeitig gibt: viele Beteiligte, lange Rückstände und Prioritäten, die sich von Woche zu Woche ändern. Die meisten Priorisierungsmethoden wie MoSCoW, WSJF und RICE funktionieren für eine kleine Liste und eine kleine Gruppe, aber sie funktionieren nicht mehr, wenn die Liste und das Publikum groß werden. Besprechungen werden länger, Ergebnisse werden inkonsistent, und jedes Mal, wenn sich etwas ändert, alles neu zu ordnen, ist nicht praktikabel. Die Leute lernen auch, die Zahlen zu „spielen“, um ihren Artikel nach oben zu bringen.

Es gibt ein zweites Problem: Diese Methoden gehen davon aus, dass sich alle darüber einig sind, was „Wert“ bedeutet. In Wirklichkeit wollen Vertrieb, Compliance, Plattform, Design und Support oft unterschiedliche Dinge. Numerische Modelle (wie einfache Bewertungen) lassen diese Unterschiede außer Acht, weil einige Kompromisse (wie Markenrisiko, Kundenvertrauen, regulatorische Fristen) leichter zu erörtern sind, als sie in einer einzigen Zahl zusammenzufassen.

EIN flacher Produktbestand macht das noch schlimmer. Wie Jeff Patton sagt, ist das Lesen eines Backlogs als eine lange Liste so, als würde man versuchen, ein Buch zu verstehen, indem man eine Liste von Sätzen in zufälliger Reihenfolge liest — der gesamte Inhalt ist da, aber die Geschichte ist weg. Ohne die Geschichte wird „Priorität“ zu einem Etikett, das die Leute verwenden, um Argumente für sich zu gewinnen, und nicht für eine klare Reihenfolge der Arbeit.

Einfach ausgedrückt, wenn die Arbeit und die Anzahl der Stimmen zunehmen, können die üblichen Techniken nicht mehr mithalten. Wenn Sie nicht in der Lage sind, unterschiedliche Sichtweisen aufzuzeigen und Kompromisse zu vereinbaren, weichen Entscheidungen von der Strategie ab, Pläne ändern sich ständig, weil sie nie an Ergebnisse gebunden waren, und Ingenieure verstehen nicht mehr, warum ihre Arbeit wichtig ist.

Die Schätzung zeigt

Teams sind in der Regel zu optimistisch über Aufwand und zu viel Vertrauen in ihre Schätzzahlen. Im Durchschnitt dauert die Arbeit etwa 30% länger als erwartet. Selbst wenn die Leute angeben, dass sie zu 90% sicher sind, dass ein Bereich den tatsächlichen Aufwand abdeckt, ist dies nur in 60— 70% der Fälle der Fall.

Übersetzung: Selbstvertrauen fühlt sich gut an, bedeutet aber nicht Genauigkeit.

Die tiefere Frage ist, wie wir schätzen. Es wird oft allein geraten, anstatt gemeinsam das Risiko zu überprüfen.

Folgendes passiert tatsächlich: Jemand sieht ein Arbeitselement namens „API aktualisieren“, gibt ihm 5 Punkte allein aufgrund des Titels und das Team macht weiter. Niemand testet die Annahmen, die hinter der Zahl stehen.

Niemand spricht über die Änderungen der Authentifizierungsebene, die durch „Update“ impliziert werden. Niemand spricht die Datenbankmigration an, die sich vor aller Augen versteckt. Niemand überprüft, ob das Frontend-Team weiß, dass diese Änderung bevorsteht.

Und wenn diese mitten im Sprint auftauchen, scheitert der Plan und das Vertrauen sinkt.

Nach ein paar Fehlschüssen verschlechtert sich das Verhalten. Die Leute beginnen, ihre Schätzungen aufzufüllen und runden die Zahlen leise auf um sich sicher zu fühlen. Das Produkt beginnt dann, sich zurückzudrängen. Und aus Schätzung wird Verhandlung, nicht Lernen.

Ein gesünderes Signal zum Anschauen ist das Streuung der Schätzungen. ‍Eine große Streuung von Schätzungen ist kein Problem, das es zu glätten gilt, sondern eher ein Signal zur Diskussion von Annahmen. Höchstwahrscheinlich wird es einen gewissen Unterschied zwischen den ursprünglichen Schätzungen geben, sodass jedes Teammitglied eine großartige Gelegenheit hat, darüber zu sprechen, warum seine Schätzungen entweder höher oder niedriger als die anderen waren.

Die Koordinationskosten von Abhängigkeiten

Wenn verschiedene Teams verbundene Teile des Systems besitzen, kann die Arbeit eines Teams oft erst dann voranschreiten, wenn ein anderes Team eine Änderung vornimmt. Wenn diese Teams nicht in einer Reihe stehen, bleibt die Änderung hängen.

Dies ist häufig der Fall, wenn die Art und Weise, wie die Software verkabelt ist, nicht mit der Organisation der Teams übereinstimmt.

Im Code steht beispielsweise „Service A muss sich vor Service B ändern“, aber A und B leben in unterschiedlichen Teams mit unterschiedlichen Prioritäten, Sprint-Terminen und Aufnahmeregeln. Der Code erfordert Koordination, aber das Organigramm sieht sie nicht vor.

In großen Organisationen sind diese kleinen Links auf Arbeitselementebene ein ständige Quelle der Verzögerung. Und in letzter Zeit ist es nur noch schlimmer geworden.

Das Plattform-Engineering ist gewachsen, und die meisten Funktionen betreffen jetzt gemeinsame Dienste — Authentifizierung, Datenplattformen, CI/CD, Komponentenbibliotheken. Die Planung erfolgt jedoch oft, ohne dass das Plattformteam im Raum anwesend ist. Niemand überprüft ihre Kapazität, niemand testet die Reihenfolge der Arbeiten, und es gibt keine Einigung über Aufnahmefenster oder darüber, was zu tun ist, wenn etwas blockiert ist.

Auf dem Papier sieht der Plan also fertig aus. Geschichten sind groß. Der Sprint ist abgeschlossen. Dann, nach drei Tagen, sagt jemand im Stand-up: „Diese API wird erst nächsten Dienstag fertig sein“, oder „Das Plattformteam ist überfordert“ oder „Das Bereitstellungsfenster am Freitag ist nicht verfügbar“. Die Arbeit wartet, die Leute warten und Geld brennt, während nichts vorankommt.

Abhängigkeiten erhöhen Sie die Komplexität in jedem System. Höhere Komplexität bedeutet mehr Leerlaufzeiten, wenn die Arbeit zwischen Personen oder Teams ausgetauscht wird. Entwickler warten also oft darauf, dass andere Arbeiten abgeschlossen sind, bevor sie beginnen können, was zu Ineffizienzen führt, die keinen Mehrwert bringen, aber dennoch Lohn- und Budgetkosten kosten.

Was hat sich 2025 geändert

Drei Schichten im Jahr 2025 erschwerten die Planung noch weiter:

1. Verteilte Arbeit reduzierte die Live-Koordination.

Hybride Tage ersetzt jeden Tag im selben Raum zu sein. Mehr Arbeit passiert asynchron. Das bedeutet, dass Ihre schriftlichen Pläne und Notizen wie Sprintziele, Storymaps und Abhängigkeitsnotizen erklären müssen, was in Gesprächen in Echtzeit früher behandelt wurde: warum diese Arbeit wichtig ist, was zuerst kommt, was nicht passt, wer daran beteiligt ist und was Sie blockieren könnte. Vage Ziele, die persönlich festgelegt werden könnten, fallen jetzt in allen Zeitzonen auseinander.

2. Weniger Tools, ein System.

Mannschaften Anbieter kürzen um die Ausgaben zu reduzieren. Planung, Schätzung und Rückblick wurden in einer Lösung zusammengefasst, unabhängig davon, ob sie gut passten oder nicht. Das reduziert zwar die Zahl der Kontextwechsel, bedeutet aber auch, dass die Teams auf spezielle Tools und benutzerdefinierte Workflows verzichten müssten. Das bedeutet auch, dass alle Beteiligten die gesamte Bandbreite von der Strategie bis hin zu den Storys an einem Ort sehen können, sodass Ihre Sprintziele, Schätzungen und Rückblick-/Verbesserungsmaßnahmen genauer gelesen werden können.

3. Atlassian AI hat die Erwartungen geweckt.

Atlassian erweitertes Rovo in Jira und Confluence. Suche, Steuerung und Automatisierung verbinden jetzt Konversationen mit Problemen und beschleunigen die Erkennung. Und die Sache mit KI ist, dass sie jede Richtung beschleunigt, in die Sie bereits eingeschlagen haben. Wenn Ziele verschwommen sind, wenn Schätzungen Vermutungen sind und wenn Abhängigkeiten verborgen sind, hilft Ihnen die Automatisierung nur dabei, schneller in die falsche Richtung zu gehen.

Die Kombination all dieser Änderungen ist brutal: mehr Koordination erforderlich, weniger Überschneidungen bei der Abstimmung in Echtzeit und höhere Strafen, wenn Pläne scheitern, weil die Beteiligten jetzt mehr vom Gesamtbild sehen können.

Die Grundlagen schaffen: Best Practices für die Sprint-Planung

Die Teams, die für die Planung zuständig sind, haben ihre Grundlagen anhand von drei bewährten Planungsmethoden neu aufgebaut. Es sind einfache, geschriebene Regeln, die das gesamte Team befolgt. Sie sind von der Planungstafel und den Arbeitsaufgaben abhängig, sodass sie auch nach Übergaben und über Zeitzonen hinweg immer noch Sinn machen.

1. Setzen Sie Prioritäten in eine klare Arbeitsreihenfolge um

Die „Priorität“ wird unterbrochen, wenn Menschen nicht dieselbe Wertvorstellung teilen. Die Lösung besteht darin, sich auf eine einzige, sichtbare Reihenfolge zu einigen — warum zuerst diese, dann die und was passt nicht in diesen Sprint.

Teams, die das richtig machen:

• Verwandeln Sie Ziele und Ergebnisse in Backlog-Arbeit in einem gleichmäßigen Rhythmus, nicht ad hoc.

Einmal im Monat bestätigen Produkt und Lieferung die Ziele und teilen sie für die nächsten 6—8 Wochen in epische und kleine Abschnitte auf. Auf diese Weise bleibt sinnvolle Arbeit in der Pipeline, ohne die Annahmen und Wünsche, die sich ohnehin ändern werden, zu überfordern.

• ‍Schreiben Sie testbare Sprintziele mithilfe einer konsistenten Vorlage.

Ziel, Test, Einschränkung. Legen Sie klar definierte Ziele, Vorgaben und Kennzahlen fest. Was ist die Definition von erledigt? Woher weiß das Team, ob es erfolgreich ist? Du solltest das verlassen Besprechung zur Sprint-Planung mit einer klaren Vorstellung davon, was getan werden muss und wie Erfolg aussieht. Zum Beispiel ist „Benutzer können den Checkout mit gespeicherten Zahlungsmethoden abschließen, ohne die Kartendaten erneut eingeben zu müssen“ viel besser als „Verbessern Sie die Checkout-UX jedes Mal“. Wenn du nicht verifizieren kannst, ob du es erreicht hast, ist das ein Wunsch, kein Ziel.

• ‍Führen Sie eine 30-minütige Überprüfung durch, bevor Sie etwas planen.

Vereinbaren Sie die Reihenfolge der Arbeiten, bevor Sie die Termine festlegen. In 30 Minuten mit den Konstruktions-, Design- und Plattformteams: Gehen Sie die Liste der Abhängigkeiten durch, überprüfen Sie die Kapazität und identifizieren Sie die wichtigsten Risiken. Ergebnis: geordneter Pfad zum Erledigen, klare Abgrenzung dessen, was nicht in diesen Sprint passt, und eine einfache Regel für den Umgang mit blockierten Elementen. Dadurch kommen teamübergreifende Spannungen zum Vorschein, bevor es mitten im Sprint zu einer Krise kommt.

• ‍Machen Sie Abhängigkeiten dort sichtbar, wo Menschen tatsächlich planen.

Verwende ein Standardabhängigkeitsfeld und zwei bis drei Linktypen in Jira. Überprüfe die Links mit dem höchsten Risiko während der Planung — nicht, wenn sie am dritten Tag die Arbeit blockieren.

Einfache Agile TeamRhythms Story-Maps von Benutzern macht diesen Prozess konkret — Lege Ziele und Ergebnisse an oberster Stelle fest, Arbeitselemente, die mit diesen Zielen in Verbindung stehen, und sprinte oder versioniere Swimlanes, um sie klar zu gruppieren. Aktiviere Abhängigkeitslinien, damit Hindernisse und teamübergreifende Verbindungen in der Planung auftauchen. Wenn Epen zu Ergebnissen führen, wenn sich die Reihenfolge der Arbeit von selbst erklärt und wenn Abhängigkeiten auf derselben Tafel sichtbar sind, hören Sie auf, Prioritäten zu überdenken und beginnen mit der Umsetzung.

2. Schätzen Sie gemeinsam ab, um Risiken frühzeitig zu erkennen

Bei der Schätzung geht es nicht darum, eine perfekte Zahl zu erreichen. Es ist eine schnelle Methode, um Risiken zu identifizieren, während Sie den Umfang oder die Reihenfolge noch ändern können. Behandeln Sie es wie ein kurzes, zielgerichtetes Gespräch, das verborgene Annahmen sichtbar macht und aufzeichnet, was Sie gelernt haben.

• ‍Schätzen Sie zusammen, leben Sie.‍

Lauf Poker planen aus der Jira-Problemansicht, sodass jeder den gleichen Titel, die gleiche Beschreibung, die gleichen Akzeptanzkriterien, Designs und Anlagen sieht. Halte die ersten Stimmen versteckt und zeige sie alle zusammen an (damit die erste Zahl den Rest nicht beeinflusst).

Easy Agile TeamRhythm hilft Ihnen beim Ausführen des Einschätzung Prozess in Jira, genau dort, wo die Arbeit stattfindet. Erfassen Sie die wichtigsten Punkte der Diskussion in den Kommentaren in der Themenansicht. Synchronisiere die endgültige Schätzung wieder mit Jira, sodass dein Plan auf der aktuellen Realität basiert und nicht auf alten Schätzungen von vor zwei Wochen.

• ‍Notieren Sie die Argumentation, nicht nur die Zahl.‍

Wenn sich eine Geschichte von einem bewegt 3 zu einem 8 fügen Sie nach der Diskussion zwei kurze Anmerkungen zum Arbeitselement hinzu:‍

- Was hat sich geändert in der Konversation (die Annahme, die Sie aufgedeckt haben), und‍

- Was ist noch unbekannt (das Risiko, dem Sie ausgesetzt sind)

Das hilft der nächsten Person, die es aufgreift, und verhindert, dass Sie dieselbe Debatte später wiederholen.

• Halten Sie sich an klare, einfache Skalen.

Die Zeitschätzungen variieren stark von Person zu Person. Story Points helfen Teams stattdessen dabei, sich auf den Aufwand zu einigen. Wenn Sie jedes Teammitglied bitten, den Zeitaufwand für eine Aufgabe abzuschätzen, erhalten Sie wahrscheinlich 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 für die Erledigung eines Arbeitselements erforderlich ist. Das bedeutet, dass Sie einen Konsens erzielen und viel schneller mit Ihrem Story-Mapping oder Ihrer Sprint-Planung fortfahren können.

Pflegen Sie einen kleinen Satz aktueller Arbeitselemente (einfach/mittel/schwer) mit Schätzungen und Istwerten. Wenn die Diskussionen nicht zu Ende zu gehen scheinen, verweisen Sie auf diese bekannte Arbeit: „Das sieht aus wie der Auth-Refactor vom Juni — das war eine 8 und hat sechs Tage gedauert, einschließlich des Migrationsskripts.“

• ‍Beschränken Sie die festgelegte Arbeit auf etwa 80-85% der durchschnittlichen Kapazität.

Der Raum bietet Platz für einen Verbesserungsgegenstand, für unvermeidliche Unterbrechungen und für die Realität. Wenn Sie sich unerreichbare Ziele setzen, ist Ihr gesamtes Team zum Scheitern verurteilt. Wenn Sie Ihre Sprintziele Sprint für Sprint nicht erreichen, schadet dies der Motivation und Moral des Teams. Verwenden Sie Schätzungen, um so gut wie möglich vernünftige Ziele zu setzen. Berücksichtigen Sie die Teamkapazität auf der Grundlage Ihrer bisherigen Erkenntnisse darüber, wie lange die Erledigung von Aufgaben dauert, wie das Team arbeitet und welche Hindernisse sich dabei ergeben könnten.

Schützen Sie die Ehrlichkeit der geschätzten Zahlen. Eine Schätzung ist eine gemeinsame Einschätzung von Umfang und Risiko und kein Ziel, das durchgesetzt werden muss. Wenn es sich ändern muss, ändern Sie es nach einer Teambesprechung — überschreiben Sie es nicht. Denken Sie daran, was wir zuvor gesagt haben: Wenn aus einer Schätzung eine Verhandlung wird, fangen die Leute an, eine Zahl zu „übertreiben“ (leise zu übertreiben) um sich sicher zu fühlen), und die Genauigkeit wird schlechter.

3. Der Kreis der Verbesserungen wurde geschlossen

Teams tappen oft in die Falle, rückblickende Artikel als gute Absichten und nicht als klare Maßnahmen zu verfassen. Allgemeine Hinweise wie „Verbessern Sie die Kommunikation“ oder „Korrigieren Sie unseren Prozess“ klingen auf dem Papier gut, aber sie sagen niemandem, was als Nächstes zu tun ist.

‍Aktionselemente werden bei einer Retrospektive oft ignoriert. Jeder konzentriert sich darauf, die Menschen dazu zu bewegen, ihre Ideen zu verbreiten, und es wird nicht so viel Zeit mit den Aktionspunkten und dem, was als Ergebnis getan oder geändert wird, aufgewendet.

• ‍Beginne jedes Retro, indem du die Aktionen des letzten Sprints überprüfst.‍

Zehn Minuten. Haben wir sie geschlossen? Haben sie geholfen, falls geschlossen? Was haben wir gelernt? Auf diese Weise setzt das Team das Gelernte sofort um und jeder kann sehen, was sich geändert hat.

• ‍Verwandeln Sie Erkenntnisse sofort in JIRA-Arbeitselemente.‍

Jede Aktion benötigt einen Besitzer, ein Fälligkeitsdatum, einen Link zur zugehörigen Arbeit und eine klare Definition von erledigt. Wenn du sie nicht sofort zuweisen kannst, ist sie nicht umsetzbar, es handelt sich um eine Beschwerde.

Einfache Agile TeamRhythms Rückblick lebt direkt in Jira, an dein Board angeschlossen. Verwandle rückwirkende Elemente in Jira-Ausgaben mit Inhabern und Datum, verknüpfe sie mit einem epischen oder Backlog-Objekt und setze mindestens eines davon in den nächsten Sprint ein. Erfasse unvollständige Aktionspunkte und sich wiederholende Themen auf derselben Seite wie die Bearbeitung.

• ‍Machen Sie in jedem Sprint Platz für einen Verbesserungsgegenstand.‍

Wähle einen Aktionspunkt für einen Sprint aus und beende ihn, bevor du einen anderen startest, damit er nicht durch Feature-Arbeit zur Seite geschoben wird. Behandle Aktionspunkte wie ein Feature: Schätzen Sie es ein, verfolgen Sie es und schließen Sie es mit einer Notiz über das Ergebnis und die Auswirkungen ab.

• ‍Schreiben Sie eine kurze Wirkungsnotiz, wenn Sie eine Aktion abschließen.‍

Ein Retro sollte den Menschen Energie geben. Es sollte ihnen zeigen, dass wir besser werden, dass ihre Stimme wichtig ist, dass etwas besser geworden ist, weil sie etwas gesagt haben.

Schreiben Sie eine einzeilige Wirkungsnotiz für jede abgeschlossene Maßnahme, idealerweise mit einer kleinen Kennzahl — zum Beispiel „Zusammenfassen von PR-Reviews in zwei täglichen Zeitfenstern — die durchschnittliche Überprüfungszeit ist von sechs Stunden auf 90 Minuten gesunken“. Das unterrichtet das nächste Team, rechtfertigt die Investition und zeigt, dass Aktionen im Nachhinein die Fähigkeit des Teams erhöhen, Ergebnisse zu liefern, und dass es sich nicht um Verwaltungsaufwand handelt.

Was ändert sich, wenn Sie die Best Practices für die Planung befolgen

Teams mit soliden Grundlagen der Sprint-Planung sprechen selten über sie. Sie sind nicht auf der Bühne und erklären ihren Prozess. Sie liefern nur feste Arbeit, während sich alle anderen fragen, was ihr Geheimnis ist.

Es gibt kein Geheimnis. Die besten Teams haben einfach aufgehört, Planung als Besprechung zu betrachten, um zu überleben, und beginnen, sie als ein System bewährter Verfahren zu betrachten, das sich im Laufe der Zeit weiterentwickelt.

Die mentale Belastung durch die Planung von Sitzungen lässt nicht nach. Aber es verschiebt sich. Anstatt alles live in einem Raum unter Zeitdruck zu verarbeiten, haben diese Teams ihre Antworten in schriftlichen Plänen und Notizen festgehalten, die ihnen das Denken abnehmen.

Die User Story Map erklärt, worauf es ankommt und warum. Die Reihenfolge der Arbeiten zeigt Abhängigkeiten, bevor sie die Arbeit blockieren. Die Schätzwerte und Notizen erfassen nicht nur Zahlen, sondern auch die zugrunde liegenden Annahmen. Retro-Aktionspunkte stehen neben der Arbeit am Produkt, sodass der nächste Sprint von dem profitiert, was der letzte Sprint gelernt hat.

Wenn Sie die Best Practices korrigieren, werden sich Ihre Herausforderungen bei der Sprint-Planung verringern. Nicht perfekt. Nicht für immer. Aber genug, dass sich Planung nicht mehr wie eine Krise anfühlt und sich so anfühlt, wie sie sein sollte: eine ruhige Sicht auf das, was jetzt möglich ist, mit einfachen Möglichkeiten, sich anzupassen, während Sie lernen.

Die Kosten unklarer Pläne steigen. KI beschleunigt, was Sie ihr geben. Stakeholder können auf einfache Weise mehr Details einsehen. Die Arbeit findet zeitzonenübergreifend statt. In dieser Welt ist Klarheit kein nettes Extra — sie ist eine Grundvoraussetzung.

Die Teams, die 2026 gut abschneiden werden, sind nicht diejenigen mit besseren Tools oder intelligenteren Frameworks. Sie werden diejenigen sein, die ein paar einfache Best Practices in den Plan und die Arbeitsaufgaben geschrieben haben, sodass Übergaben einfach sind, andere sie überprüfen und verstehen können und sie auch nach dem Meeting Sinn machen.

In Hunderten von Teams sahen wir dasselbe Muster: Retrospektiven fanden regelmäßig und mit Bedacht statt — und doch wurde weniger als die Hälfte der retrospektiven Aktionspunkte jemals abgeschlossen. Die Teams identifizierten immer wieder wertvolle Verbesserungen, aber diese Verbesserungen kamen bei der Umsetzung ins Stocken. Anstatt Veränderungen voranzutreiben, tauchten dieselben Probleme Sprint für Sprint wieder auf.

Als wir mit den Kunden sprachen, war ihnen nicht klar, was sie verbessern sollten — sie waren sogar nicht sicher, wie sie das umsetzen sollten. Durch den Mangel an Transparenz, Rechenschaftspflicht und Priorisierung fühlten sich Fortschritte unerreichbar an.

Diese Frustration veranlasste uns, unsere Herangehensweise an Retrospektiven zu überdenken. Nicht nur im Raum, sondern auch in den Tagen und Wochen, die darauf folgen. Denn während die meisten Teams wissen, wie man reflektiert, wissen weit weniger, wie man voranschreitet.

Willst du direkt in die Action eintauchen? Schnapp dir unsere kostenlose Vorlage für retrospektive Aktionen hier - eine klare, praktische Anleitung, die Ihrem Team hilft, sich nicht mehr im Kreis zu drehen und Fortschritte zu erzielen, die wirklich hängen bleiben.

Oder wenn Sie den tieferen Grund hinter dieser Herausforderung verstehen möchten, lesen Sie weiter.

Der unsichtbare Friedhof guter Ideen

Denke zurück an deine letzten Retros. Sie sind wahrscheinlich auf Blocker gestoßen, haben Siege gefeiert und vielleicht sogar eine schwierige Teamdynamik ausprobiert. Die Diskussion fühlte sich wahrscheinlich ehrlich an — sogar wertvoll.

Fragen Sie sich jetzt: Was hat sich dadurch tatsächlich geändert?

Allzu oft gehen rückblickende Aktionspunkte, selbst die gut gemeinten, im Zuge eines neuen Sprints verloren. Das Jira-Board füllt sich, die Deadline rückt näher und die sorgfältig überlegten Ideen treten in den Hintergrund.

Es ist nicht so, dass es Teams egal wäre. Es ist so, dass uns oft ein System fehlt, mit dem wir aus Team-Retrospektiven heraus Maßnahmen ergreifen können, die nachverfolgbar und in unsere eigentliche Arbeit integriert sind.

Wir haben das Muster gesehen: Teams setzen sich Retro für Retro mit denselben Problemen auseinander. Mit der Zeit schwächt diese Wiederholung das Vertrauen ab. „Haben wir nicht schon darüber gesprochen?“ wird zum Refrain, und irgendwann fühlt sich das Retro wie ein Ritual ohne Belohnung an.

Das Folgeproblem

Die meisten Retrospektiven scheitern nicht während der Sitzung selbst; sie geraten in den Tagen und Wochen danach ins Stocken. Laut einem Umfrage In der PMI-Community haben fast zwei Drittel der Befragten weniger als 25% der Ideen aus ihren Retros umgesetzt — keiner gab an, mehr als 75% umgesetzt zu haben.

„Wenn dein Team während der Retrospektiven ständig Aktionspunkte erstellt, sie aber selten abschließt, bist du nicht allein. Unvollendete Aktionspunkte sind ein großer Produktivitätskiller und führen dazu, dass Fortschritte ins Stocken geraten. Der Schlüssel zu echten Verbesserungen liegt nicht in der Erstellung langer Listen, sondern in der Umsetzung. Indem Sie rückwirkende Aktionspunkte mit der gleichen Wichtigkeit behandeln wie andere Sprint-Aufgaben, kann Ihr Team endlich den Kreislauf unvollendeter Verbesserungen durchbrechen und echte, positive Veränderungen erleben, individuell und auf Teamebene. „- Stefan Wolpers, Zeitalter des Produkts

Retrospektive Anti-Patterns

Teams haben aufgrund einer Kombination von Anti-Mustern, die die Rechenschaftspflicht und Dynamik schwächen, ständig mit der Umsetzung zu kämpfen:

Folgemaßnahmen scheitern häufig an folgenden Gründen:

• Mangel an klarer Eigentümerschaft‍

Wenn ein Aktionspunkt „allen“ gehört, gehört er am Ende niemandem. Teams, die keinen bestimmten Besitzer zuweisen, sehen den Gegenstand mit geringerer Wahrscheinlichkeit durch. Rechenschaftspflicht ist ein entscheidender Faktor, um sicherzustellen, dass die Bearbeitung abgeschlossen wird, und das wird oft übersehen, insbesondere bei teamweiten Rückblicken.

• Keine Fristen:

Aktionselemente ohne Timebox treten in den Hintergrund. Teams verzögern oder priorisieren häufig Aufgaben, die nicht mit bestimmten Sprint-Meilensteinen oder Überprüfungspunkten verknüpft sind. Zeitlich begrenzte Ziele machen Folgemaßnahmen greifbar und messbar.

• Vage Ergebnisse:

Teams tappen oft in die Falle, rückblickende Elemente als Absichten und nicht als Aktionen zu schreiben. Allgemeine Formulierungen wie „Verbessern Sie die Kommunikation“ oder „Korrigieren Sie unseren Prozess“ sind nicht spezifisch. Ohne ein klares „Was“ und „Wie“ bewegt sich nichts.

• Zu viele Aktionen:

Wenn jede Idee aus dem Retro-Stil zu einem Action-Objekt wird, verschwindet der Fokus. Priorisierung ist von entscheidender Bedeutung. Die Teams müssen eine oder zwei wichtige Verbesserungen auswählen, die für den bevorstehenden Sprint realistisch sind. Andernfalls fühlt sich alles gleich wichtig an — und es wird nichts unternommen.

• Schlechte Sicht:

Aktionspunkte sind oft verstreut — sie leben in Whiteboards, statischen Dokumenten oder im Gedächtnis einer Person. Wenn Teams nicht sehen können, wofür sie sich verpflichtet haben, werden sie nicht danach handeln. Die Integration von Folgeaufgaben in die täglichen Tools des Teams (wie Easy Agile TeamRhythm in Jira) macht Rechenschaftspflicht unumgänglich.

All diese Faktoren führen zu demselben Endergebnis: eine große Kluft zwischen guten Absichten und echten Fortschritten. Unseren eigenen Nutzungsdaten von Easy Agile TeamRhythm zufolge absolvierten die Teams nur 40— 50% ihrer Aufgaben im Nachhinein. Nach der Veröffentlichung von Funktionen zur Aufdecken und Nachverfolgen unvollständiger Aktionen stieg diese Abschlussrate auf 65%. Bessere Folgemaßnahmen, nicht nur bessere Konversationen, sind erforderlich, um echte Fortschritte zu erzielen.

Ein 5-stufiges System für Retros, die zum Fortschritt führen

Hier ist der Rhythmus, den wir in belastbaren, leistungsstarken Teams gesehen haben:

1. Bereite dich zielgerichtet vor
   • Schaue dir Action-Gegenstände aus dem letzten Retro noch einmal an — nicht nur, um sie abzuhaken, sondern um zu verstehen, was sich seit ihrer Veröffentlichung geändert hat.
   • Was ist vorangekommen? Was nicht? Warum?
   • Räumt raus, was abgestanden ist. Markieren Sie, was noch relevant ist. Identifizieren Sie Muster, die eine eingehendere Diskussion verdienen.
2. Konzentrieren Sie sich auf den Dialog
   • Gehen Sie über die Symptome hinaus. Untersuchen Sie die Grundursachen.
   • Verwenden Sie Tools wie „5 Warums“, um Ihr Denken zu schärfen.
   • Verankern Sie die Diskussion auf: Was ist dringend und es wert, gelöst zu werden jetzt?
3. Priorisieren Sie mit Absicht
   • Versuche nicht alles zu reparieren. Verwenden Sie zum Filtern eine Wirkungs-/Aufwandsmatrix.
   • Wählen Sie 1—2 Aktionspunkte aus, zu denen Sie sich verpflichten möchten.
   • Weisen Sie Besitzer zu. Definieren Sie Erfolg. Vereinbaren Sie Zeitpläne.
4. Verfolge, wo du arbeitest
   • Verwenden Sie einen retrospektiven Action-Tracker, der in Ihrem Arbeitsablauf enthalten ist.
   • In Easy Agile TeamRhythm können Sie unvollständige Elemente aufdecken, ihren Verlauf einsehen, nach Relevanz sortieren und ihren Kontext verstehen — und das alles, ohne die Tools wechseln zu müssen.
5. Schließe den Kreislauf — jedes Mal
   • Sieh dir zu Beginn jedes Retro-Spiels die vorherigen Aktionspunkte an.
   • Feiere, was getan wurde, auch wenn es klein ist.
   • Überdenken Sie, was Sie behalten, ändern oder löschen möchten.
6. Fortschritt messen
   Fangen Sie an, Ihren kontinuierlichen Verbesserungsfortschritt mit einfachen, umsetzbaren Kennzahlen zu verfolgen: Wenn Sie diese im Laufe der Zeit messen, erfahren Sie, ob Sie sich verbessern wie du verbesserst dich.
   
   • ‍Abschlussrate von Aktionselementen —% der Aktionsgegenstände, die vor dem nächsten Retro abgeschlossen wurden (Ziel: 80— 100%)‍
   • Rate wiederkehrender Probleme — Wie oft taucht dasselbe Thema in allen Retros wieder auf‍
   • Durchschnittsalter der geöffneten Aktionselemente — Wie lange Verbesserungsaufgaben ungelöst bleiben
   • ‍Retro-Teilnahmerate —% des Teams, das aktiv zu Retro-Eingaben oder Abstimmungen beiträgt

Hören Sie auf, dieselben Konversationen zu wiederholen

Eine Team-Retrospektive, die funktioniert, deckt nicht nur Probleme auf, sondern löst sie. Wenn Sie sich zur Gewohnheit machen, alles zu verfolgen, werden Rückblicke von einem passiven Meeting zu einem Hebel für echte Veränderungen.

Wenn sich Ihre Retros wie ein Déjà-vu anfühlen, liegt das Problem möglicherweise nicht darin, wie Sie sprechen. Es könnte das sein, was danach passiert.

🎁 Holen Sie sich das vollständige Framework

Wir haben all diese und weitere Lektionen zu einem praktischen, praxiserprobten Produkt zusammengefasst Vorlage für rückwirkende Maßnahmen. Im Inneren findest du:

• Ein schrittweises Arbeitsblatt
• Anleitung zur Zuweisung und Nachverfolgung von Scrum-Aktionselementen
• Beispiele für erreichbare rückwirkende Maßnahmen
• Integrierte Strategien, um einer Retrospektive einen Sinn zu verleihen

👉 Laden Sie die kostenlose Vorlage hier herunter.

Du sprichst bereits darüber, worauf es ankommt. Stellen wir sicher, dass Sie danach handeln.

‍

Bei Easy Agile suchen wir ständig nach neuen Wegen, um unsere Produkte zu verbessern. Eine der Möglichkeiten, Innovationen zu fördern, sind die Dash Days — eine fokussierte Phase, in der unser Team von den täglichen Aufgaben Abstand nimmt, um zu experimentieren, zu erforschen und neu zu erfinden, wie unsere Tools den Kunden besser dienen können.

Während unserer letzten Dash Days haben wir die Benutzeroberfläche von zwei unserer Flaggschiffprodukte neu betrachtet: Einfacher agiler Teamrhythmus und Einfache agile Programme. Ziel war es, die Interaktion und Auffindbarkeit zu verbessern, damit Benutzer den vollen Nutzen unserer Tools ohne unnötige Komplexität nutzen können.

Hier erhalten Sie einen Einblick in unseren Denkprozess, unsere Herausforderungen und die aufregenden Lösungen, die wir untersucht haben.

Die Herausforderung

Im Zuge der Weiterentwicklung der Programme Easy Agile TeamRhythym und Easy Agile haben wir leistungsstarke Funktionen eingeführt, die den Benutzern mehr Kontrolle und Flexibilität bieten. Mit dem Hinzufügen neuer Funktionen wurde die Benutzeroberfläche jedoch ausgefeilter. Für uns ist dies eine Chance — eine Gelegenheit, einen Schritt zurückzutreten, die Benutzererfahrung zu vereinfachen und den Benutzern zu helfen, mehr von dem zu nutzen, was unsere Produkte bieten.

Um diesem Problem zu begegnen, haben wir Mitarbeiter aus dem gesamten Unternehmen zusammengebracht, um zu überlegen, wie wir das Erlebnis mit beiden Produkten verbessern können. In diesen Sitzungen haben wir einige wichtige Möglichkeiten identifiziert:

• Auffindbarkeit: Wie erleichtern wir es Benutzern, die leistungsstarken Funktionen unserer Tools zu finden und zu verwenden?
• Sichtbarkeit: Was ist der beste Weg, um Benutzern die richtigen Informationen und Funktionen zur Verfügung zu stellen, wenn sie sie benötigen?
• Kohärenz: Wie schaffen wir ein einheitlicheres Erlebnis innerhalb und zwischen unseren Produkten, um die Navigation intuitiver zu gestalten?

Mit diesen Erkenntnissen ausgestattet, machten wir uns dann daran, Lösungen zu finden, die auf die individuellen Herausforderungen jedes Produkts zugeschnitten sind.

Ein persönlicheres Erlebnis mit Easy Agile Programs

Bei den Programmen haben wir uns auf drei konzentriert.“wie könnten wir“ Fragen, um unsere Herausforderungen in Chancen umzuwandeln:

1. Wie können wir den Fokus mehr auf die Aktionen legen, die Benutzer ausführen möchten?
2. Wie können wir die Navigation intuitiver und einfacher gestalten?
3. Wie können wir Benutzern helfen, wenn sie mehr Kontext darüber erhalten, wo sie sich in der App auf einem bestimmten Bildschirm befinden?

Von den vielen Lösungen, die wir untersucht haben, war diejenige, die uns am meisten begeistert hat, die Idee einer Startbildschirm von Easy Agile Programs—ein personalisiertes Dashboard, das die Benutzer je nachdem, wo sie sich in ihrem Planungszyklus befinden, als Leitfaden dient.

Dieser Startbildschirm könnte sich an die Position anpassen, an der sich die Benutzer auf ihrer Reise befinden, und relevante Anleitungen und Aktionen anbieten.

• Für neue Nutzer, der Startbildschirm könnte klare Onboarding-Schritte und einen einfachen Zugriff auf die Hilfe bieten, sodass sie schnell und sicher loslegen können.
• Für erfahrene Anwender, es könnte Einblicke und wichtige Maßnahmen im Zusammenhang mit ihren Fortschritten bieten, sodass sie sich auf das konzentrieren können, was am wichtigsten ist. Benutzer sehen möglicherweise sogar Daten, die ihre Erfolge zusammenfassen, was es einfacher macht, Erfolge mit ihren Teams zu teilen.

Ganz gleich, ob jemand mit dem Produkt noch nicht vertraut ist oder gerade mit der Umsetzung begonnen hat, der Startbildschirm könnte eine großartige Möglichkeit sein, unsere Benutzer anzuleiten und zu coachen und ihnen dabei zu helfen, Fragen wie „Was soll ich als Nächstes tun?“ zu beantworten. oder „Welchen Mehrwert verpasse ich?“.

Eine fokussiertere Oberfläche für Easy Agile TeamRhythm

Für TeamRhythym lauteten unsere drei wichtigsten „Wie könnten wir“ -Fragen:

• Wie können wir bei der Sprint-Planung mehr Fokus auf die User Story Map legen?
• Wie können wir die Auffindbarkeit von Problemen ohne Epen verbessern?
• Wie können wir das Layout verbessern, um wichtige Funktionen hervorzuheben und die allgemeine Benutzerfreundlichkeit zu verbessern?

Vor dem Hintergrund dieser Fragen haben wir eine Reihe von Ideen untersucht, um die Sprint-Planung zu vereinfachen und es Benutzern zu erleichtern, ihre Arbeit vorzubereiten, zu planen und zu überprüfen, unabhängig davon, ob sie Scrum oder Kanban verwenden.

Die Sprint-Planung kann sich manchmal überwältigend anfühlen, wenn mehrere Sprints um Aufmerksamkeit konkurrieren. Um den Benutzern zu helfen, sich zu konzentrieren, haben wir die Idee untersucht, eine einzuführen fokussierter Blick bei der Sprint-Planung.

• Dies würde es Benutzern ermöglichen, einen bestimmten Sprint und nur den Backlog zu vergrößern, während andere ausgeblendet werden.
• Jedes Problem hätte seine eigene Zeile in der Detailansicht, und Benutzer können entweder eine ganze Zeile ziehen und ablegen oder einzelne Probleme ziehen, um sie schnell nach Prioritäten zu ordnen.
• In der Sprint-Ansicht werden auch Epics ausgeblendet, die im aktuellen Sprint keine verknüpften Probleme haben, sodass die Benutzer einen klareren Überblick darüber haben, was für ihre aktuelle Arbeit relevant ist.

Wir haben auch nach Möglichkeiten gesucht Verbessern Sie die User Story Map-Oberfläche um die nützlichsten Tools und Funktionen in den Vordergrund zu stellen. Indem wir die Darstellung wichtiger Funktionen verbessern, helfen wir Teams dabei, schnell auf das zuzugreifen, was sie benötigen, wann sie es benötigen, sodass sie ohne Unterbrechung produktiv bleiben können.

Auf diese Weise können wir Teams, die TeamRhythm verwenden, ein reibungsloseres, fokussierteres Erlebnis bieten, sodass sie sich auf das konzentrieren können, was vor ihnen liegt, ohne von allem anderen abgelenkt zu werden.

Du bist dran. Was denkst du?

Bei Easy Agile denken wir immer darüber nach, was als Nächstes kommt.

Diese Ideen stehen noch nicht auf unserer offiziellen Roadmap, aber sie sind die Art von Innovationen, auf die wir uns freuen.

Wenn Sie der Meinung sind, dass diese Änderungen Ihre Erfahrung mit Easy Agile TeamRhythm und Easy Agile Programs verbessern würden, lassen Sie es uns wissen! Ihr Feedback hilft uns bei der Entscheidung, welche Prioritäten gesetzt werden sollen, damit wir weiterhin Tools entwickeln können, die für Ihre Teams wirklich einen Unterschied machen.

‍

Das siebte Prinzip des Manifests für agile Softwareentwicklung lautet:
Funktionierende Software ist das wichtigste Maß für den Fortschritt.
Keine Storypoints, keine Geschwindigkeit, keine Schätzungen: funktionierende Software.

Jason Godesky, Bessere Programmierung

Schätzungen sind eine häufige Herausforderung für agile Softwareentwicklungsteams. Die erwartete Größe und Komplexität einer Aufgabe ist alles andere als objektiv; was für eine Person einfach ist, ist es für eine andere möglicherweise nicht. Story Points sind zur wichtigsten Kennzahl geworden, um den Aufwand abzuschätzen, der mit der Erledigung einer Aufgabe verbunden ist, und werden häufig zur Leistungsmessung verwendet. Aber hat das einen echten Wert und welche Risiken bestehen, wenn man sich zu sehr auf die Geschwindigkeit als Richtwert verlässt?

Agile Schätzung

Als Menschen sind wir im Allgemeinen schlecht darin, große Dinge in Einheiten wie Zeit, Entfernung oder in diesem Fall Komplexität genau zu messen. Wir sind jedoch hervorragend darin, relative Vergleiche anzustellen — wir können feststellen, ob etwas größer, kleiner oder genauso groß ist wie etwas anderes. Hier kommen Story Points ins Spiel. Story Points sind eine Möglichkeit, den relativen Aufwand für eine Aufgabe abzuschätzen. Sie sind nicht objektiv und können je nach Erfahrung des Teams und gemeinsamen Referenzpunkten schwanken. Je länger ein Team jedoch zusammenarbeitet, desto effektiver werden sie in Bezug auf die relative Größe.

Die Teams, die ich coache, hatten alle Probleme mit der Schätzung von Nutzergeschichten. Die historischen Daten zeigen uns, dass, sobald eine Story 5 Storypoints überschreitet, die Variabilität bei der Bereitstellung zunimmt. In der Regel gilt: Je mehr die Schätzung 5 Punkte überschreitet, desto stärker weicht die Darstellung von der Schätzung ab.

Robin D Bailey, Agiler Coach, GoSourcing

Referenzskala

Story Points sind zwar als Abstraktion für Planung und Schätzung nützlich, sollten aber nicht überanalysiert werden. In einem neu gebildeten Team werden die Storypoints wahrscheinlich stark schwanken, aber in einem Team, das schon viele Releases zusammen fertiggestellt hat, kann man mehr Vertrauen in die Zuverlässigkeit von Schätzungen haben. Zwei verschiedene Teams werden jedoch unterschiedliche Referenzskalen haben.

Auf Unternehmensebene bestand der wichtigste Wert, nach dem ich bei Story Points gesucht habe, darin, alle systemischen Probleme zu verstehen. Damals zum Beispiel, als Atlassian vierteljährlich auf Server veröffentlichte, gingen die Sprints vor einer Veröffentlichung schnell über die Bühne und verfehlten den üblichen Grad der Fertigstellung von Storypoints. Es stellte sich heraus, dass die Hauptursache ein massiver Anstieg kritischer Fehler war, die durch hochwertige Blitztests aufgedeckt wurden. Indem wir früher und regelmäßiger bessere Tests durchgeführt haben, haben wir die Last verteilt und auch dazu beigetragen, das Risiko der Veröffentlichungen zu verringern. Rückblickend klingt das einfach, aber es waren neue Erkenntnisse für unsere Teams zu der Zeit, die aufgedeckt werden mussten.

Mat Lawrence, COO, Easy Agile

Selbst bei gut etablierten Teams kann die Geschwindigkeit durch Faktoren wie erhöhte Komplexität bei gemeinsam geplanten Abhängigkeiten oder auch nur durch die durchschnittliche Anzahl von Story Points pro Ticket beeinflusst werden. Wenn ein Team viele Tickets mit geringer Komplexität geplant hat, reicht sein Prozess möglicherweise nicht für den erforderlichen Durchsatz aus. Wenn andere Teammitglieder weniger Tickets mit hoher Komplexität haben, könnte dies den Aufwand, den andere Teammitglieder zur Überprüfung der Arbeit benötigen, drastisch erhöhen. Beide Situationen könnten sich auf die Geschwindigkeit auswirken, aber beide stellen Engpässe dar.

Jede gemessene Änderung der Geschwindigkeit könnte auf eine Reihe anderer Faktoren zurückzuführen sein, z. B. auf Kapazitätsverschiebungen aufgrund von Änderungen der Mitarbeiterzahl, bei denen Teammitglieder aufgrund von Krankheit oder geplantem Urlaub abwesend sind. Die Realität ist, dass die Umgebung selten steril und kontrolliert ist.

Relative Geschwindigkeit

Viele Unternehmen fühlen sich vielleicht versucht, über Storypoints zu berichten, und Velocity-Berichte sind in Jira leicht verfügbar. Dennoch sollten sie mit Vorsicht betrachtet werden, wenn sie in einem „Team von Teams“ verwendet werden, z. B. in einem Agile Release Train. Aufgrund der unterschiedlichen Referenzskalen in den einzelnen Teams können Storypoints bedeutungslos werden. Was ein Team als 8-Punkte-Aufgabe ansieht, kann für ein anderes eine 3-Punkte-Aufgabe sein.

Für viele Manager bedeutet das Vorhandensein einer Schätzung, dass es einen „tatsächlichen“ Wert gibt. Dies bedeutet, dass Sie Schätzungen mit Istwerten vergleichen und sicherstellen sollten, dass Schätzungen und Istwerte übereinstimmen. Wenn sie das nicht tun, bedeutet das, dass die Mitarbeiter lernen sollten, besser abzuschätzen.

Wenn also das Vorhandensein einer Schätzung dazu führt, dass das Management den Blick von der Wertschöpfung abwendet und sich stattdessen auf die Verbesserung der Schätzungen konzentriert, lenkt es die Aufmerksamkeit vom zentralen Zweck ab, nämlich schnell einen echten Wert zu liefern.

‍Ron Jefferies
Mitautor des Manifests für agile Softwareentwicklung
Story Points überarbeitet

Ich suche Wert

Story Points sind jedoch immer noch ein wertvolles Werkzeug, wenn sie richtig eingesetzt werden. Storypoints dem Team, das sie verwendet, zu melden und Einblicke in ihre einzigartigen Trends zu geben, könnte ihnen helfen, mehr Selbstbewusstsein zu gewinnen und häufige Fallstricke zu vermeiden. Teams, die ihre Arbeitsweise verbessern möchten, möchten möglicherweise ihre Geschwindigkeit im Laufe der Zeit überwachen, während sie neue Strategien umsetzen.

Sicherlich werden Teams, die über einen längeren Zeitraum zusammenarbeiten, zu einem gemeinsamen Verständnis davon gelangen, wie sich eine 3-Story-Point-Aufgabe für sie anfühlt. Und die Diskussion und Erkundung, die erforderlich sind, um zu einem Punkt des gemeinsamen Verständnisses zu gelangen, sind wertvoll. Das Argument für 8 Storypoints im Gegensatz zu 3 kann eine Komplexität aufdecken, die bisher nicht berücksichtigt wurde, oder es kann eine neue Perspektive aufzeigen, die dazu beiträgt, die Arbeit effektiver aufzuschlüsseln. Es könnte sich auch die Frage stellen, ob es sich lohnt, die Arbeit überhaupt fortzusetzen, und deutlich machen, dass ein neuer Ansatz erforderlich ist.

Der Wert von Story Points für mich (als Entwickler und Gründer) sind die Gespräche, in denen das Thema von Menschen mit unterschiedlichen Perspektiven diskutiert wird. Velocity ist nur in langfristigen Teams mit hoher Mitarbeiterbindung relativ genau.

Dave Elkan, Co-CEO von Easy Agile

Auf Unternehmensebene können Story Points verwendet werden, um systemische Probleme zu verstehen, indem Trends im Zeitverlauf beobachtet werden. Diese Berichterstattung bietet zwar keine objektive Messgröße, kann aber Einblicke in die Fortschritte innerhalb eines Agile Release Trains geben. Der Abschluss eines Story Points als Maßstab für die Leistung von Einzelpersonen oder Teams sollte jedoch mit großer Vorsicht betrachtet werden.

Story Points sind ein nützliches Schätzinstrument, um den relativen Aufwand zu vergleichen. Sie hängen jedoch von gemeinsamen Bezugspunkten ab, und verschiedene Teams haben unterschiedliche Skalen. Selbst etablierte Teams können im Laufe der Zeit Geschwindigkeitsänderungen feststellen. Aus diesem Grund können Geschwindigkeitsberichte zwar Aufschluss über den Fortschritt des Teams geben, es darf jedoch nicht vergessen werden, dass Story Points eher zur Einschätzung des Aufwands als zur Messung konzipiert wurden. Und am Ende des Tages ist es unser Geschäft, großartige Software zu erstellen, keine großartigen Schätzungen.

Sie möchten Ihr Team auf Verbesserungen konzentrieren? Easy Agile TeamRhythm hilft dir dabei, Erkenntnisse in die Tat umzusetzen — mit Team-Retrospektiven, die mit deinem Agile-Board in Jira verknüpft sind. So kannst du deine Arbeitsweise verbessern und dein nächstes Release besser machen als das letzte. Verwandeln Sie ein Aktionselement mit nur wenigen Klicks in ein Jira-Problem und planen Sie dann die Arbeit auf der User Story Map, um sicherzustellen, dass Ihre Ideen am Ende der Retrospektive nicht verloren gehen.

Vielen Dank an Satvik Sharma, John Folder, Matthew Lawrence, David Elkan, Henry Seymour, und Robin D. Bailey dafür, dass Sie ihr Fachwissen und ihre Erfahrung in diesen Artikel eingebracht haben.

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.

Das Sprintziel ist ein wichtiger Aspekt jedes Sprints und sollte während Ihres zweiwöchigen Prozesses im Mittelpunkt stehen. Das Ziel stellt sicher, dass sich das Team auf ein klares Ziel für den Sprint konzentriert, und wenn es gut gemacht wird, inspiriert das Team, während des gesamten Sprints auf Kurs zu bleiben.

Was macht also ein gutes Sprintziel aus und wie passt das Sprintziel in den Rahmen eines Sprints? In diesem Beitrag werden wir im Wettlauf (oder sollten wir sagen Sprint 😉) eine Zusammenfassung des Scrum-Prozesses durchgehen, gefolgt von einer Liste mit fünf kritischen Elementen eines effektiven Sprintziels. Du erfährst, wie du deine Sprintziele für einen erfolgreichen Sprint alle zwei Wochen am besten erstellst, verwaltest und umsetzt.

Ein Überblick über den Scrum-Prozess

Wir sind große Fans von Gedränge! Brauchen Sie eine kleine Auffrischung? So funktioniert der Scrum-Prozess und wo das Sprintziel in das Gesamtbild passt.

Scrum ist ein agiles Framework, das hauptsächlich von Softwareentwicklungsteams verwendet wird und den Teammitgliedern einen optimierten Arbeitsablauf bietet, um die Bedürfnisse von Stakeholdern und Kunden zu erfüllen. Der Scrum-Workflow umfasst vier Besprechungen (auch bekannt als Zeremonien), die alle einen bestimmten Zweck haben. Diese Struktur bedeutet, dass sich die Teammitglieder problemlos gegenseitig unterstützen können, indem sie Ergebnisse teilen, verfolgen und verbessern.

Das Scrum-Framework unterteilt die Arbeit in sich wiederholende zweiwöchige Sprints, in denen ein festgelegter Arbeitsaufwand — das Sprintziel — abgeschlossen wird. Jedes Scrum beginnt mit einem Sprint-Planungsmeeting, und während dieser Zeit definiert der Product Owner das Sprintziel. Sie entscheiden, welche Aufgaben aus dem Produkt-Backlog in das Sprint-Backlog übertragen werden, um im darauffolgenden zweiwöchigen Sprint abgeschlossen zu werden.

Die Artikel im Produktbacklog geben einen Überblick darüber, was vor der Fertigstellung oder Veröffentlichung eines Produkts zu tun ist. Die Elemente des Sprint-Backlogs sind das, was das Team (hoffentlich) im Laufe des Sprints erreichen wird.

Das Scrum Master fungiert als Scrum-Guide, der das Team durch die Besprechungen und Schritte des Scrum-Prozesses führt. Während des gesamten Sprints trifft sich das Scrum-Team zu einem tägliches Scrum um miteinander abzuchecken und berichten Sie, welche Arbeiten in den letzten 24 Stunden abgeschlossen wurden.

Am Ende des Sprints ein Sprint-Review und Sprint-Rückblick helfen Sie dem Team, Feedback von Stakeholdern einzuholen und ihre Prozesse zu verbessern, bevor der nächste Sprint beginnt. Der gesamte Prozess wiederholt sich bei der Sprint-Planung erneut und wiederholt sich so lange, bis das Produkt oder Projekt abgeschlossen ist.

Einfache Sprint-Planung:

Ziehe Elemente direkt aus deinem Backlog auf deine TeamRhythm User Story Map. Bearbeiten Sie Story-Zusammenfassungen und Story-Point-Schätzungen online. Zeige dein Sprintziel auf jeder Sprint-Swimlane an.

PROBIERE: TEAMRHYTHM SANDBOX DEMO

Was macht ein gutes Sprintziel aus?

Das Sprintziel sorgt dafür, dass sich das Team darauf konzentriert, was jeder für jeden Sprint zu erreichen versucht. Es ist eine Erweiterung der allgemeinen Produkt- oder Projektziele, aber das Sprintziel kann sich auf wichtige Komponenten konzentrieren, die das Team für diesen bestimmten Sprint in Angriff nehmen möchte.

Was macht ein gutes Sprintziel aus? Lass es uns herausfinden.

1. Das Ziel ist erreichbar

Das Ziel des Sprints muss innerhalb des für den Sprint vorgesehenen Zeitrahmens erreichbar sein. Im Allgemeinen ist das Team in einem Scrum-Framework an zwei Wochen gebunden.

Wenn neue Informationen gewonnen werden und andere Hindernisse auftreten, besteht immer die Möglichkeit, dass das Sprintziel nicht erreicht wird. Das sollte Sie jedoch nicht davon abhalten, erreichbare Ziele zu setzen. Wenn ein Team die Ziele des Sprints und des Projekts kontinuierlich nicht erreicht, sinken die Moral und der Enthusiasmus.

Es ist wichtig, dass die Sprintziele innerhalb der vorgegebenen Zeit des Sprints überschaubar sind. Sprintziele können zu groß werden, wenn ein Team versucht, zu viele verschiedene Komponenten gleichzeitig zu erledigen, oder wenn zu viel vom Produkt-Backlog in das Sprint-Backlog aufgenommen wird. Nehmen Sie stattdessen eine einigermaßen erreichbare Arbeitslast aus dem Produkt-Backlog heraus, um das Sprint-Backlog zu bilden. Andernfalls erhalten Sie am Ende eine entmutigende Gesamtliste und keine klare Richtung für jeden Sprint.

2. Das Team versteht die Definition von erledigt

Je klarer das Sprintziel, desto besser. Du musst die Ziele des Sprints klar definieren und klar definieren, was es bedeutet, getan zu werden. Woher weiß das Team, ob es die gewünschten Ergebnisse erzielt hat? Wie sieht „erledigt“ aus? Sind sich alle über diese Definition für jede gegebene Aufgabe und die Gesamtziele des Sprints einig?

Deine Ziele müssen messbar sein, um Unklarheiten, Subjektivität oder widersprüchliche Meinungen über den Erfolg des Sprints zu vermeiden.

Wenn ein Team aufeinander abgestimmt ist und jeder versteht, was erreicht werden muss, verbessert sich die Entscheidungsfindung und jeder Aspekt des Scrum-Teams kann harmonisch auf dieselben Ziele hinarbeiten.

3. Das Sprintziel ist für das Team von Bedeutung

Das Team muss nicht nur wissen, was das Team in jedem Sprint zu erreichen hofft, sondern auch die Gründe hinter dem Sprintziel verstehen.

Stellen Sie sicher, dass jeder versteht, warum er auf ein bestimmtes Sprintziel hinarbeitet. Welche Bedeutung hat das Sprintziel? Im Idealfall bezieht sich die Bedeutung des Sprintziels auf die Bedürfnisse der Stakeholder, die Kundenreise oder die Benutzererfahrung Ihres Produkts.

Visualisieren und priorisieren Sie die Arbeit, die Ihren Kunden den größten Mehrwert bietet

Einfacher agiler Teamrhythmus

VERSUCHE ES JETZT

4. Das Sprintziel entspricht den allgemeinen Produktzielen

Das Sprintziel kann sich auf einen bestimmten Aspekt der Produktentwicklung konzentrieren, sollte aber dennoch mit den allgemeinen Produktzielen in Verbindung stehen.

Stellen Sie bei der Erstellung von Sprintzielen sicher, dass die übergreifende Produktvision nicht verloren geht oder ignoriert wird. Jeder Sprint ist zwar spezifisch für seine eigenen Ziele, sollte aber darauf abzielen, Ihre Produktziele zu erreichen.

5. Das Sprintziel ist während des gesamten Sprints sichtbar

Das Sprintziel kann kein „Setz es und vergiss es“ -Aspekt deines Sprints sein. Es sollte für das Team die ganze Zeit sichtbar sein, und das Team muss das Ziel kontinuierlich überprüfen, um sicherzustellen, dass es auf dem richtigen Weg ist, es zu erreichen.

Das gemeinsame Ziel sollte im Mittelpunkt der täglichen Scrum-Meetings stehen. Wenn möglich, zeigen Sie das Sprintziel für alle sichtbar an. Beziehen Sie sich beim Erledigen der Backlog-Elemente und beim Durcharbeiten des Sprints kontinuierlich auf das Sprintziel und die Fortschritte, die Sie auf dem Weg dorthin machen. Wie wahrscheinlich ist es, dass Sie das Sprintziel erreichen, wenn Sie die verbleibende Zeit des Sprints berücksichtigen? Was könnte der Erreichung dieses Ziels im Weg stehen?

Während der Sprint-Retrospektive solltest du den Erfolg oder Misserfolg besprechen, den das Team beim Sprintziel erzielt hat. Was lief gut und hat zu deinem Erfolg beigetragen? Was lief nicht so gut, dass du es für den nächsten Sprint ändern oder anders machen könntest?

Mit Easy Agile TeamRhythm verfügt jedes Scrum Board in Jira über eine zugehörige User Story Map.

Während des gesamten Sprints kann das Team auf die User Story Map zurückgreifen, um sicherzustellen, dass der Zeitplan eingehalten wird, Abhängigkeiten koordiniert und das Gesamtbild im Blick behält.

MACHEN SIE EINE PRODUKTTOUR

Ein kundenorientierter Ansatz

Lassen Sie uns einige der wichtigsten Faktoren zusammenfassen, die Sie bei der Festlegung und Umsetzung Ihres Sprintziels berücksichtigen sollten:

✅ Stellen Sie sicher, dass das Ziel erreichbar ist.

✅ Stellen Sie sicher, dass das Team die Definition von erledigt versteht.

✅ Stellen Sie sicher, dass das Sprintziel für das Team von Bedeutung ist.

✅ Stellen Sie sicher, dass das Sprintziel mit den allgemeinen Produktzielen übereinstimmt.

✅ Stellen Sie sicher, dass das Sprintziel während des gesamten Sprints sichtbar ist.

Vielen Dank, dass Sie bei uns bleiben und den Easy Agile-Blog nutzen. Wir sind begeistert davon, Teams dabei zu helfen, mit Agile besser zu arbeiten. Wir haben eine Suite von Jira-Apps entwickelt, um den Kunden bei jedem Schritt des Entwicklungsprozesses im Auge zu behalten.

Suchen Sie nach einem Tool zur Optimierung Ihrer Sprint-Planungssitzungen? Auschecken Einfacher agiler Teamrhythmus, was den flachen Produktbestand in ein aussagekräftiges Bild der Arbeit verwandelt.

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.

Es ist Zeit, Dinge zu erledigen und das Projekt den Programmierern zu übergeben. Aber bevor sie sich die Hände schmutzig machen, muss jemand planen der Scrum-Sprint oder die Scrum-Iteration. Das Sprint Planning-Meeting ist eine der Scrum-Zeremonien, und es ist die Eröffnungsveranstaltung des Sprints. 🎬

Lassen Sie sich von uns durch die Veranstaltung führen und erklären, wie Sie eine Veranstaltung erfolgreich vorbereiten und durchführen können. Außerdem erfährst du, wer an der Sprint-Planung teilnimmt und warum das Meeting so wichtig ist.

Was ist ein Sprint Planning-Meeting?

Sprint Planning ist ein Scrum-Meeting. Es leitet einen Sprint ein, findet also am ersten Tag eines neuen Sprints statt. Falls zutreffend, sollte es danach erfolgen der Sprint Review und die Sprint-Retrospektive aus der vorherigen Iteration.

Die Sprintplanung zielt darauf ab, die Ergebnisse für den bevorstehenden Sprint festzulegen und einen Plan für die Entwicklung der Arbeit zu definieren.

Das gesamte Scrum Team (der Product Owner, der Scrum Master, und das Entwicklungsteam) arbeitet bei der Sprint-Planung zusammen.

Können Sie sich ein erfolgreiches Projekt ohne Planung vorstellen? 🙅 Das können wir auch nicht, also starten wir keinen Scrum-Sprint, ohne ihn zu planen.

Um einen Scrum-Sprint zu planen, müssen Sie sich entscheiden:

• Die Dauer des Sprints — denk daran, dass ein Sprint eine Timebox ist
• Das Sprintziel, was ihr Zweck ist und darstellt die Produktzunahmeder Wert für den Kunden
• Die Arbeit, die das Entwicklungsteam während des Sprints erledigen kann, welche Arbeitsaufgaben das Team zuerst erledigen sollte, um das Sprintziel zu erreichen, und wie lange sie unter Berücksichtigung der Kapazität des Teams benötigen sollten

Darüber hinaus sollte die Sprint-Planung das Team motivieren und realistische Erwartungen setzen.

Am Ende des Sprint Planning-Meetings muss das Team die folgenden Ergebnisse erzielen:

• Ein gemeinsames Verständnis des Sprintziels. Dieses Ziel ist die Richtlinie für die Bewertung der Arbeit des Entwicklungsteams nach Abschluss des Sprints.
• Das Sprint Backlog. Dieses Artefakt steht für das Gespräch zwischen dem Entwicklungsteam und dem Product Owner über die zu erledigende Arbeit. Es ist das Ergebnis eines ausgewogenen Verhältnisses zwischen Kundennutzen und Entwicklungsaufwand.

Jetzt erfordert jedes Sprint Planning-Meeting einige Vorbereitungen. Lesen Sie weiter, wer es tun sollte und was es beinhaltet.

Wie bereitest du dich auf die Sprint-Planung vor?

Der Product Owner sollte die folgenden Schritte befolgen, um die Grundlage für eine erfolgreiche Sprint-Planung zu legen:

• Kombinieren Sie die Ergebnisse des vorherigen Sprint Reviews mit dem Feedback von Stakeholdern wie Management und Kunden und die Produktvision
• Aktualisieren und, falls erforderlich, verfeinern der Produkt-Backlog
• Kennen Sie den Kundennutzen, den das Entwicklungsteam schrittweise schaffen muss

Sobald alle Vorbereitungen abgeschlossen sind, ist es Zeit für das Sprint Planning-Meeting.

Wie sollte das Treffen ablaufen?

1. Der Product Owner gibt die Product Backlog-Elemente — und die entsprechenden Prioritäten — an, die sie als die besten Kandidaten für den nächsten Sprint betrachten. Artikel können sein Anwenderberichte, Aufgaben oder Bugs. Der Product Owner schlägt diese Artikel entsprechend dem Kundennutzen und der Produktvision vor.
2. Basierend auf Aufwandsschätzungen und dem Vorschlag des Product Owners das Entwicklungsteam wählt die Produkt-Backlog-Elemente aus, an denen während des aktuellen Sprints gearbeitet werden soll. Indem sie diese Elemente zu Sprint-Backlog-Elementen heraufstufen, einigen sich die Entwickler mit dem Product Owner auf das Sprint-Ziel.
3. Obwohl optional, könnte das Team die Abhängigkeiten zwischen den Elementen besprechen und darüber, wer an jedem einzelnen von ihnen arbeiten sollte.

Sehr wenige Schritte, oder? Einige praktische Maßnahmen sollten diese Schritte jedoch ergänzen. Im Folgenden erfahren Sie, um welche Maßnahmen es sich dabei handelt.

Wie führt man ein erfolgreiches Sprint-Planning-Meeting durch?

1. Begrenzen Sie die Dauer der Besprechung. ⏳ Die Sprint-Planung sollte nicht länger als 1-2 Stunden pro Sprintwoche dauern. Das bedeutet, dass das Meeting für einen zweiwöchigen Sprint nicht länger als 2-4 Stunden dauern sollte.

2. Lassen Sie den Scrum Master der Wächter der Zeit sein. Sie sind dafür verantwortlich, dass das Meeting innerhalb der definierten Zeitbox stattfindet.

3. Halten Sie das Meeting jedes Mal am selben Tag und zur gleichen Zeit ab. 📅 Teammitglieder können ziemlich beschäftigt sein und volle Agenden haben. Deshalb empfiehlt es sich, für jeden Teilnehmer einen Platz in der Agenda zu reservieren.

4. Definieren Sie wertvolle, klare Ergebnisse. 🎁 Diese, zusammen mit einem klaren Sprint-Backlog, erhöhen die Motivation des Entwicklungsteams. Die richtigen Ergebnisse zu erzielen ist pure Zufriedenheit, und ein klarer Arbeitsplan ist das Rezept, um dies zu erreichen.

5. Stellen Sie sicher, dass der Scrum Master diese Dinge garantiert. Erstens, dass das Gespräch zwischen dem Entwicklungsteam und dem Product Owner fruchtbar ist. Sie sollten sich alle auf das Sprintziel einigen. Zweitens, dass die Entwickler gute Entscheidungen treffen, wenn sie Artikel aus dem Produkt-Backlog in das Sprint-Backlog verschieben. Es ist eine gute Wahl, ein Element auszuwählen, das für die Dauer des Sprints, die Teamkapazität und die Arbeitslast machbar ist.

Es mag einfach erscheinen, aber das ist nicht alles, was Sie während der Sprint-Planung tun müssen. Es gibt eine Reihe von Dingen, die es zu vermeiden gilt.

Wenn wir dir einen Rat geben sollten...

Schätzen Sie den Aufwand anhand der Kapazität des Entwicklungsteams ab. Um zu entscheiden, wie viel Arbeit das Team in einem Sprint erledigen kann, sollten Sie die Kapazität des Teams berücksichtigen. (Und denken Sie daran, Schätzungen sind genau das — Schätzungen.) Entwickler berücksichtigen ihre bisherigen Erfahrungen, doch jeder Sprint ist einzigartig und kann sich im Laufe seines Verlaufs ändern. Die Berücksichtigung der Teamkapazität verbessert jedoch die Genauigkeit der Aufwandsschätzung. Darüber hinaus Storypoints könnte dem Team bei der Aufwandsschätzung helfen.

Bedenken Sie, dass sich die Fähigkeit des Entwicklungsteams zur Schätzung im Laufe der Zeit verbessern sollte. Daher sollte das Team weniger genaue Aufwandsschätzungen nach dem Sprint nicht kritisieren. Andernfalls wird das Team viel länger brauchen, um eine Schätzung vorzunehmen, oder beim nächsten Mal viel größere Schätzungen abzugeben.

Versuchen Sie nicht, während der Sprint-Planung alles zu planen. Lassen Sie die Idee, das vollständigste und perfekteste Sprint-Backlog aller Zeiten zu erstellen, vor der Tür. Schließlich dreht sich bei Scrum alles um Flexibilität und „Besser gemacht als perfekt“. Ein Sprint-Backlog, das vollständig genug ist, um Entwicklern den Einstieg zu erleichtern, ist also genau das, was es sein muss. Denken Sie daran, dass die Lösung komplexer Probleme einen Learn-by-Doing-Ansatz erfordert, der die Planung zu einer ebenso komplexen Aufgabe macht.

Ermitteln Sie eine realistische Erwartung für das Ergebnis des Sprints. Es ist keine gute Idee, unrealistische Erwartungen an den Zuwachs zu stellen, den das Entwicklungsteam im Laufe eines Sprints erzielen kann. Es könnte Entwickler frustrieren, dass sie nicht liefern konnten, was ihre Motivation und Leistung ernsthaft beeinträchtigen kann. Auf der anderen Seite sorgen realistische Erwartungen dafür, dass das Team Erfolg hat und ein Erfolgserlebnis hat. Außerdem erleichtern sie die Konversation zwischen den Entwicklern und dem Product Owner, sodass sie sich auf das Sprintziel einigen können.

Haben Sie einen gut verfeinerten Produkt-Backlog. Es muss detailliert genug sein, damit das Entwicklungsteam verstehen kann, worum es bei den Arbeitsaufgaben geht. Sie möchten keine wertvolle Zeit in der Sprint-Planung damit verschwenden, Arbeitselemente in maximal eines pro Tag aufzuteilen. Definieren und folgen Sie einem Verfeinerung des Backlogs verarbeiten und sicherstellen, dass Product Backlog-Artikel Ihren Anforderungen entsprechen Definition von bereit.

Schlage ein klares Sprintziel vor. 🎯 Der Product Owner muss sich über den erwarteten Kundennutzen für die Erhöhung im Klaren sein. Andernfalls wählt das Entwicklungsteam möglicherweise eine Reihe von Artikeln aus dem Produktbacklog aus, die keinen Bezug zueinander haben. Das Ergebnis könnten unerwartete Ergebnisse und ein geringes Erfolgserlebnis sein.

Klären Sie das Definition von erledigt mit dem Entwicklungsteam. Zu wissen, was geleistete Arbeit im aktuellen Sprint bedeutet, hilft den Entwicklern, die Erwartungen zu erfüllen. Das liegt daran, dass sie besser verstehen, was zu tun ist, um das Inkrement zu erzielen. Außerdem gibt eine klare Definition von „Fertig“ dem Entwicklungsteam mehr Selbstvertrauen bei der Einschätzung des Aufwands.

Starke Sprint-Planung macht Ihr Projekt stärker

Wenn du folgst das Scrum-Framework, Sprint Planning ist keine Wahl. Wenn Sie jedoch jemals versucht sind, ihn zu überspringen, setzen Sie ein Lesezeichen für diesen Artikel und lesen Sie das Folgende. 📑

Mit einem erfolgreichen Sprint-Planning-Meeting ist es einfacher, das Sprintziel, die zu erledigenden Aufgaben und die Sprintergebnisse zu verstehen. Wenn das Team nicht weiß, wohin es geht und wie es dorthin gelangen kann, wird es wirklich schwierig, die Kundenbedürfnisse zu erfüllen. Es ist genauso schwierig, Ihren Kunden wertvolle Zuwächse zu bieten, wenn Sie die Arbeit nicht nach Prioritäten organisieren.

Bei der Sprint-Planung geht es darum, Klarheit zu schaffen und die Arbeit zu organisieren, bevor es in der Iteration zu spät ist. Es geht auch darum, das gesamte Team in die Vorbereitung auf alle Anstrengungen einzubeziehen, die ein Sprint erfordert. Ein Hinweis: Denken Sie daran, dass ein Sprint-Plan in die Zeitbox eines Sprints passen muss, und berücksichtigen Sie die Teamkapazität.

Einfacher agiler Teamrhythmus ist perfekt für die Sprint-Planung. Es ist ein schnelles, unkompliziertes, visuelles und kollaboratives Tool, das Ihnen Folgendes ermöglicht:

• Ziehe Artikel direkt aus dem Produkt-Backlog auf die User Story Map
• Aufwandsschätzungen in User Stories registrieren
• Story-Point-Schätzungen bearbeiten
• Priorisieren Sie die User Stories in jedem Sprint, indem Sie sie innerhalb der jeweiligen Sprint-Swimlane anordnen
• Analysieren Sie die Sprint-Statistiken, um sicherzustellen, dass die geplante Arbeit die Kapazität des Teams nicht überschreitet und das Sprintziel realistisch ist
• Visualisieren Sie, was das Team wann liefern wird, indem Sie User Stories in Sprint-Swimlanes zusammenfassen

Lassen Sie uns wissen, wenn Sie Fragen haben zu Einfacher agiler Teamrhythmus. Wir empfehlen es für Ihr Scrum-Projekt sehr, und unsere Kunden empfehlen dasselbe.

„Tu es oder tu es nicht; es gibt keinen Versuch.“ Dies ist sicherlich das berühmteste Zitat von Jedi-Meister Yoda, aber es trifft nicht gerade auf die agile Entwicklung zu. Tatsächlich ist es quasi das Gegenteil von agil. Wenn Yoda ein Scrum Master wäre, würde das Zitat jedoch viel eher so aussehen: „Versuche es und versuche es noch einmal; so machst du es.“

Der Scrum Master unterstützt das Scrum-Team und führt es zu einem hoffnungsvollen Sieg. Es ist lohnend, aber die Rolle des Scrum Masters ist voller Druck. Der Erfolg des Scrum und das Wohlbefinden des Teams liegen auf den Schultern des Scrum Masters.

Wenn Sie ein Scrum Master sind oder einer werden möchten, sind Sie bei uns genau richtig. Meistern Sie die Scrum-Theorie und Ihre Führungsqualitäten mit unseren sechs Strategien für Scrum Master.

Scrum-Werte und die Rolle des Scrum Masters verstehen

Scrum ist eine agile Praxis, die häufig für die Produktentwicklung verwendet wird. Es basiert darauf, eine bestimmte Menge an Arbeit in kurzen Phasen — sogenannten Sprints — zu erledigen, sodass Teams kontinuierlich Iterationen erstellen können, während sie mehr über ein Produkt und seine Stakeholder erfahren.

Kenneth Schwaber hat in den frühen 1990er Jahren das Scrum-Framework mitentwickelt, um Teams bei der Verwaltung komplexer Entwicklungsprojekte zu unterstützen. Er gründete auch die Scrum Alliance und gründete Scrum.org, eine Online-Ressource für agile Teams.

Zu Beginn eines Scrums entscheidet der Product Owner, welche Product Backlog-Artikel in den Sprint-Backlog. Von dort aus übernimmt der Scrum Master und führt das Team durch Scrum-Events, darunter:

• Sprint-Planung
• Tägliches Scrum oder tägliche Standups
• Sprint-Bewertung
• Sprint-Retrospektiven

Die Rolle des Scrum Masters besteht darin, das Team durch den Scrum-Prozess zu führen. Sie erleichtern den Prozess und helfen dem Team, das Framework zu beherrschen und sich von einem Sprint zum nächsten zu verbessern.

Eigenschaften, die einen großartigen Scrum Master ausmachen

Ein effektiver Scrum Master zu sein, geht über das einfache Befolgen der Scrum-Regeln hinaus. Hier sind einige zusätzliche Merkmale, die Exzellenz in dieser Rolle wirklich definieren:

1. Emotionale Intelligenz

Ein guter Scrum Master besitzt eine hohe emotionale Intelligenz. Das bedeutet, dass sie:

• Verstehe und verwalte ihre eigenen Emotionen.
• Fühlen Sie sich in die Gefühle und Perspektiven der Teammitglieder ein.
• Ermöglichen Sie eine konstruktive Kommunikation und lösen Sie Konflikte elegant.

2. Starke Fähigkeiten zur Moderation

Es geht nicht nur darum, die täglichen Scrum-Meetings zu verwalten. Sie müssen:

• Ermutigen Sie zu einem offenen Dialog.
• Stellen Sie sicher, dass jede Stimme gehört wird.
• Führe das Team zum Konsens, ohne überheblich zu sein.

3. Anpassungsfähigkeit

Die Landschaft eines Projekts kann sich schnell ändern. Großartige Scrum Master:

• Passen Sie sich schnell an Veränderungen an, ohne den Fokus zu verlieren.
• Helfen Sie dem Team, Strategien schnell zu entwickeln und gleichzeitig die Moral aufrechtzuerhalten.

4. Lebenslanger Lerner

Die Welt von Agile entwickelt sich ständig weiter. Außergewöhnliche Scrum Master:

• Verpflichten Sie sich zu kontinuierlichem Lernen.
• Bleiben Sie mit den neuesten Praktiken, Tools und Methoden auf dem Laufenden.

5. Dienende Führung

Im Mittelpunkt der Rolle eines Scrum Masters steht die servative Führung. Das beinhaltet:

• Stellen Sie die Bedürfnisse des Teams über ihre eigenen.
• Beseitigung von Hindernissen, die den Fortschritt des Teams behindern.
• Befähigung der Teammitglieder, Verantwortung zu übernehmen und Entscheidungen zu treffen.

6. Analytisches Denken

Ein guter Scrum Master sollte in der Lage sein:

• Analysieren Sie die Prozesse des Teams und identifizieren Sie Engpässe.
• Nutzen Sie datengestützte Erkenntnisse, um kontinuierliche Verbesserungen zu fördern.

7. Motivierende Fähigkeiten

Die Motivation des Teams zu erhalten, ist entscheidend für eine nachhaltige Produktivität. Sie zeichnen sich aus durch:

• Kleine Erfolge anerkennen und feiern.
• Förderung einer positiven, kollaborativen Teamkultur.

8. Exzellente Kommunikation

Kommunikation ist der Schlüssel. Sie müssen:

• Vermitteln Sie Ideen klar und präzise.
• Stellen Sie sicher, dass alle Beteiligten auf derselben Wellenlänge sind.

Indem ein Scrum Master diese Eigenschaften verkörpert, ermöglicht er nicht nur ein effektives Projektmanagement, sondern fördert auch ein florierendes Teamumfeld, das Innovation und Erfolg fördert.

Sechs Strategien, um ein großartiger Scrum Master zu werden

Hier sind sechs Strategien für Scrum Master, um ihre Fähigkeiten zu verbessern oder sich auf ihre zukünftigen Rollen vorzubereiten.

1. Vergiss nicht, selbst agil zu sein

Lebst du selbst nach agilen Prinzipien? Wie agil sind Sie in Ihrem Führungsstil?

Effektive Scrum Master wissen, dass sie sich auch aufgrund neuer Erfahrungen, Erfolge und Misserfolge kontinuierlich verbessern müssen. Es ist wichtig, aus Ihren Fehlern zu lernen, damit Sie sie nicht noch einmal machen, aber es ist genauso wichtig, aus Ihren Erfolgen zu lernen. Nehmen Sie sich die Zeit, Ihren Prozess zu überprüfen, einschließlich dessen, was gut gelaufen ist und was nicht, damit Sie wissen, wie Sie sich als Führungskraft und Moderator verbessern können.

2. Lerne dein Team kennen

Ihre Fähigkeit, Ihr Team zu führen, hängt davon ab, wie gut Sie es kennen. Sie sollten kontinuierlich die Stärken und Schwächen Ihres Teams kennenlernen. Wie gut arbeiten sie zusammen? Wer bringt das Beste aus einander heraus und wer arbeitet nicht so gut zusammen? Gehen Sie tief in die Tiefe, um die grundlegende Dynamik des Teams wirklich zu verstehen.

Erfahre auch mehr über jeden Einzelnen im Team. Wobei benötigen sie Hilfe? Worin zeichnen sie sich aus? Welches Feedback können Sie ihnen geben, um ihnen zu helfen, in ihrer Rolle weiterzuentwickeln? Wie können Sie ihnen zum Erfolg verhelfen? Bauen Sie eine Beziehung zu Ihren Teammitgliedern auf, indem Sie sie fragen, wie es ihnen geht, Feedback geben und entgegennehmen und Gemeinsamkeiten finden.

3. Fördern Sie eine Kultur des kontinuierlichen Feedbacks

Die agile Methodik basiert auf kontinuierlicher Verbesserung. Wie werden sich die Personen in Ihrem Team verbessern, wenn Sie ihnen kein Feedback geben? Und wie wirst du dich verbessern, wenn du das Team nicht um Feedback bittest und es nicht akzeptierst?

Feedback ist eine Einbahnstraße, und es funktioniert nur, wenn es konstruktiv und kontinuierlich ist. Warten Sie nicht, bis Sie etwas Negatives zu beheben haben — Sie müssen regelmäßig sowohl positives als auch negatives Feedback geben. Wenn Sie dies regelmäßig tun, können Sie und Ihr Team sich daran gewöhnen, Feedback zu hören, sodass es nicht erschütternd oder abschreckend wirkt, wenn Sie dies tun.

Als Scrum Master sollten Sie ein Umfeld fördern, in dem alle Mitglieder geben und empfangen konstruktives Feedback.

4. Verbessern Sie Ihre Kommunikationsfähigkeiten

Das Sagen zu haben bedeutet nicht, dass du ständig redest. Das Gegenteil ist der Fall: Gute Führungskräfte sind großartige Kommunikatoren. Als Führungskraft müssen Sie Ihrem Team ständig zuhören und beide Ohren offen halten für alle Probleme, mit denen sich Ihr Team oder die Mitglieder des Teams möglicherweise befassen.

Hören Sie sich aktiv die Anliegen des Entwicklungsteams an und überlegen Sie, wie jeder Einzelne in Ihrem Team am liebsten kommuniziert. Bevorzugen sie mutige und auf den Punkt gebrachte Interaktionen? Oder brauchen sie Zeit, um ein Gespräch zu beginnen? Jeder kommuniziert ein bisschen anders, und wenn Sie die Präferenzen Ihres Teams verstehen, können Sie das Beste aus jeder Interaktion herausholen.

Scrum Master müssen ihre Kommunikationsfähigkeiten verbessern, um effektive Führungskräfte für ihre Teams zu sein. Beurteilen Sie regelmäßig Ihren Kommunikationsstil und dessen Effektivität und bitten Sie Ihr Team um Feedback dazu, wie es Ihnen geht.

5. Machen Sie das Beste aus jeder Retrospektive

Die Retrospektive ist die letzte Veranstaltung eines Scrums. Sie sind ein unglaublich wichtiger Teil des Scrum-Prozesses und sollten nicht übersehen, überstürzt oder zu wenig genutzt werden. Als Scrum Master müssen Sie die Verantwortung dafür übernehmen, dass Retrospektiven wirksam sind und nach jedem Scrum stattfinden. Gehen Sie mit einem Plan los, um das Beste aus jedem Retro-Meeting herauszuholen.

Das bedeutet nicht, dass Sie sich um alles kümmern müssen. Es ist hilfreich, Ihr Team gelegentlich eine Retrospektive durchführen zu lassen. Alle Beteiligten sollten kontinuierlich ihre eigenen Ideen einbringen, um das Meeting zu verbessern.

Sammeln Sie regelmäßig Feedback von Ihrem Team darüber, wie Ihre Retrospektiven ihrer Meinung nach verlaufen. Fragen Sie nach Ideen, wie sie sich verbessern und die Dinge ändern könnten. Die Wiederholung exakt derselben Fragen und rückblickende Aktivitäten langweilen Ihr Team und führen zu geringerem Engagement.

Einen tieferen Rückblick finden Sie in unseren fünf Schritten zu Durchführung effektiver Sprint-Retrospektiven.

6. Werden Sie zertifizierter Scrum Master

Eine Scrum Master-Zertifizierung kann Sie vom einfachen Scrum Master zum meisterhaften Scrum Master machen. Eine Zertifizierung ist zwar nicht erforderlich, um ein professioneller Scrum Master zu werden, aber sie hilft auf jeden Fall.

Scrum.org, die vom Mitbegründer von Scrum gegründete Website, bietet ein dreiteiliges Zertifizierungsprogramm namens The Professional Scrum MasterTM an. Das Programm besteht aus drei Bewertungsstufen, die Ihr Wissen über das Scrum-Framework und die praktische Anwendung der Scrum-Theorie bestätigen.

• Der professionelle Scrum MasterTM I (PSM I)
• Der professionelle Scrum MasterTM II (PSM II)
• Der professionelle Scrum MasterTM III (PSM III)

Wir sind auch große Fans der SAFe-Trainingsprogramme von Pretty Agile:

• SAFe Scrum Master SSM Zertifizierung
• SAFe Advanced Scrum Master

Eine Zertifizierung ist eine großartige Ergänzung zu Ihrem Lebenslauf und hilft Ihnen dabei, Ihre Moderationsfähigkeiten und Ihr Scrum-Wissen zu verfeinern.

Easy Agile für Scrum Master

„Versuche es und versuche es noch einmal; so machst du es.“

Das Schöne an Agilität ist, dass unabhängig davon, wie viele Zertifizierungen oder Jahre Erfahrung Sie haben, es immer mehr zu verbessern gibt. Agile ist ein iterativer Prozess, bei dem das Lernen von Sprint zu Sprint und von Projekt zu Projekt fortgesetzt wird. Als Scrum Master liegt es an Ihnen, das Handwerk weiter zu erlernen und Ihre Moderationsfähigkeiten zu perfektionieren. Die Rolle des Scrum Masters beinhaltet lebenslanges Lernen.

Easy Agile entwickelt Produkte, die Scrum Mastern und agilen Entwicklern helfen, effizienter und effektiver zu arbeiten. Unsere Tools wurden speziell für Teams entwickelt, die Jira verwenden und lieben, aber mehr Funktionen benötigen, um die Kundenbedürfnisse zu priorisieren.

Versuche Einfacher agiler Teamrhythmus um die Agilität Ihres Teams von der Planung bis zur Überprüfung zu unterstützen. TeamRhythm unterstützt das Mapping von User-Storys, die Verfeinerung des Backlogs, die Sprint- und Versionsplanung sowie Team-Retrospektiven und baut so einen kontinuierlichen Verbesserungszyklus direkt in Jira auf. Es ist eine Win-Win-Situation für Scrum Master, Entwicklungsteams und Kunden. Testen Sie unsere Produkte 30 Tage lang absolut kostenlos.

Seien wir ehrlich! Das Projektmanagement für agile Teams kann eine Menge schwieriger Aufgaben beinhalten, angefangen beim Umgang mit den Erwartungen der Produktverantwortlichen bis hin zu undefinierten Qualitätsstandards.

Klar, du hast gute und schlechte Tage. Aber warum setzen Sie Ihre Ziele nicht höher und streben den idealen Tag an?

Um Ihnen dabei zu helfen, verwendet Planning Poker, auch Scrum Poker genannt, Spielkarten, um agiles Schätzen und Planen zu vereinfachen. Das Ergebnis? Ihr agiler Schätzungs- und Planungsprozess läuft reibungsloser und Ihr Entwicklungsteam steigert seine Produktivität.

In diesem Artikel erfährst du, welche treibende Kraft hinter der Pokerplanung steckt, wie sie bei der Schätzung hilft, die Geschichte des Pokers zu planen und wie man dieses Spiel spielt.

Die treibende Kraft hinter der Pokerplanung

Der Zweck der Pokerplanung besteht darin, das gesamte Team in die Zusammenarbeit einzubeziehen. Scrum Poker macht es einfacher, wertvolle Zeit- und Aufwandsschätzungen vorzunehmen, damit Ihr Team zufriedenstellende Ergebnisse erzielen kann.

Anstatt dass die Teammitglieder ihre Schätzungen mündlich äußern, verwenden sie ein Kartenspiel, um für sie zu sprechen. Das Ziehen von Karten und das gleichzeitige Ablegen dieser Spielkarten verdeckt verhindert Vorurteile. Jeder folgt dieser Methode im Schätzprozess, was individuelle Schätzungen unterstützt und den Einfluss von Gleichaltrigen zunichte macht.

Andere Techniken zur Projektschätzung verwenden Zeit, um zu bestimmen, wie lange eine Aufgabe dauern wird. Bei der agilen Schätzung werden Story Points verwendet. Diese Story Points beziehen sich auf den Aufwand, mit dem eine Aufgabe bewältigt wird.

Bei der Pokerplanung weist das gesamte Team jeder Aufgabe Storypoints zu. Jeder Storypoint ist eine visuelle Darstellung des zu erledigenden Arbeitsaufwands und des Aufwands, der für die Erledigung jeder Aufgabe aufgewendet werden muss. Diese Methode setzt sich im Laufe der Zeit durch, da sie visuell ist und sich auf den Aufwand statt auf Zeitbeschränkungen konzentriert

Arbeitsschätzung in der agilen Entwicklung

Das Schätzverfahren ist für die Teammitglieder von entscheidender Bedeutung, da es bestimmt, wie viel Arbeit in jedem Sprint steckt. Die Aufteilung des Produkt-Backlogs in kleine Aufgaben hilft dabei, den Arbeitsaufwand einzuschätzen.

Als Scrum Master, du hast eine schwierige Rolle zu spielen. Am Ende des idealen Tages möchten Sie, dass die Benutzergeschichte des Product Owners vorbildlich ist. Gleichzeitig haben Sie als Scrum-Master ein Scrum-Team zu verwalten.

Agile Entwicklung ist ein kritischer Prozess, den Sie kontrollieren müssen. Wenn Sie die User Story und die Story-Points richtig verstehen, sind Sie auf halbem Weg. Meistern Sie den Schätzungsprozess und Sprint-Planung, und du kontrollierst den Produkt-Backlog und die Retrospektive.

Softwareentwicklungsteams können entweder physische Spielkarten oder Software für die Pokerplanung verwenden. Die Verwendung von Software, die ein Jira-Plugin enthält, ist von entscheidender Bedeutung, wenn Sie verteilte Teams haben. Wenn du ein Jira-Plugin hast, kann jeder am Schätzungsprozess teilnehmen und ihn optimieren.

Geschichte des Planungspokers

Softwareentwicklungsteams verwendeten früher eine andere teambasierte Schätztechnik, Wideband Delphi. Obwohl es mit der Pokerplanung vergleichbar war, dauerte es zu lange, bis mit dieser Technik ein Konsens erzielt wurde.

James Grenning stellte fest, dass Delphi nicht als strukturierter Schätzansatz funktionierte, und entwickelte die Idee, Poker zu spielen im Jahr 2002. Grenning stellte fest, dass ein physisches Kartenspiel ein ansprechender Ansatz für agile Teams war, Arbeitsschätzungen abzugeben. Er fand auch heraus, dass Scrum Poker besser funktionierte als Wideband Delphi.

Die Planung von Poker ist umfassender. Das Kartenspiel stellt sicher, dass das Scrum-Team an den Arbeitsschätzungen teilnimmt, und alle müssen so lange mitmachen, bis ein Konsens erreicht ist.

2002 entwickelte Mike Cohn eine Mountain Goat-Software und stellte ein Deck digitaler Karten zur Verfügung, die bei der Pokerplanung verwendet werden konnten. Scrum-Teams können diese digitalen Spielkarten von entfernten Standorten aus verwenden, um das agile Schätzen und Planen zu verbessern und dabei Spaß zu haben.

Lassen Sie uns die Vor- und Nachteile der Pokersitzung erkunden und erfahren, wie das Spiel gespielt wird.

Was Scrum-Teams für eine Pokersession benötigen

Agile Teams benötigen einige wichtige Elemente für ihre Planungssitzungen. Zu diesen Artikeln gehören:

• Ein Kartenspiel
• Schätzer (das agile Team)
• Ein Moderator
• Eine Funktionsliste
• Eine Eieruhr

Wähle deine Spielkarten

Beim Scrum Poker haben die Teammitglieder (Schätzer) jeweils ein Kartenspiel. Sie verwenden diese Spielkarten, um anzugeben, wie hoch oder niedrig sie schätzen, wie lange es dauern wird, bis die einzelnen Elemente auf der Liste der Funktionen abgeschlossen sind. Bei diesen Listenfunktionen kann es sich um die Benutzerstory, um Storypoints oder um ideale Zeitpunkte für die Fertigstellung handeln Sprint-Planung.

Die Spielkarten, die das Entwicklungsteam verwendet, folgen einer Fibonacci-Sequenz. Diese Fibonacci-Folge folgt dem Muster 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, wobei jede aufeinanderfolgende Zahl die Summe der beiden vorhergehenden Zahlen ist.

Alternativ können die Teammitglieder ein anderes Kartenspiel verwenden, bei dem der Wert jeder Zahl ein festes Verhältnis hat, z. B. 1, 2, 4, 8, 10, 12 usw.

Verschiedene Kartendecks bieten angepasste Sequenzen, wie 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 und 100. Andere kommerzielle Decks Habe Karten, die darauf hinweisen, dass das agile Team eine Kaffeepause braucht, oder ein Unendlichkeitssymbol, was bedeutet, dass es unmöglich ist, eine Aufgabe zu erledigen.

Ebenso können Teammitglieder ein Standardkartenspiel für Scrum Poker verwenden. Hier verwenden die Teammitglieder das Ass, die 2, 3, 5, 8 und den König.

Wie spielt man Scrum Poker

Jedes Scrum-Team hat unterschiedliche Ziele, aber die allgemeine Reihenfolge beim Planungspoker ist wie folgt:

• Bis auf den Moderator haben alle Teammitglieder ihr eigenes Kartenspiel.
• Teammitglieder stellen dem Moderator (oft dem Product Owner) Fragen zu Themen, User Stories, Storypoints, Produkt-Backlogs, agile Retrospektiven oder was auch immer sie sonst noch für ihren agilen Schätzungs- und Planungsprozess benötigen. Fragen beziehen sich in der Regel auf die Akzeptanzkriterien des Product Owners. Zu den Fragen kann gehören, ob die Backlog-Elemente abgeschlossen sind und was der nächste beste Schritt ist, um den Sprint abzuschließen.
• Sobald der Moderator die Fragen des agilen Teams beantwortet hat, wählt jedes Teammitglied eine Kartenschätzung aus. Das gibt an, wie lange das Arbeitselement ihrer Meinung nach dauern wird.
• Die Teammitglieder legen dann ihre Karten verdeckt auf den Tisch oder verwenden eine Jira-Plugin für verteilte Teams.
• Die Spielkarten werden mit der Vorderseite nach unten gelegt, um zu verhindern, dass sie sich gegenseitig verankern oder beeinflussen.
• Der Moderator deckt die Karten des Scrum-Teams auf, um dessen Schätzungen einzusehen.
• Wenn Teammitglieder im Vergleich zu anderen Teammitgliedern eine hohe oder niedrige Schätzung haben, müssen sie ihre Argumentation erläutern. Das agile Team kann zur Klärung weitere Fragen stellen. Diese Befragungszeit wird oft durch die Verwendung einer Eieruhr begrenzt.
• Der Prozess wird wiederholt, bis sich das Agile-Team auf die Schätzung geeinigt hat, wie lange es dauern wird, jede User Story fertigzustellen.
• Häufig wird eine Einigung über die zweite oder dritte Ziehung der Spielkarten für jedes Arbeitselement erzielt.

Agile Schätzung, die das gesamte Team einbezieht

Planning Poker ist eine genaue, kollaborative Methode zur Teambildung, um den Arbeitsaufwand für jede User Story abzuschätzen.

Während Sie sich darauf vorbereiten, bei Ihrem nächsten Meeting zur Planung Ihrer Produkt-Roadmap den Planungspoker einzusetzen, sollten Sie Folgendes in Betracht ziehen Einfacher agiler Teamrhythmus. Die App hilft dir dabei, Jira-Elemente in Themen zu gruppieren, sodass die Beteiligten einfach den Überblick behalten können.

Eine der Kernfunktionen eines agilen Softwareentwicklungsteams ist die Aufwandsschätzung. Sie können einen Produkt-Backlog nicht richtig priorisieren, ohne vorher eine Vorstellung davon zu haben, wie viel Arbeit erforderlich ist, um die einzelnen User Stories fertigzustellen. Eins agile Schätztechnik plant Poker. Agile Entwicklung ist ein gemeinschaftliches Unterfangen, und Pokerplanung ist eine Übung zur Konsensbildung, bei der Ihr gesamtes Team in den Schätzungsprozess einbezogen wird.

Softwareentwicklungsteams verwenden Planungspoker, um Elementen in ihrem Produkt-Backlog Aufwand zuzuweisen (z. B. Storypoints oder ideale Tage). Manchmal auch Scrum Poker genannt, ist es eine spielerische Methode, einen Konsens zu erzielen, indem alle Mitglieder des Scrum-Teams am Schätzungsprozess teilnehmen können. Physische oder digitale Pokerkarten werden verwendet, um eine gemeinsame Planungssitzung zu ermöglichen. ♠️

Hier geben wir Ihnen eine Anleitung zur Pokerplanung. Zunächst zeigen wir Ihnen, wie man es im Rahmen eines Sprint-Planungsmeetings spielt. Zweitens werden wir uns einige seiner Vorteile als Schätzmethode ansehen. Dann werden wir sehen, warum Planungspoker bei der Planung von Produkt-Roadmaps verwendet werden kann. Es kann helfen, Ihre Stakeholder in eine einvernehmliche Abschätzungssitzung zu den Kundenthemen Ihres Produkts einzubeziehen.

Planungspoker spielen — agile Zusammenarbeit

Eine der wichtigsten Aktivitäten für agile Teams während einer Sprint-Planungssitzung ist die Schätzung des Aufwands, der erforderlich ist, um jede User Story im Sprint abzuschließen. Ein üblicher Weg, dies zu tun, besteht darin, einer einzelnen Person, wie dem Product Owner oder einem Softwareentwickler, zu erlauben, jeder User Story Story Points zuzuweisen. Alternativ können Sie Planungspoker als Schätztechnik verwenden, um das gesamte Team einzubeziehen.

Eine Pokersitzung zur Planung ist eine unterhaltsame und kollaborative Art, die Sprint-Planung spielerisch zu gestalten. Schließlich ist das Agiles Manifest unterstreicht den Wert von Zusammenarbeit und Interaktionen in Softwareentwicklung. Poker zu planen ist eine großartige Möglichkeit, sich an diese agilen Prinzipien zu halten.

Es ist also der Tag der Sprint-Planung. Wenn Ihre Teammitglieder versammelt sind, gehen Sie wie folgt vor:

1. Bereiten Sie die Bühne vor. Wenn Ihr Team noch nicht mit der Pokerplanung vertraut ist, erklären Sie den Ablauf. Sie verwenden Spielkarten, um die Größe jeder User Story in der nächsten Sprint-Iteration abzuschätzen. Der Product Owner oder Scrum-Master fungiert als Moderator, alle Teammitglieder spielen mit, und während der gesamten Sitzung wird es viel Raum für Diskussionen und Fragen geben.
2. Verteile die Pokerkarten. Geben Sie jedem Spieler einen identischen Satz nummerierter Karten. Wir empfehlen, die Fibonacci-Folge zu verwenden — 0, 1, 2, 3, 5, 8, 13, 21 usw. (Um zu erfahren, warum diese Sequenz so effektiv für Schätzungen ist, siehe Mike Cohn von Die Erklärung von Mountain Goat Software.) Und übrigens, wenn ihr euch nicht persönlich treffen könnt und als verteiltes Team plant, dann könnt ihr es versuchen planningpoker.com als Möglichkeit, Ihre Sitzung aus der Ferne durchzuführen. 😃
3. Lesen Sie eine Benutzergeschichte. Der Moderator liest den Teammitgliedern eine Geschichte aus dem Sprint vor. Sie sollten so viele Details und den Kontext wie möglich angeben, damit das Team den Arbeitsaufwand besser einschätzen kann.
4. Besprechen Sie die Geschichte als Gruppe. Lassen Sie das Team zunächst alle klärenden Fragen zu der gerade gelesenen User Story stellen. Öffnen Sie dann das Wort für Diskussionen — jedes Teammitglied kann beschreiben, was nötig ist, um die Geschichte fertig zu stellen, welche Abhängigkeiten die Arbeit blockieren und wer im Team möglicherweise in die Arbeit einbezogen werden muss.
5. Spielt Karten. Jetzt ist es Zeit, das Spiel zu spielen. Jedes Teammitglied reicht eine Karte ein (verdeckt!) an den Moderator. Wenn alle Spielkarten eingereicht wurden, verrät der Moderator, was jeder einzelne schätzt. In einer idealen Welt stimmen alle Zahlen überein! Das bedeutet, dass im Team ein perfekter Konsens über den Aufwand besteht, der für dieses Sprint-Element erforderlich ist, und Sie können mit dem nächsten weitermachen.
6. Diskutieren und schätzen Sie erneut. Höchstwahrscheinlich wird es einen gewissen Unterschied zwischen den ursprünglichen Schätzungen geben. Dies bietet jedem Teammitglied eine hervorragende Gelegenheit, zu belegen, warum seine Schätzungen entweder höher oder niedriger als die der anderen waren. Dann kannst du eine weitere Runde machen, in der du die Karten einreichst und aufdeckst, um zu sehen, ob es weitere Übereinstimmungen gibt. Tipp: Lass den Moderator entscheiden, wann die Runde beendet werden soll. Denken Sie daran, dass Sie nicht für jede User Story einen perfekten Story-Point-Konsens benötigen.

Du hast es geschafft! Ihr Sprint ist geplant, und das gesamte Team hat ein gemeinsames Verständnis dafür gewonnen, wie jedes Mitglied den Aufwand und die Arbeit wahrgenommen hat, die erforderlich sind, um jede User Story fertig zu stellen.

Die Vorteile von Planning Poker Agile Estimation

Als agile Schätz- und Planungstechnik hat Planungspoker seine Vorteile:

• Es fördert die Zusammenarbeit. Als funktionsübergreifendes Team ist es wichtig, dass jedes Teammitglied während des Schätzungsprozesses eine Stimme hat. Da jeder Schätzer seine Sicht auf eine Nutzerstory darlegt, versteht die Gruppe besser, wie sie zu ihrer Schlussfolgerung gekommen ist.
• Es fördert den Konsens in Ihrem gesamten Team. Bei jeder Runde des Planungspokers ist es wahrscheinlicher, dass die Schätzungen des Teams übereinstimmen.
• Es wurde nachgewiesen, dass der Wert eine genauere Methode zur Schätzung darstellt (im Vergleich zu einer einzelnen Person, die die Schätzungen vorlegt).

In einer Studie veröffentlicht von ScienceDirect, Planungspoker wurde verwendet, um die Hälfte der Arbeit eines Softwareprojekts abzuschätzen. Es gab zwei Entdeckungen. Erstens waren die Schätzungen von Planning Poker statistisch gesehen höher als die individuellen Schätzungen. Zweitens erwiesen sich die Poker-Schätzungen als genauer als die individuellen Schätzungen für dieselben Aufgaben.

Planungspoker für Roadmap-Planung

Pokerplanung ist eine unterhaltsame und effektive Methode, um eine genaue Schätzung Ihrer Artikel im Produktbestand zu erhalten. Aber warum sollten Sie es nicht auch für strategische Planungssitzungen wie die Roadmap-Planung verwenden?

In unserem definitiver Leitfaden für Produkt-Roadmaps, wir erörtern, wie sich Roadmaps auf übergeordnete, kundenorientierte Themen konzentrieren und nicht auf einzelne Funktionen. Wir heben auch hervor, dass die Entwicklung Ihrer Produkt-Roadmap ein kollaborativer Prozess sein sollte (genau wie die Sprint-Planung) und mehrere Interessengruppen einbeziehen sollte.

Gehen Sie also zurück zu den obigen Schritten. Überlegen Sie, wie Sie mithilfe von Planungs-Pokerkarten Ihre relevanten Stakeholder dazu bringen können, den relativen Umfang der einzelnen Kundenthemen in Ihrer Produkt-Roadmap abzuschätzen. Es wird Spaß machen, einen umfassenden Konsens über die Produktvision Ihres Unternehmens zu erzielen.

Gruppieren Sie Ihre Themen

Planning Poker ist eine kollaborative Methode, um das gesamte Team dazu zu bringen, den Arbeitsaufwand einer User Story abzuschätzen. Es sorgt für Konsens und ist in der Regel genauer.

Wenn du Jira für die Durchführung deiner Sprint-Planungsmeetings verwendest, hast du bereits ein Tool, das deine User Stories und dein Produkt-Backlog organisiert. Wenn du versuchst, in deinem nächsten Meeting zur Planung deiner Produkt-Roadmap Poker zu planen, gib Einfache agile Benutzer-Roadmaps für Jira ein Blick. Es bietet die Möglichkeit, Jira-Elemente in Themen zu gruppieren, die Ihre Stakeholder leicht sehen können. Viel Spaß beim Spielen!