Der Product Owner und das Team bemühen sich die Kapazität optimal zu nutzen.
Zur Sprint Planung wird die mögliche Kapazität des Development Teams ermittelt. Diese Kapazität schränkt die Aufnahme von Backlog Items in den Sprint ein.
Jedes Backlog Item für den Sprint ist durch das Development Team 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 das Development Team sich bei den Backlog Items verschätzt hat 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 lernt das Development Team 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.