5 Tipps zur agilen Schätzung, die bei der Priorisierung von Backlogs helfen

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.

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!