Zu Beginn jedes Sprints findet als Kick-Off das Sprint Planning Meeting statt. Es dauert einen Tag (Time-Box 8 Std.) und dient dazu, das Arbeitspaket des Scrum-Teams für den kommenden Sprint (Sprint Backlog) zu schnüren.
§Ablauf des Sprint Planning Meeting
-
Time-boxed (8 h)
-
Input: Product Backlog
-
Output: Sprint Backlog
-
Aufgeteilt in zwei weitere Time-Boxes von jeweils 4 h:
-
Der Product Owner präsentiert dem Team die Product Backlog Items mit der höchsten Priorität und benennt (optional) sein Sprint Goal, mit dem das Team einverstanden sein muß. Gemeinsam bestimmen beide Seiten, welchen Teil des Product Backlogs das Team im kommenden Sprint in ein Increment of Potentially Shippable Functionality verwandeln kann. Das Team verpflichtet sich (engl. „to commit“) auf den besprochenen Lieferumfang, welchen es soeben selbst mitbestimmt hat.
-
Das Team plant autonom (ohne Mitsprache des Product Owners) im Detail, wie es sein gegebenes Versprechen einlösen kann, indem es die betreffenden Requirements in Tasks herunterbricht und letztere zu einem Sprint Backlog konsolidiert.
Hinweise
-
Der Product Owner stellt zwar die Anforderungen, aber das Scrum-Team alleine entscheidet, wieviel von der gewünschten Funktionalität es im kommenden Sprint tatsächlich realistisch schaffen kann. Das Team kann bei differierenden Ansichten von niemandem "überstimmt" werden.
-
Jedes Team wird, wenn es auch nur im geringsten Wert auf sein Ansehen legt, versuchen, so viel wie möglich in einem Sprint zu schaffen. Meistens muß bei unerfahrenen Teams sogar der ScrumMaster das Team etwas bremsen, damit es sich nicht übernimmt. Darunter würde dann die Qualität leiden, und das Produkt-Inkrement würde seinem Anspruch, "Sashimi" bzw. potentially shippable zu sein, nicht gerecht werden.
| < Zurück | Weiter > |
|---|