Eine Frage zur Sprintplanung. Nehmen wir an, dass die Geschwindigkeit des Teams 20 Story Point (SP) beträgt. Die ältesten Stories im Product Backlog sind A (12 SP), B (5 SP) und C (4 SP).
Es ist leicht zu sehen, dass wir, wenn wir alle drei Aufgaben (21 SP) übernehmen, höchstwahrscheinlich Aufgabe C nicht beenden werden. Aber wenn wir nur A und B (17 SP) nehmen, werden wir den Sprint vorzeitig beenden.
Es gibt zwei mögliche Lösungen:
Es scheint, dass diese beiden Lösungen ähnlich sind. Aber meiner Meinung nach gibt es einen Unterschied. Es ist Motivation.
Erste Lösung: Es motiviert das Team, sich zu beeilen. Aber demotivieren Sie, wenn das Team nicht alle geplanten Arbeiten erledigt. Nach meiner Erfahrung kommt der zweite Fall häufiger vor.
Zweite Lösung: Ich habe gesehen, dass die Arbeit normalerweise die gesamte geplante Zeit in Anspruch nimmt. Und es hat nichts damit zu tun, wie genau wir dieser Arbeit Zeit widmen. Wenn wir also nur zwei Aufgaben im Sprint planen, werden wir diese beiden Aufgaben wahrscheinlich den ganzen Sprint erledigen.
Was sagt Scrum dazu? Welchen Weg sollten wir nutzen?
Bei Scrum geht es nicht nur darum, Stories zu vervollständigen. Es geht darum, Geschäftswert zu liefern. Sie sollten also damit beginnen, das Sprintziel zu besprechen und sich darauf zu einigen. Und dann kann das Entwicklungsteam weitere Diskussionen und Verhandlungen mit dem Product Owner führen. Beispielsweise kann das Entwicklungsteam vorschlagen, einige Schnickschnack aus einer Story zu streichen oder eine andere Story zu modifizieren – alles im Interesse des Erreichens dieses Sprint-Ziels. Aber der Product Owner trifft die letzte Entscheidung.
Danach sind Velocity, Story Points und Priorisierung ein guter Ausgangspunkt für die Dimensionierung. Denken Sie jedoch daran, dass die Geschwindigkeit keine genaue Zahl sein kann. Es kann nur ein Bereich sein - etwas wie 20 bis 25. Ihre Frage ist jedoch immer noch gültig. Drücken wir mehr aus, als das Team liefern kann, oder planen wir es sicher?
Was sagt Scrum dazu?
Scrum möchte, dass das Team am Ende des Sprints ein potenziell auslieferbares Inkrement des Produkts erstellt. Also sollte der Product Owner am Ende des Sprints, nachdem er den Sprint Review gesehen hat, die Möglichkeit haben zu sagen: „Alles klar, versende es (oder stelle es bereit)!“ Das Entwicklungsteam sollte dies also im Hinterkopf behalten und sich entsprechend verpflichten.
Sie können auch versuchen, was @CarynRose vorgeschlagen hat, und versuchen, die Geschichten in kleinere Teile aufzuteilen.
Eine Option, die ich geprüft habe: Wenn das Team in den ersten beiden Stockwerken gute Fortschritte gemacht hat, füge ich das dritte Stockwerk mitten im Sprint hinzu. Ich frage jedoch immer: "Sind Sie sicher, dass Sie es jetzt hinzufügen und vollständig fertigstellen und versandbereit sind?" Wenn es irgendwelche Bedenken gibt, werde ich es nicht hinzufügen.
Eine weitere Option: Zum Zeitpunkt der Sprint-Planung können Sie bei ausreichender Bandbreite eine Timebox-Research-Story einplanen, um das Risiko in einem Backlog-Element zu reduzieren (natürlich in Absprache mit dem Product Owner).
Brechen Sie idealerweise die größere Geschichte auf. Aber es gibt produktive Möglichkeiten, die verbleibende Zeit in einem Sprint zu nutzen. Wie wäre es mit:
Ich denke, dass eine Aufgabe mit 12 Story Points wahrscheinlich in 2 kleinere Aufgaben aufgeteilt werden könnte, sodass Sie A, B, C und D haben, was sich für eine andere Priorisierung anbieten könnte.
Dies ist das häufigste Problem bei der Projektplanung. Und die Lösung liegt in der Natur des Problems. Wenn in Ihrem Fall ein anderes Team entweder von AB oder C abhängt, wäre dies eine hohe Priorität und ein MUSS, um diesen Sprint abzuschließen. Ebenso, wenn es keine Abhängigkeit zu einem der Storypoints gibt und Sie ein funktionierendes Produkt ohne ihn ausliefern können. Es ist ideal, diesen Story Point in den nächsten Sprint zu verschieben und als Teil der Product Backlog-Elemente abzudecken.