In unserer Organisation verwenden wir Geschwindigkeit, um die Menge der möglichen Arbeit in einem Sprint vorherzusagen. Manchmal fügen wir basierend auf der durchschnittlichen Geschwindigkeit des Teams zusätzliche Funktionen hinzu, die nichts mit dem Sprint-Ziel zu tun haben, nur um mehr Wert zu schaffen, wenn die Aufgaben des Sprint-Ziels nicht ausreichen.
Manchmal konnten diese zusätzlichen Funktionen nicht abgeschlossen werden, und wir müssen den Sprint als fehlgeschlagenen Sprint beenden, weil wir die Erwartungen der Stakeholder nicht erfüllen konnten.
Ist es möglich, Stories auch in einem laufenden Sprint zu entfernen?
Indem Sie Erfolg als „ alle Dinge tun“ und nicht als „die richtigen Dinge tun“ definieren, bereitet Ihr Prozess das Team von Natur aus auf einen Misserfolg vor. Nutzen Sie stattdessen den Rahmen (insbesondere das Sprint-Ziel und die Definition of Done ), um den Wert, den das Team liefert, richtig zu messen.
Manchmal konnten diese zusätzlichen Funktionen nicht abgeschlossen werden, und wir müssen den Sprint als fehlgeschlagenen Sprint beenden, weil wir die Stakeholder-Sichtung nicht abschließen konnten.
Das ist falsch. Abgesehen von der Frage, ob Sie Arbeit in einen Sprint aufnehmen sollten, die nichts mit dem Sprint-Ziel zu tun hat, bedeutet das Nichterledigen von "zusätzlicher Arbeit" nicht, dass Sie einen gescheiterten Sprint haben.
Die Scrum-Tautologie von CodeGnome sagt:
Denken Sie immer daran, dass das Ziel eines Sprints nicht darin besteht, viele Backlog-Elemente zu erledigen. Das Ziel eines Sprints ist es, das Sprintziel zu erreichen.
Das Ignorieren der Tautologie ist ein Aspekt des 100%-Usage-Irrtums . Sich darauf zu konzentrieren, wie viel Arbeit das Team leistet, anstatt wie vorhersehbar es funktionierende Produktinkremente liefert, riecht sehr nach Framework-Implementierung.
Ein erfolgreicher Sprint ist einer, der das definierte Sprint-Ziel erfüllt und ein potenziell auslieferbares Inkrement gemäß der Definition of Done liefert. Jede andere Definition ist Selbstsabotage.
Der Abschnitt des Scrum-Leitfadens zur Scrum-Theorie erkennt nicht einmal das Konzept eines „gescheiterten Sprints“ an. Stattdessen behandelt es Prozess- oder Bereitstellungsprobleme als Inspektions- und Anpassungsmöglichkeiten. Es sagt:
Wenn ein Inspektor feststellt, dass ein oder mehrere Aspekte eines Prozesses außerhalb der akzeptablen Grenzen liegen und dass das resultierende Produkt nicht akzeptabel sein wird, muss der Prozess oder das verarbeitete Material angepasst werden. Eine Anpassung muss so bald wie möglich vorgenommen werden, um weitere Abweichungen zu minimieren.
Im Prinzip bedeutet dies, dass der einzige „Fehler“ darin besteht, Scrum-Prinzipien nicht anzuwenden, wie z. B. das Setzen eines kohärenten Sprint-Ziels, das Neuverhandeln des Umfangs mit dem Product Owner nach Bedarf oder das Abbrechen eines Sprints , wenn dies erforderlich ist.
Um Ihre Frage auf einer grundlegenden Ebene zu beantworten: Wenn Sie den Sprint-Umfang ändern möchten, während der Sprint ausgeführt wird, müssen die von Ihnen geänderten Backlog-Elemente eine entsprechende Größe haben. Wenn Sie beispielsweise dem Sprint eine 5-Punkte-Story hinzufügen müssen, können Sie eine 5-Punkte-Story aus dem Sprint entfernen. Oder Sie könnten eine 2-Punkte-Story und eine 3-Punkte-Story entfernen. Das Sprint-Engagement bleibt daher gleich – Sie leisten keine zusätzliche Arbeit.
Sie haben nicht gesagt, ob Sie dies tun oder nicht, aber entfernen Sie nichts aus dem Sprint, wenn er als in Bearbeitung markiert ist, da dies die Arbeit des Teams stören würde.
Das Erreichen des Sprintziels sollte Ihr Ziel sein. Wenn es zusätzliche Dinge gibt, die das Team tun soll, wenn es schneller als erwartet durch das Sprint-Backlog kommt, erwägen Sie, diese als Stretch Goals zu setzen. Mit dieser Methode müssen Sie sie nicht direkt zum Sprint hinzufügen und Sie müssen nichts herausnehmen. Wenn das Team den Sprint-Backlog vorzeitig abschließt, könnte es den Punkt mit der höchsten Priorität aus der Liste der Stretch Goals nehmen und in den Sprint einbringen. Es muss etwas sein, das innerhalb des Sprints abgeschlossen werden kann – seien Sie also vorsichtig, wenn Sie gegen Ende des Sprints große Elemente hinzufügen. Werden die Stretch Goals nicht erreicht, ist der Sprint nicht gescheitert. Stretch Goals sind zusätzliche Arbeit – sie sind nicht deine Sprintziele.
Das Scheitern eines Sprints kann für das Team sehr demoralisierend sein, und es scheint, als könnte es verhindert werden, wenn es aufgrund von Elementen passiert, die dem Sprint hinzugefügt wurden und sich nicht auf das Sprintziel beziehen.
Wenn Stakeholder während des Sprints nach mehr Arbeit fragen, müssen Sie nur sagen, dass die Arbeit für einen zukünftigen Sprint berücksichtigt werden kann.
Es wäre hilfreich zu wissen, was Ihre Rolle ist, wie Sie nicht gesagt haben. Das wäre aber vielleicht eine andere Frage.
Daniel
Erik
Josbel Luna