Wie oft sollte ein Scrum-Team seine Sprint-Verpflichtung erfüllen? [geschlossen]

Engagement ist ein Versprechen, und uns allen wurde beigebracht, dass Sie Ihre Versprechen halten müssen. Aber ist es realistisch, das Engagement für jeden Sprint beizubehalten? Manchmal werden Menschen krank, manchmal hat sich der technische Ansatz als falsch erwiesen und Sie müssen alles überdenken, manchmal bei weiteren Gesprächen mit dem Produktbesitzer oder den Benutzern, von denen Sie verstehen, dass die Funktion sich stark von der ursprünglich angenommenen unterscheiden sollte.

Ich weiß, dass der offizielle Scrum-Leitfaden jetzt eher das Wort "Prognose" als "Verpflichtung" verwendet, wahrscheinlich um diese Probleme anzugehen.

Meine Frage ist also, wie oft Teams in Ihren Organisationen ihr Engagement beibehalten und ob Ihnen dieser Ansatz gefällt oder Sie ihn ändern möchten.

Vielen Dank.

Es geht nicht so sehr darum, wie oft ein Team "seine Versprechen halten" soll.
Es geht eher darum zu untersuchen, warum ein Team Probleme haben würde, seine Verpflichtungen zu erfüllen.

Wenn es sich um eine göttliche Intervention handelt, spielt das keine Rolle. Wenn Sie jedoch feststellen, dass Sie häufig zum Zeichenbrett zurückkehren müssen, weil Ihr technischer Ansatz eindeutig falsch ist oder wenn die PO ihre Meinung ständig ändert oder wenn die Geschichten zu Beginn eines Sprints nicht klar genug sind, dann sind Sie es müssen untersuchen, warum.

Die Nichteinhaltung einer Sprint-Verpflichtung ist ein Symptom. Sie müssen an der Grundursache interessiert sein.

Wenn alles in Ordnung ist, ist es normal, dass die Teams ihre Scrum-Verpflichtungen erfüllen. Sie sollten kühl genug laufen, um kleine, vernünftige und wahrscheinliche Störungen wie Tageskrankheiten, Notfälle bei der Kinderbetreuung usw. zu bewältigen, ohne dass sie sofort und automatisch ein Versagen bei der Erfüllung ihrer Sprint-Verpflichtung auslösen. Wenn dies nicht möglich ist, sind die Sprints meiner Meinung nach zu hoch und laufen zu heiß, um langfristig als Team gut zu sein.

Wenn Sprints durchweg nicht erfolgreich sind, hat Scrum sein Versprechen eingelöst, „Probleme“ sichtbar zu machen. Zu den Problemen gehören möglicherweise nicht richtig definierte Aufgaben, unzureichende Erfahrung im Team oder eine Managementkultur, bei der ständig versucht wird, zu viel zu liefern - und daher ständig zu kurz kommt.

In beiden Fällen besteht die Lösung darin, die Grundursache zu identifizieren und zu beheben, anstatt die Entwickler stärker zu schlagen.

Teams, die ihren Verpflichtungen immer „nahe“ sind, scheitern schwerwiegender. Sie können sicher sein, dass sie nicht genügend Tests durchführen.

Ich persönlich glaube, wenn sich niemand in der Organisation um die Erfüllung Ihrer Verpflichtung kümmert, sprechen Sie nicht über eine Verpflichtung. Sie benötigen zwei Partner, um einen Deal abzuschließen und eine Verpflichtung einzugehen.

Ein Sprint-Engagement ist etwas, das Sie unter Berücksichtigung aller "normalen Variationen" einhalten sollten. Sie können meinen Blog-Beitrag über die Grundlagen der agilen Planung lesen, wenn Sie mehr darüber erfahren möchten, was ich mit grundlegenden Variationen meine. Und wie Stefan sagte , ist die Nichteinhaltung Ihrer Verpflichtung ein Symptom, nicht die Krankheit.

Nach jedem Sprint haben Sie einen Moment Zeit, um die tatsächliche Geschwindigkeit dieses Sprints zu überprüfen und Ihre "Durchschnittsgeschwindigkeit" daran anzupassen (wie im oben erwähnten Beitrag erläutert ). Wenn Ihre Geschwindigkeit weiter sinkt, Sprint für Sprint, sehen Sie Muster, die Ihnen helfen können, die eigentliche Ursache dafür zu erkennen. Dies kann zu viel ungeplante Arbeit sein (z. B. kleine dringende Aufgaben, Fehler im Code, an dem Sie arbeiten, Änderungen der Akzeptanzkriterien während des Sprints, ...). Alle diese Daten müssen nachverfolgt werden, höchstwahrscheinlich vom Scrum Master, um herauszufinden, welche Muster sich darin befinden. Dies wird dem Team helfen, während der Retrospektive Maßnahmen zu entwickeln.

Meine Perspektive ist, dass Teams keine Verpflichtung eingehen. Wahrscheinlich machen sie nicht einmal eine Prognose. Die Vorhersage wird gemacht, bevor der Sprint geplant ist - die Vorhersage ist, dass sie im Durchschnitt ihre Geschwindigkeit erreichen werden. Das bedeutet, dass sie manchmal ein paar Punkte mehr als ihre Geschwindigkeit machen, manchmal etwas weniger.

Wenn Sie regelmäßig weniger als Ihre Geschwindigkeit tun, sinkt Ihre Geschwindigkeit, um dies widerzuspiegeln. Die Prognose sinkt somit ebenfalls. Wenn Sie immer mehr Geschichten einbringen, als Ihre historische Geschwindigkeit angibt, dass Sie Sprint für Sprint ausführen können, ist dies kein Fehler bei der Ausführung, sondern ein Fehler bei der Planung. Sie kennen Ihre Geschwindigkeit, sollten also nicht mehr Punkte einbringen, als die Geschichte angibt.

Um Ihre spezielle Frage zu beantworten, hat von den drei Organisationen, in denen ich Scrum verwendet habe, nur eine die Metriken "Miss the Commit" im Laufe der Zeit verfolgt. Für dieses Unternehmen haben die Teams in etwa 85% der Fälle ihre Prognose getroffen.

Wenn Sie Ihrer Verpflichtung nicht nachkommen, sollten Sie Ihre Geschwindigkeit verringern. Wenn Sie es immer erfüllen, sollten Sie es erhöhen, bis Sie manchmal versagen.

Die Frage ist, wie schlimm Sie scheitern? Es sollte immer nah sein. Entweder du schaffst es mit ein bisschen Spiel oder du versagst nur ein bisschen. Das ist ein gesundes Ziel für jede Disziplin, Laufzeiten, Gewichtheben usw. Idealerweise sollte der durchschnittliche Arbeitsaufwand im Sprint eine Normalverteilung um Ihre Geschwindigkeit sein.

Was wichtiger ist, ist der langfristige Trend in Ihrer Geschwindigkeit. Wenn Sie jede Woche 15 Story-Punkte zu Ihrer Geschwindigkeit hinzufügen, aber nur 10 mehr erreichen als in der Woche zuvor, ist das wirklich eine schlechte Sache? An einigen Stellen betrachten sie diese "Streckenziele".