Keine Artikel gefunden.

Agile Schätzungstechniken: Ein tiefer Einblick in die T-Shirt-Größe

Inhalt
Dies ist ein Text innerhalb eines div-Blocks.
Dies ist ein Text innerhalb eines div-Blocks.
Dies ist ein Text innerhalb eines div-Blocks.
Abonnieren Sie unseren Newsletter

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

Agile estimation techniques: Group of people looking at sticky notes on glass wall

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

Agile estimation techniques: Group of people sitting on the floor and looking at the camera

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

Two co-workers looking at sticky notes on glass window board

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

Woman sitting in a bean bag while working on her laptop

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.

Keine Artikel gefunden.

Verwandte Artikel

  • Workflow

    10 Gründe, warum Sie Story Points zur Schätzung verwenden sollten

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


    1. Schnelle Schätzung

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

    2. Sorgen Sie für Konsens und Zusammenarbeit

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

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

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

    3. Keine künstlichen Fristen

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

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

    4. Bessere Planung und Prognose

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

    5. Zoomen Sie auf die Details

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

    6. Holen Sie sich Engagement

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

    7. Sei anpassungsfähiger

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

    8. Sei gerade genau genug

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

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

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

    9. Bessere Kapazitätsplanung

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

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

    10. Leistung messen und verbessern

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

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

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

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

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

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

    Also, wie integrieren Sie sie in Ihren Arbeitsablauf?

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

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

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

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

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

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

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

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

    Ordnen Sie Storypoints in Easy Agile TeamRhythm zu

    in-line edit

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

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

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

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

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

    Kostenlose Testversion: Easy Agile TeamRhythm

  • Agile Best Practice

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

    Die Priorisierung von Backlogs ist eine nie endende Aufgabe für Product Owner und Produktmanager. Wenn sich die Prioritäten als Reaktion auf sich ändernde Geschäftsanforderungen weiterentwickeln oder sogar die Arbeit abgeschlossen ist oder Anpassungen an der Teamausstattung vorgenommen werden, ist es wichtig, dass Sie sich weiterhin auf die Arbeit konzentrieren, die den größten Nutzen bringt, indem Sie Ihren Backlog in einem guten Zustand halten. Agile Schätzungstechniken können die Priorisierung Ihres Backlogs schneller und einfacher machen.

    Schauen wir uns also einige spezifische Methoden an, um priorisiere deinen Backlog und erfahren Sie, wie agile Schätzungen dazu beitragen können, Ihren Endbenutzern und Stakeholdern den größtmöglichen Nutzen zu bieten.

    5 Möglichkeiten, einen Backlog zu priorisieren

    Natürlich gibt es mehr als fünf Möglichkeiten, Arbeitselemente in einem Backlog zu priorisieren. Wir haben jedoch einige unserer Favoriten ausgewählt, die in Kombination mit einem agilen Schätzprozess dazu beitragen, dass unser Produkt-Backlog stets priorisiert bleibt, sodass wir die Sprint-Planung im Handumdrehen durchführen können.

    1. Gewichteter kürzester Job zuerst

    Wow, ist das ein Schluck voll! Verwenden wir das Akronym „WSJF“, um uns darauf zu beziehen SAFE-Technik. WSJF ist nicht so einschüchternd, wie es klingt. Es handelt sich um eine einfache Formel, die Artikeln aus dem Produktrückstand einen Geschäftswert zuweist.

    WSJF = Kosten der Verzögerung ÷ Auftragsdauer

    Kosten der Verzögerung ist die Summe von drei relativen Metriken:

    • Nutzer-/Geschäftswert: Die relative Wichtigkeit des Arbeitselements.
    • Zeitkritikalität: der Rückgang des Nutzer-/Geschäftswerts im Laufe der Zeit.
    • Reduzierung des Risikos: die Reduzierung des geschäftlichen oder technischen Risikos.

    Um die relative Größe der Verzögerungskosten zu ermitteln, stellen Sie sich den niedrigsten Geschäftswert, den geringsten Wertverlust im Laufe der Zeit und die geringste Risikominderung als Wert 1 vor. Das Gleiche wie bei Schätzung des Storypoints der Fibonacci-Sequenz, passen Sie diese Punktzahl entsprechend an, wenn Sie Arbeitselemente vergleichen, um sie relativ zueinander zu bewerten.

    Die Jobdauer wird ebenfalls relativ ausgedrückt. Wenn Sie Ihre Arbeitselemente mithilfe einer relativen Schätzung anhand von Story Points schätzen, entspricht der Story-Point-Wert der Auftragsdauer.

    Wenn du diese Technik verwendest, um eine große Menge an Arbeit in einem Backlog zu priorisieren, in dem einige Artikel nur T-Shirt-Größe hatten, konvertiere deine T-Shirt-Größen in Standard-Fibonacci-Zahlen und verwende diesen Wert.

    Warnung: Seien Sie vorsichtig bei der Umrechnung von T-Shirt-Größen in Story Points. Sie benötigen eine Möglichkeit, die Arbeitselemente in T-Shirt-Größe zu kennzeichnen, die Sie in Story Points umgewandelt haben. Sie und Ihr Scrum Master müssen diese Schätzungen als Schätzungen der T-Shirt-Levels erkennen und nicht als tatsächliche Schätzungen der Storypoints, die mit vollständig verfeinerten Arbeitsaufgaben einhergehen.

    Sehen Sie in Easy Agile TeamRhythm mehr auf einen Blick, um die Priorisierung Ihres Backlogs zu beschleunigen

    💡 Tipp: Füge bis zu drei zusätzliche Felder auf Ausgabekarten hinzu

    SEHEN SIE WIE

    2. Moskau

    Ein Muss, ein Muss, ein Könnten-Hättest und ein Nicht-Haben sind die Kriterien, die verwendet werden, um einen Backlog mit der MoSCoW-Technik zu priorisieren. Das Produktteam definiert diese Bezeichnungen auf der Grundlage der einzigartigen Eigenschaften des Produkts und der Konkurrenzangebote.

    Jedes Arbeitselement fällt in eine dieser Kategorien. Der einfachste Teil dieses Vorgangs besteht darin, Won't-have-Elemente direkt in den Papierkorb zu schicken und sie dir aus dem Weg zu räumen. Als Nächstes priorisieren Sie zuerst die Must-Haves und dann die Soll-Haves. Die Elemente, die man haben könnte, fallen natürlich an das Ende des Backlogs.

    Nehmen Sie diese Artikel in Ihre regelmäßigen Verfeinerungsgespräche mit Ihren Teammitgliedern auf und weisen Sie jedem Artikel eine T-Shirt-Größe oder einen Storypoint-Wert zu. Dann bist du bereit, deinen Sprints oder Releases die richtige Menge an Arbeitselementen hinzuzufügen, basierend auf der Geschwindigkeit deiner Teams oder der Anzahl der Storypoints, die sie während eines Sprints voraussichtlich abschließen werden.

    3. Kano

    Das Kano-Modell der Priorisierung verwendet fünf Klassifizierungen:

    • Muss sein: die grundlegende Funktionalität, die Ihre Benutzer erwarten.
    • Attraktiv: eine angenehme Überraschung für Ihre Benutzer, aber niemand wird verärgert sein, wenn es nicht da ist.
    • Eindimensional: Arbeitselemente, die Ihre Nutzer glücklich machen und sie enttäuschen werden, wenn sie nicht Teil Ihres Produkts sind.
    • Gleichgültig: Arbeitselemente, die für Ihre Kunden unwichtig sind. Oft handelt es sich bei diesen Arbeitsaufgaben um technische Probleme oder Verbesserungen, die dem Softwareentwicklungsteam helfen, effizienter zu entwickeln oder mit den neuesten Versionen seines Tech-Stacks zu arbeiten — aber Ihren Kunden sind sie wirklich egal.
    • Umgekehrt: Der Vorgang, bei dem eine frühere Funktion oder ein vorheriges Update rückgängig gemacht wird. Wenn Sie jemals eine Funktion entwickelt oder eine Benutzeroberflächenaktualisierung vorgenommen haben, die Ihre Benutzer gehasst haben, dann kennen Sie sich mit Reverse-Work-Aufgaben aus. Hoppla. Leider sind dies manchmal notwendige Übel, insbesondere wenn es um Sicherheitsfunktionen oder die Umstellung von Benutzern auf ein neues Produkt geht, nachdem sie ein veraltetes Produkt außer Dienst gestellt haben.

    Wie bei der MoSCoW-Methode schätzen Sie diese Arbeitselemente während der Verfeinerung und fügen sie dann Ihrem Iterations- oder Release-Plan hinzu. Aber anders als bei MoSCow möchten Sie vielleicht Ihre Sprints und Releases mit Arbeitselementen aus jeder Klassifizierung ausgleichen.

    4. Rangliste stapeln

    Die brutalste aller Priorisierungstechniken, das Stack-Ranking, zwingt Teams dazu, eine lineare Rangfolge der Arbeitsaufgaben zu haben, was bedeutet, dass es nur eine oberste Priorität, eine zweite Priorität, eine dritte Priorität usw. gibt. Brutal!

    Sobald du dich daran gewöhnt hast, ist Stack-Ranking eine nützliche Methode, um zu erzwingen Produktmanager um schwierige Entscheidungen zwischen Arbeitselementen zu treffen. Selbst wenn zwei Arbeitselemente während desselben Sprints abgeschlossen werden können, ist es Sache des PO, zu bestimmen, welches zuerst erledigt wird, und dann spiegelt sich diese Wahl im Sprint-Backlog wider.

    Oft wird dieser Job einfacher, wenn er schlecht formuliert wird. Wenn Sie zum Beispiel nur einen Tag Zeit hätten, um neue Nutzer für Ihr Produkt zu gewinnen, welche Arbeit würden Sie in der Produktion erwarten? BUMM! Da ist deine oberste Priorität.

    Das Schöne am Stack-Ranking ist, dass es PoS ermöglicht, kleinere Arbeitselemente in aktuelle Sprints zu verschieben, wenn andere Arbeiten mit höherer Priorität zu umfangreich sind. Wenn das größere Arbeitselement hinzugefügt wird, wird das Team aufgrund seiner Geschwindigkeit zu viel beansprucht. Diese kleinen Arbeitselemente dienen dazu, die Sprints zu füllen, damit die Teams ihr Tempo beibehalten und so produktiv wie möglich arbeiten können. Nur weil ein Arbeitselement, das zwei Stockwerke hoch ist, zu zwei Dritteln im Backlog liegt, heißt das nicht, dass es niemals erledigt werden kann.

    5. Zuordnung von Geschichten

    Mithilfe von Story Mapping können Sie die Reise des Kunden durch Ihr Produkt von Anfang bis Ende visualisieren. (Ja, das haben wir direkt von unserem anderen gestohlen ausgezeichneter Artikel zum Thema Story-Mapping.) Fortgeschrittene Story-Mapper sollten das, was Sie über Story-Mapping gelernt haben, nutzen und darüber nachdenken, wie Sie MoSCOW- oder Kano-Techniken zu Ihren Story-Maps hinzufügen können.

    Vielleicht könnte dein episches Rückgrat oben auf der User-Story-Map die Buckets in der MoSCoW-Methode repräsentieren?

    Wenn Sie wie wir sind, sind Ihre Story-Mapping-Sitzungen produktive Brainstorming-Aktivitäten, und Sie werden die Sitzungen mit viel mehr Arbeit verlassen, als Sie erledigen können. Indem Sie die MoSCoW- oder Kano-Prinzipien auf die Geschichten in Ihren Benutzererlebnissen anwenden, werden Sie die wichtigsten Geschichten entdecken, die Sie priorisieren müssen, und die Geschichten, die auf eine spätere Veröffentlichung warten können.

    Agile Schätzung in die Backlog-Priorisierung einbauen

    Wir haben Ihnen fünf verschiedene Techniken an die Hand gegeben, mit denen Sie Ihre Arbeitselemente in einem organisierten, priorisierten und wertschöpfenden Produkt-Backlog zusammenfassen können:

    1. Gewichteter kürzester Job zuerst
    2. MOSKau
    3. KANO
    4. Rangfolge stapeln
    5. Storymaps

    Wir haben Ihnen auch Möglichkeiten aufgezeigt, wie Sie agile Schätzungen wie T-Shirt-Größen und Storypoints in Ihren Priorisierungsprozess einbeziehen können, damit Ihr Team die wichtigsten Aufgaben erledigt und gleichzeitig die Geschwindigkeit beibehalten und Ihre Kunden und Stakeholder beeindrucken kann.

    Wir empfehlen Ihnen, diese Ideen aufzugreifen, sie mit Ihrem Team zu teilen und sie auszuprobieren. Wenn Sie Hilfe bei der Verwendung des Story-Map-Konzepts benötigen, versuchen Sie es Einfacher agiler Teamrhythmus. Wie auch immer Ihr Team seinen Produkt-Backlog priorisiert, denken Sie daran, die wichtigsten Arbeiten an die erste Stelle zu setzen und diese Prioritäten dann nach Bedarf anzupassen. Machen Sie es einfach und bleiben Sie agil!

  • Agile Best Practice

    Das Problem mit der agilen Schätzung

    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.