Das Entwicklungsteam schätzt die Backlog Einträge und verpflichtet sich auf die Umsetzung einer bestimmten Menge an Einträgen.
Nach einigen Sprints, pendelt sich die schaffbare Menge ein. Das ermöglicht eine Release Planung. Der Product Owner ist in der Lage eine gute Schätzung zu erstellen, was wann fertig sein könnte.
Störungen von außen reduzieren die Produktivität des Teams. Eine richtige Vorhersage über die erreichbaren Teilprodukt-Ziele ist nicht mehr möglich. Das Team wird unruhig und kann sich nicht mehr auf die vorgestellten Einträge verlassen. Es wird anfangen einen Puffer in der Planung einzubauen.
Items die von außen, also nicht vom Scrum Team selbst kommen, stören die Planung des Product Owners. Er wird gehindert den geplanten Nutzen des Produktes zu erreichen.
Da der Product Owner die Planung im Blick hat, sollten neue Anfragen an das Produkt nur über den Product Owner in das Product Backlog einfließen. Er muss über neue Anforderungen informiert sein. Eventuell müssen dadurch anderen Backlog Einträge erheblich angepasst werden.
Um eine hohe Produktivität des Entwicklungsteams zu gewährleisten, plant das Team auch selbst die Umsetzung der Sprint Backlog Items.
Ein Sprint Backlog Item, dass später im Sprint eingeworfen wird, könnte die Erreichung des aktuellen Sprintziels (Sprint Goal) gefährden und auch eine erneute Planung erfordern. Diese erneute Planung kostet entsprechend Zeit und verhindert eventuell die Umsetzung von anderen Items aus dem Sprint Backlog.
Der Product Owner priorisiert seine Product Backlog Einträge nach dem höchsten Produktnutzen. Dieser Reihenfolge entlang werden Items für den Sprint ausgewählt.
Keine Anpassung oder Änderung sollte das Sprintziel gefährden. Es dürfen keine Änderungen am Sprint Backlog dem Development Team aufgedrückt werden. Es dürfen keine Änderungen am Product Backlog dem Product Owner aufgedrückt werden. Diese entscheiden jeweils selbst.
Eine Einmischung von außen untergräbt das Vertrauen in den Product Owner.
Die Stärke von Scrum beruht, neben dem Timeboxing auch auf Vertrauen. Das Vertrauen ist für alle Rollen wichtig. Wenn das Entwicklungsteam nicht darauf vertrauen kann, ob die ausgewählten Items nun richtig sind, wird es in der Umsetzung gehemmt.
Unnötige Rückfragen, am Product Owner vorbei verzögern, und andere zwischenmenschliche Probleme können das gesamte Produkt gefährden. Das Team gerät in Gefahr sich zu destabilisieren.