Eine → Time-Box von 30 aufeinanderfolgenden Kalendertagen im klassischen → Scrum. Inzwischen haben viele → ScrumMasters die Erfahrung gemacht, daß in vielen Projekten kürzere Sprints von zwei Wochen oder sogar einer Woche besser geeignet für die Problemdomäne bzw. die Organisation des Kunden sind. (Die Wahl der richtigen Sprint-Länge ist ein Thema für sich und würde den Rahmen dieses Glossars sprengen.)
Innerhalb eines Sprints tut das → Team alles, um sein Versprechen einzulösen, die im → Sprint Planning Meeting ausgewählte Menge von → Requirements in ein → Increment of Potentially Shippable Functionality zu transformieren und somit das → Sprint Goal zu erreichen.
Während eines Sprints gibt es keine neuen oder geänderten Anforderungen von außen – der → Product Owner und alle anderen → Stakeholders sowie insbesondere die → Chickens lassen das Team in Ruhe arbeiten. (Der ScrumMaster hat dafür Sorge zu tragen, daß diese Regel auch eingehalten wird.)
Während eines Sprints gibt es keine neuen oder geänderten Anforderungen von außen – der → Product Owner und alle anderen → Stakeholders sowie insbesondere die → Chickens lassen das Team in Ruhe arbeiten. (Der ScrumMaster hat dafür Sorge zu tragen, daß diese Regel auch eingehalten wird.)
Was der Product Owner während des Sprints sehr wohl darf, ist, den Product Backlog im Hinblick auf zukünftige Sprints zu verändern, also Requirements in Form von → Product Backlog Items neu in die Liste aufzunehmen oder Einträge zu streichen sowie Prioritäten und somit die Reihenfolge der Einträge zu verändern.
| < Zurück | Weiter > |
|---|