Die folgenden Abbildungen zeigen die Leistung eines Scrum-Teams während der ersten 6 Sprints eines Projekts.
Frage 1: Wie groß ist die Velocity des Teams?
Frage 2: Wie viele Story Points werden voraussichtlich von diesem Team in Sprint 7 erreicht?
Frage 3: Nun, wenn a eine Tabelle wie unten hat und das Product Backlog darstellt. Welche Geschichten würden Sie für Sprint 7 auswählen und warum?
+---------------+
| Story Id | SP |
+---------------+
| S1 | 3 |
| S2 | 1 |
| S3 | 3 |
| S4 | 5 |
| S5 | 8 |
| S6 | 3 |
| S7 | 1 |
| S8 | 1 |
| S9 | 5 |
+---------------+
Frage 4: Und basierend auf den obigen Daten, wie viele Sprints sind erforderlich, um das Projekt abzuschließen?
Frage 5: Zeichnen Sie ein Burndown-Diagramm für dieses Scrum-Projekt, indem Sie die Daten aus den beiden obigen Tabellen verwenden. Was lässt sich aus diesem Burndown-Chart ableiten?
Frage 1: Wie groß ist die Velocity des Teams?
Du hast es ja schon in deiner Frage aufgeschrieben, es ist einfach die Anzahl der Story Points die in einem Sprint „verbrannt“ werden ( Velocity ). In Sprint 1 ist Ihre Geschwindigkeit also 15. Bitte beachten Sie, dass nur "erledigte" Stories gezählt werden. Interessanter ist der durchschnittliche Geschwindigkeitsbedarf für Frage zwei.
Frage 2: Wie viele Story Points werden voraussichtlich von diesem Team in Sprint 7 erreicht?
Die "durchschnittliche" Geschwindigkeit ist interessanter, da sie Ihnen hilft, die Geschwindigkeit für kommende Sprints vorherzusagen. Das geht ganz einfach, indem man alle Story Points vergangener Sprints addiert und durch die Anzahl der Sprints dividiert. In Ihrem Fall kann dies zu Folgendem führen:
(15 + 5 + 20 + 15 + 25 + 10) / 6 = 90 / 6 = 15
Da sich Ihre Geschwindigkeit im Laufe der Zeit ändert (Sie werden schneller, die Teamzusammensetzung ändert sich usw.), dürfen Sie nur die letzten 3 Sprints absolvieren. Scrum Inc. empfiehlt das Wetter von gestern, um den nächsten Sprint vorherzusagen, auch in Bezug auf die Anzahl der verfügbaren Teammitglieder.
Frage 3: Nun, wenn a eine Tabelle wie unten hat und das Product Backlog darstellt. Welche Geschichten würden Sie für Sprint 7 auswählen und warum?
Wenn die Tabelle einen priorisierten Rückstand darstellt (dies ist ein Muss in Scrum!), würden Sie die ersten X Stories abhängig von Ihrer geschätzten Velocity für den nächsten Sprint nehmen.
Die Reihenfolge hängt nur vom Product Owner ab, er/sie ist der einzige, der den Rückstand priorisiert. Dazu gibt es mehrere Ansätze:
Frage 4: Und basierend auf den obigen Daten, wie viele Sprints sind erforderlich, um das Projekt abzuschließen?
Nehmen wir die oben berechnete Durchschnittsgeschwindigkeit (15SP). Ihr Backlog hat eine Gesamtgröße von
3 + 1 + 3 + 5 + 8 + 3 + 1 + 1 + 5 = 30SP
Theoretisch könnten Sie das Projekt also innerhalb von zwei Sprints abschließen.
(!) Aber Vorsicht, all diese Zahlen sind Schätzungen und KEINE Fakten. Ihre niedrigste Geschwindigkeit war 5 SP und Ihre höchste 25 SP, im schlimmsten Fall benötigen Sie also möglicherweise 6 Sprints oder mehr, um es zu beenden.
Es ist nichts Falsches daran, akademische oder Hausaufgabenfragen zu stellen, aber Fragen zu stellen, bei denen Sie sich keine Mühe gegeben haben, die Fragen selbst zu lösen, ist verpönt. Außerdem haben Hausaufgabenfragen nicht immer kanonische Antworten, weil die einzig „richtige“ Antwort die ist, nach der dein Lehrer sucht.
Vor diesem Hintergrund lohnt es sich, die Fragen, die Sie stellen, aus zwei Gründen zu beantworten:
Meine Antworten unten werden Ihnen helfen, Ihre Hausaufgabenfragen sachkundiger zu beantworten, aber sie können oder müssen nicht die Antworten sein, die Ihr Lehrer von Ihnen erwartet hat. Ihr Kilometerstand wird daher variieren. Viel Erfolg bei Ihrem Auftrag!
Bei Geschwindigkeitswerten von 15, 5, 20, 15, 25, 10 hast du eine mittlere Geschwindigkeit von 15. Es besteht eine Wahrscheinlichkeit von 90 % (technisch gesehen ein Konfidenzintervall), dass deine tatsächliche Geschwindigkeit für deinen nächsten Sprint zwischen 5 und 25 liegt .
Siehe Velocity Range Calculator für die Mathematik hinter dieser Berechnung. Sie können Ihre eigenen Berechnungen mit einem anderen Konfidenzintervall durchführen, wenn Sie dies bevorzugen.
Sie können eine beliebige Mischung aus Storys auswählen, die Ihnen gefällt, vorausgesetzt, die Gesamtzahl liegt unter der erwarteten Kapazität des Teams und die ausgewählten Storys beziehen sich alle auf das aktuelle Sprint-Ziel. Ohne Fudge-Faktoren oder Diskussionen über die Risikotoleranz für ein nicht erfülltes Sprint-Ziel würde ich davon ausgehen, dass 15 Story Points als zuverlässiges Ziel eine kleine Geschichte geben oder nehmen.
Die Sprint-Planung ist teilweise ein Rucksackproblem , wird aber weiter verkompliziert durch die Anforderung, Stories in der Prioritätsreihenfolge von oben im Product Backlog auszuwählen und sicherzustellen, dass alle ausgewählten Stories zur Kohärenz beitragen (oder zumindest nicht davon ablenken). eines einzelnen Sprintziels. Aus diesem Grund werden das Entwicklungsteam und der Product Owner ermutigt, während der Backlog Refinement- und Sprint Planning-Meetings Stories zu diskutieren und Kuhhandel zu betreiben: damit der Product Owner das Product Backlog spontan bearbeiten und neu priorisieren kann, um Stories für die Teamauswahl zu optimieren.
Das Team kann Storys nicht nur auf der Grundlage von Größenschätzungen auswählen, noch sollten Storys hauptsächlich auf der Grundlage des Versuchs ausgewählt werden, die Anzahl der Story Points für den Sprint zu maximieren. In Scrum müssen Stories vom Team in strikter Prioritätsreihenfolge aus dem Product Backlog ausgewählt werden, bis ihre erwartete Kapazität für den Sprint zugewiesen ist, aber es ist die Aufgabe des Product Owners sicherzustellen, dass diese Prioritätsreihenfolge eine zentrale Kohärenz für den Sprint widerspiegelt.
Das Akzeptieren von Geschichten basierend auf Ordinalwerten bis (aber niemals darüber hinaus) der Kapazitätsprognose des Teams mag kontraintuitiv klingen, sollte es aber wirklich nicht. Pragmatisch gesehen optimieren Scrum-Teams eher auf Kohärenz und einen zuverlässigen Rhythmus als auf Geschwindigkeit um ihrer selbst willen. Die Geschwindigkeit ist nur ein Proxy für die Kapazität zur Unterstützung der Prognose.
Algorithmendesigner streben nach optimalen Lösungen für das Rucksackproblem. Scrum-Teams streben danach, Wert in einem zuverlässigen Takt zu liefern. Ein zu starker Fokus auf die Optimierung der Velocity ist ein deutliches Anti-Pattern.
Sie haben noch 30 Story Points in Ihrem Product Backlog. Unter der Annahme, dass Sie genau geschätzt haben und sich die Schätzungen für den Rest des Projekts nicht ändern – von den Teams wird erwartet, dass sie basierend auf neuen Informationen während der Backlog-Verfeinerung und der Sprint-Planung neu schätzen – und auch unter der Annahme, dass Sie nichts zu Ihrem Produkt hinzufügen oder daraus entfernen Rückstand über die nächsten zwei Sprints, dann werden Sie bei Ihrer gegenwärtigen Geschwindigkeit mindestens zwei Sprints benötigen, um den gesamten aktuellen Rückstand zu vervollständigen.
Beachten Sie, dass es möglich ist, dass das Projekt nach dem aktuellen Sprint als ausreichend erklärt und abgeschlossen werden kann, da ein Sprint am Ende jeder Iteration ein potenziell freizugebendes Inkrement bereitstellt. Wenn Ihr Team alternativ weniger als den Median liefert (Ihr Konfidenzintervall hat fünf Story Points als Low-End-Prognose), kann es bis zu sechs Sprints dauern, um das gesamte Product Backlog in seiner aktuellen Zusammensetzung zu vervollständigen.
Während das wirkliche Worst-Case-Szenario immer ist:
Basierend auf der statistischen Wahrscheinlichkeit haben Sie eine 90%ige Chance, in Ihrem nächsten Sprint mindestens fünf Story Points zu erledigen. Sie müssen Ihre Wahrscheinlichkeiten für jeden Sprint neu berechnen, aber für Prognosezwecke sind sechs Sprints angesichts Ihrer Daten eine angemessene äußere Grenze.
Wie hoch ist die Geschwindigkeit des Teams?
Das Team hat noch keine stabile Geschwindigkeit erreicht. Ich würde nicht unbedingt die genaue Anzahl der erreichten Story Points erwarten, aber eine Variation von 10-15 Story Points zwischen den einzelnen Sprints scheint übertrieben. Obwohl dies von den verwendeten Story-Point-Werten abhängen kann, bin ich am besten mit der Verwendung eines Satzes von 1-3-5-8-13-20-40 vertraut, bei dem Storys mit einer Größe von 20 oder 40 neu bewertet werden müssen, um zu sehen, ob sie es sind kann nicht in kleinere Geschichten zerlegt werden, die auch einen Mehrwert für die Stakeholder darstellen.
Wie viele Story Points werden voraussichtlich von diesem Team in Sprint 7 erreicht?
Ich würde ungefähr 10-15 Story Points einplanen, die im Sprint erreicht werden. Dies basiert auf der Anleitung, dass Sie den letzten abgeschlossenen Sprint als Bezugspunkt für die Planung des nächsten Sprints verwenden. Sobald Sie eine stabile Geschwindigkeit erreicht haben, würden Sie wahrscheinlich jeden Sprint, Sprint für Sprint, nahezu die gleiche Anzahl von Punkten absolvieren.
Nun, wenn a eine Tabelle wie unten hat und das Product Backlog darstellt. Welche Geschichten würden Sie für Sprint 7 auswählen und warum?
Mein erster Vorschlag an das Team wäre, die Geschichten 1-4 für insgesamt 12 Story Points einzubringen. Es ist etwas mehr als in Sprint 6 abgeschlossen, aber die meisten Sprints erreichten mehr als 10 (nur 2 nicht). Wenn das Product Backlog entsprechend priorisiert wurde, stellen diese auch die wertschöpfendsten Stories für die Stakeholder dar.
Ohne vollständig zu verstehen, warum die Geschwindigkeit des Teams in Sprint 2 und 6 niedrig war, ist es nicht möglich, über die einfache Mathematik hinauszugehen, um festzustellen, warum das Team niedrig war. Es berücksichtigt auch keine Kapazitätsänderungen - Urlaub, Krankheit, Teammitglieder, die andere Arbeiten unterstützen usw.
Und wie viele Sprints sind basierend auf den obigen Daten erforderlich, um das Projekt abzuschließen?
Versuchen Sie am besten nicht, diese Frage zu beantworten, es sei denn, Sie müssen es tun. Der ganze Sinn der agilen Methoden besteht darin, die inkrementelle Bereitstellung von Software zu unterstützen, bis die das Projekt finanzierenden Stakeholder entscheiden, dass die im Rückstand verbleibenden Funktionen die Kosten für eine oder mehrere Iterationen nicht wert sind. Es kann jedoch Fälle geben, in denen Sie versuchen müssen, eine Schätzung vorzunehmen, z. B. bei einem Vertragsvorschlag für einen langfristigen Vertrag.
Es sind noch 30 Story Points im Rückstand. Unter der Annahme, dass keine Storys entfernt und keine hinzugefügt werden, und basierend auf den historischen Daten, würde ich schätzen, dass zwischen 2 und 6 Sprints erforderlich sind, um die Arbeit abzuschließen. Natürlich hängt es von Ihrem Konfidenzintervall ab. Basierend auf historischen Daten ist es unwahrscheinlich, dass das Team zwei aufeinanderfolgende Sprints mit mehr als 15 Story Points abschließt. Es ist wahrscheinlicher, dass mindestens 3 oder 4 Sprints erforderlich sind, um die verbleibende Arbeit zu erledigen.
Todd A. Jacobs
tapu74