Führt man kurze Iterationen mit definiertem Inhalt ein, so stößt man relativ häufig auf Widerstand oder erlebt, dass die versprochenen Inhalte nur als „fast fertig“ geliefert werden oder das der Product Owner sich bereits in der Planungssitzung nicht festlegen möchte, was genau geliefert werden soll.

Stefan Roock hat in seinem Artikel „Understanding Sprints and Timeboxes“ meiner Meinung nach sehr gut zusammengefasst weshalb kurze Iterationen mit einem definierten Inhalt so wichtig sind:

Es müssen Entscheidungen zu konkreten Fragestellungen und zu Prioritäten getroffen und eingehalten werden.

Er bezieht sich hierbei auf Tweets von Jim Highsmith:

@RonJeffries I've always said timeboxes weren't about time, but about forcing hard decisions. @alshalloway

— Jim Highsmith (@jimhighsmith) April 21, 2012

und Tobias Mayer:

Reading anti-timebox tweets. It's amusing how much disgust is aimed at a unit of time. Units of time create rhythm. Rhythm creates flow.

— Tobias Mayer (@tobiasmayer) April 21, 2012

Kurze Iterationen bedeuteten, dass im Sprint Planning der Product Owner Entscheidungen treffen muss, was genau Inhalt der Iteration sein soll. Sicherlich wird es immer eine Menge Optionen geben – aber er muss sich für die Menge an Themen entscheiden, deren Umsetzung das Entwicklungsteam auch für realistisch hält.

Ähnliches gilt für Release-Planungen. Natürlich sind hier die der Planung zugrunde liegenden Daten unschärfer – aber ein Product Owner, der an dieser Stelle schon auf Prinzip Hoffnung setzt, der ist nicht fähig zu Entscheidungen und damit wohl auch mit der Rolle des Product Owners überfordert.

Das Entwicklungsteam wiederum ist verpflichtet genau zu prüfen, was es liefern kann und dieses auch zu tun ohne hierbei die Qualität aus dem Blick zu verlieren. Hierfür wird nicht nur Umsetzungskompetenz sondern auch ein Händchen für Planung und tiefes Verständnis der Fachlichkeit benötigt.

Sätze die schon sehr oft gesagt/geschrieben wurden – und leider ebenso häufig in der Praxis  ignoriert werden.