Sprint-Planung: Forecasting vs. Commitment

Ich bin auf eine interessante Diskussion zum obigen Thema gestoßen:

Im Sommer 2011 haben Ken Schwaber und Jeff Sutherland ihren  Scrum Guide überarbeitet . Darin entfernten sie ein seit langem etabliertes Verhalten, das Scrum bekannt ist, nämlich die Verpflichtung, die das Team gegenüber dem Product Owner und den Kunden eingeht. Commitment wurde durch  Forecast ersetzt . Sie sagen, dass Teams ihre Arbeit prognostizieren können, sich aber nicht dazu verpflichten.

Der Autor – Mitch Lacey formulierte  seine Meinung,  die ich dem Artikel entnommen habe, wie folgt:

Obwohl ich ihre Logik verstehe, bevorzuge ich Engagement aus den folgenden Gründen:

• Sich zu etwas zu verpflichten, versetzt das Team in eine andere Denkweise als nur Prognosen. Wenn ein Team Prognosen erstellt, wird impliziert, dass es ein akzeptables Verhalten ist, nicht alles zu erfüllen, was es tun könnte. Während Teams aus ihren Prognosen lernen können und schließlich eine geringere  Schätzungsvarianz  haben, finde ich, dass Teams, die  prognostizieren  , länger brauchen, um die Varianz zu reduzieren, als Teams, die sich  verpflichten .
• Prognosen oder Schätzungen sind für das  Product Backlog angemessen . Wenn Teams jedoch Storys aus dem Product Backlog in das  Sprint Backlog verschieben  und sie aufschlüsseln, fügen sie eine weitere Ebene der Granularität hinzu und finden kleine Details heraus, die es ihnen ermöglichen, sich zu fragen: „ Können wir uns dazu verpflichten? „Bei Prognosen besteht die Gefahr, dass das Team in einen faulen Zustand zurückfällt, anstatt zu sagen: „Wir müssen nur prognostizieren, es ist in Ordnung, wenn wir einige Dinge verpassen, wir können das alles später herausfinden.“

Was  sagt Scrum.org  zu „Forecast“ oder „Commitment“?

Es gibt einen unmittelbaren Grund für die Änderung, der mit der Bedeutung der Wörter selbst zu tun hat. Das Wort Verpflichtung bezieht sich normalerweise auf übernommene Pflichten. Nachdem sich das Scrum Team , vor allem der Product Owner und insbesondere die Stakeholder verpflichtet haben, eine Liste von Product Backlog Items zu liefern,  fühlen sie sich möglicherweise verpflichtet, alle am Ende des Sprints tatsächlich zu liefern. Doch die Realität zeigt uns immer wieder, dass es schwierig, wenn nicht gar unmöglich ist, diese Selbstverpflichtung immer ohne Qualitätseinbußen zu erfüllen. Ein  Sprint-Backlog ist so komplex, dass immer Ungewissheit vorhanden ist, und der gesunde Menschenverstand sagt uns, dass wir nichts versprechen sollten, von dem wir nicht sicher sind, dass wir es halten können. Wenn wir das Wort Commit verwenden, können wir leicht zu dieser Pflicht-Pflicht-Versprechen-Denkweise neigen.

Meine persönliche Meinung:

Ich denke, beide Seiten haben die vernünftige Begründung dahinter. Was sind Ihre Kommentare und Meinungen?