Der Product Owner und das Team bemühen sich die Kapazität optimal zu nutzen.
Zur Sprint Planung wird die mögliche Kapazität der Developers ermittelt. Diese Kapazität schränkt die Aufnahme von Backlog Items in den Sprint ein.
Jedes Backlog Item für den Sprint ist durch die Developers geschätzt worden. Dadurch kann leicht ermittelt werden wieviel Kapazität noch verfügbar ist.
Ausgewählte Backlog Items können geändert werden, wenn die Umsetzung zuviel Zeit in Anspruch nehmen würde. Die Anpassungen der Sprint Backlog Items erfolgen in der Sprint Planung.
Wenn die Developers sich bei den Backlog Items verschätzt haben und nicht alle abarbeiten kann, werden diese Items eben nicht fertig.
Dies passiert in der Regel am Anfang, bei neuen Teams und einem neuen Produkt. Wenn du Einflußfaktoren kaum abgeschätzt werden können, kann es passieren, dass man sich verschätzt.
Das Verschätzen führt in der Retrospective zur Reflektion. Damit lernen die Developers immer besser mit den formulierten Anforderungen umzugehen. So werden auch die notwendige Arbeiten in Zukunft besser geschätzt. Das Ganze ist ein Lernprozess, der auch nicht durch (konstruktiver) Kritik zerstört werden sollte.