Estimation

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.

Agile Schätzungstechniken sind erstaunlich einfach, können aber für Softwareentwicklungsteams manchmal komplexer als nötig gestaltet werden. Nachdem sie in den letzten Wochen eines großen Projekts den Zorn erlebt haben, bei früheren Aufträgen eine Frist zu verpassen und Angst vor 20-Stunden-Arbeitstagen zu haben, ist es kein Wunder, dass agile Teammitglieder vorsichtig mit Schätzungen umgehen. Wie oft hat Ihre Schätzung Sie schon einmal getroffen? 😱

Agile Schätztechniken wurden entwickelt, um ein nachhaltiges Entwicklungstempo zu erreichen und den Stakeholdern realistischere Terminerwartungen zu bieten. Sie verwenden relative Größenangaben, anstatt Schätzungen in Echtzeit vorherzusagen.

Zu den beliebten Schätzmethoden in einer agilen Entwicklungsumgebung gehören Story Points, Punktabstimmung, ein Bucket-System, Affinitäts-Mapping und T-Shirt-Größen. Die Größe von T-Shirts ist eine gängige Methode zur agilen Schätzung, die sich bei der langfristigen Planung als sehr effektiv erweisen kann oder Ihrem Team hilft, sich an relative Schätzungen zu gewöhnen.

Wir geben Ihnen einen kurzen Überblick über diese agilen Schätztechniken, aber dann werden wir uns mit der Größe von T-Shirts und den verschiedenen Möglichkeiten befassen, wie Sie diese Technik anwenden können.

Notieren Sie sich Ihre Schätzungen in Jira mit

Einfache Agile User Story Maps

Kostenlose Testversion

Ein kurzer Überblick über einige beliebte agile Schätztechniken

Wenn Sie diesen Artikel lesen, sind Sie wahrscheinlich bereits mit Story Points vertraut, die normalerweise für die Sprint-Planung verwendet werden, daher werden wir keine Zeit damit verbringen, diese aufzuarbeiten. Wenn Storypointing jedoch keine vertraute agile Schätztechnik ist, gehen Sie wie folgt vor ein Artikel, der Storypoints definiert und noch eine über bestimmte Zeiten, zu denen Storypoints könnte in Ihrem Team am besten funktionieren.

Die anderen agilen Schätzungstechniken, die wir uns zuerst ansehen werden, eignen sich eher für Road Mapping oder Release-Planung als für die Sprint-Planung. Lassen Sie uns einen kurzen Überblick über Affinitäts-Mapping, Bucket-Systeme und Punktabstimmung geben.

Affinitätszuordnung

In der Produktentwicklung bezieht sich „Affinität“ auf ähnliche Backlog-Elemente, entweder in Bezug auf Codetypen, Produktbereiche oder Aufwand. Bei der Abbildung von Affinitäten im Rahmen der agilen Schätzung sprechen wir von der Gruppierung von Arbeitselementen ähnlicher Größe. Geh und finde es heraus.

Um ein Affinitäts-Mapping durchzuführen, klebt der Moderator die Backlog-Elemente auf einzelne Haftnotizen und befestigt sie an einer Wand. Identifizieren Sie an einer anderen Wand eine Seite als „Kleiner“ und die andere Seite als „Größer“. Bitten Sie dann das Scrum-Team, die Elemente im Hintergrund von der Backlog-Wand auf die Größenordnung zu verschieben, in die sie passen, je nachdem, wie groß das Objekt wahrgenommen wird oder wie lange das Team voraussichtlich benötigen wird, um es fertigzustellen.

Der Schlüssel zu dieser Technik liegt darin, schnell vorzugehen, nicht zu viel darüber nachzudenken und nicht darüber zu diskutieren. Sobald alle Gegenstände an der Wand angebracht sind, können die Teammitglieder besprechen, welche Gegenstände möglicherweise falsch dimensioniert sind. Nach einer kurzen Diskussion kann das Team entscheiden, ob die Gegenstände verschoben werden sollen.

Nachdem alle mit der Platzierung zufrieden sind, kann sich der Product Owner vertikale Linien an der Wand vorstellen, die den Backlog in Abschnitte unterteilen, und jedem Artikel einfach eine T-Shirt-Größe zuweisen und ihn auf einer Roadmap platzieren.

Schaufelsysteme

Ein Bucket-System ähnelt dem Affinitäts-Mapping, außer dass es erwartet, dass Sie etwas spezifischer werden. Es verwendet die Zahlen 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100 und 200 als relative Größen, und die Teammitglieder legen alle Backlog-Elemente in einen der Buckets. Auch dies geschieht im Hintergrund, aber das Team kann am Ende alle Elemente besprechen, die ihrer Meinung nach in den falschen Eimer gelegt wurden.

Punktabstimmung

Eine weitere Möglichkeit, wie agile Entwicklungsteams Schätzungen vornehmen können, ist die Punktabstimmung. Ja, es geht wirklich darum, Punktaufkleber auf Notizkarten oder Haftnotizen zu kleben. Aber das ist eine interessante Technik, die andere Konzepte als die relative Größe beinhaltet.

Bei der Punktabstimmung erhalten die Teammitglieder fünf Punkte. Diese Punkte beziehen sich auf das, was jedes Teammitglied für die wichtigste Arbeit im Backlog hält. Die Bedeutung könnte aus technischen Gründen wie der Überarbeitung einer Datenbank zur Skalierung vor der nächsten Hauptsaison oder aus geschäftlichem Nutzen wie den am häufigsten nachgefragten neuen Funktionen aufgrund von Kundenfeedback resultieren.

Backlog-Elemente werden dann auf der Grundlage ihres Werts (der Anzahl der Punkte) zur Roadmap hinzugefügt und können dann mithilfe einer anderen Technik an den Aufwand angepasst werden.

Wie Sie sehen, sind diese agilen Schätztechniken besonders nützlich, wenn Sie einen großen Rückstand haben, bei dem Sie jedes Mal, wenn Sie versuchen, ihn zu organisieren, das Gefühl haben, Katzen zu hüten. In der Regel werden diese Schätzprozesse zu Beginn eines Projekts, bei der Erstellung wichtiger Funktionen oder bei der jährlichen oder halbjährlichen Roadmap-Planung eingesetzt.

Lassen Sie uns nun tief in die Größe von T-Shirts eintauchen.

T-Shirt-Größen für Artikel aus dem Produktrückstand

Ahhhh, die T-Shirt-Größe. XS, S, M, L, XL — wie kann das einschüchternd sein? Es ist so einfach und doch so flexibel. Die T-Shirt-Größe wird hauptsächlich für die Roadmap- und Release-Planung verwendet und ist nichts weiter als eine Schätzung des Aufwands auf der Grundlage der zum Zeitpunkt der Schätzung verfügbaren Informationen. Deshalb ist es so einfach. Das ist eine Schätzung, und das ist okay. 👌

Sie fragen sich vielleicht, warum die Größe von T-Shirts so wichtig ist, wenn es sich um eine solche ungefähre Zahl und eine relative Schätzung handelt. Es ist hilfreich für die langfristige Planung. Ja, du hast es richtig gehört. Agile Teams planen. Wenn Sie einen kurzen Blick auf die werfen Agiles Manifest, der vierte Wert agiler Entwicklungsteams lautet:

„Auf Veränderungen zu reagieren, anstatt einem Plan zu folgen.“

Ein Team kann nicht auf Veränderungen reagieren, wenn es nie von Anfang an einen Plan befolgt hat. Durch eine langfristige agile Planung wissen Sie, ob Sie den Stakeholdern realistische Erwartungen für die nächsten 6 bis 12 Monate stellen. Oder wenn sich die Bedürfnisse des Unternehmens ändern oder die vorhandenen Ressourcen nicht ausreichen und Sie ein zusätzliches Team zusammenstellen müssen. Schätzungen von T-Shirts helfen auch dabei, zu ermitteln, wie viele Iterationen in jeder Version enthalten sein müssen, um den Endbenutzern den größtmöglichen Nutzen zu bieten.

Agile Estimation beginnt mit einer T-Shirt-Größe für die Planung zukünftiger Releases, wird dann für die Sprint-Planung in Story Points aufgeteilt und kann für die Sprint-Ausführung sogar noch weiter in Stunden unterteilt werden. Unabhängig davon ist der Hauptpunkt folgender: Je näher die Arbeit der Tastatur eines Entwicklers kommt, desto kleiner und einfacher ist es, sie genau abzuschätzen. Die T-Shirt-Größe ist am weitesten von der Ausführung entfernt, daher wird nicht erwartet, dass die Schätzung perfekt ist.

Die Größe des T-Shirts ist schnell

Wenn Sie schon einmal einen Backlog mit Hunderten von Arbeitselementen geerbt haben und dann die Frage erhalten haben: „Wie lange wird es dauern, all das zu erledigen?“ du bist nicht allein. Ihr erster Versuch, die Beantwortung dieser unmöglichen Frage zu vermeiden, könnte eine gute Bereinigung des Backlogs sein. Nehmen wir an, Sie löschen ein Arbeitselement, das älter als sechs Monate ist. Ich meine, hey, wenn es schon so lange im Produkt-Backlog ist, ist es vielleicht nicht wirklich so wichtig.

Aber wenn Sie einem Team beigetreten sind, das gerade erst mit agilen Methoden angefangen hat, werden Sie wahrscheinlich mit einem großen Rückstand feststecken und Produktmanager erwarten eine altmodische Schätzung.

Die Größe von T-Shirts ist hier praktisch. Da bekannt ist, dass Sie Schätzungen aus dem Bauch heraus abgeben, kann Ihr Team einen riesigen Rückstand im Handumdrehen bewältigen. Beschränken Sie die Entscheidungsfindung auf 30 Sekunden pro Artikel, um sicherzustellen, dass die Teammitglieder bei Übungen zur Größe von T-Shirts nicht zu viel über jeden Artikel nachdenken.

Das Ergebnis ist ein einigermaßen organisierter Rückstand mit relativen Schätzungen. Der Produkteigentümer und die Interessengruppen können anhand dieser Informationen entscheiden, was kurzfristig geschehen soll.

Wie funktioniert die Größe von T-Shirts?

Abhängig von Ihrer Backlog-Größe gibt es verschiedene Möglichkeiten, wie Sie die Größe von T-Shirts angehen können. Bei einer kleinen Anzahl von Artikeln funktioniert Planungspoker hervorragend. Bitten Sie einfach Ihren Scrum Master, die Karten mit den Fibonacci-Sequenznummern gegen Buchstaben in T-Shirt-Größe auszutauschen.

Diese Technik eignet sich auch gut, wenn Sie eine Teilmenge eines umfangreicheren Backlogs schätzen müssen.

Sie sollten wahrscheinlich einen Prozess verwenden, der Affinitätszuordnungen und Bucket-Systemen für große Backlogs ähnelt. Jeder arbeitet unabhängig daran, die Größe zuzuweisen, und am Ende bespricht er dann Konflikte. Diese Technik ermöglicht es auch kleinen Teams, einen großen Backlog relativ schnell zu überwinden.

Schließlich möchten einige neue agile Teams vielleicht ihre Schätzungsreise beginnen, indem sie T-Shirt-Größen für User Stories und die Sprint-Planung verwenden. Mike Cohn, einer der Gründer der Scrum Alliance und ein Experte für agile Prozesse, schlägt vor dass Teams, die sich für diesen Ansatz entscheiden, jeder T-Shirt-Größe einen Story-Point-Wert zuweisen. Diese Technik hilft den Teams, sich mit den Storypoints vertraut zu machen, die innerhalb des Sicherheitsnetzes bei der Schätzung der T-Shirt-Größe liegen.

Übung macht den Meister mit agilen Schätztechniken

Unabhängig von der Art des agilen Projekts, an dem Sie arbeiten oder für welchen Schätzprozess Sie sich entscheiden, je mehr Sie üben, desto schneller wird Ihr Team zu Meisterschätzern. 👑 Wir empfehlen, ein paar verschiedene Methoden auszuprobieren, um herauszufinden, welche für Ihr Team am besten geeignet ist.

Eine letzte Sache: Denken Sie daran, dass Story-Point-Schätzungen am besten für die Sprint-Planung geeignet sind. Affinitäts-Mapping, Bucket-Systeme, Punktplanung und T-Shirt-Größe eignen sich besser für die Roadmap- und Release-Planung.

Wenn du Hilfe brauchst, um deine Planung von der Wand auf Jira zu übertragen, solltest du es versuchen

Einfache agile Roadmaps

Vergessen Sie nicht, sich unsere anzusehen weitere Blogartikel um Ihrem Team auf seiner agilen Reise zu helfen.