Scrum und XP im harten Projektalltag

SO LAUFEN SPRINT-PLANUNGSMEETINGS AB | 41
� Team: “ Klar! Grund für die niedrige Entwicklungs-
Geschwindigkeit war aber, dass das Bauen von konsistenten
Testreleases zuviel Zeit in Anspruch genommen hat.”
� PO: “Ja und was heißt das jetzt?”
� Team: “Na, das heißt, dass die Entwicklungsgeschwindigkeit
weiterhin so mies bleibt, wenn wir nichts dagegen unternehmen.”
� PO: “Und weiter?”
� Team: “Unser Vorschlag ist, im kommenden Sprint 10% der Zeit
darauf zu verwenden, Dinge wie einen Server zur fortlaufenden
Release-Erstellung einzurichten, um die Integration zu
erleichtern. Das verbessert unsere Entwicklungsgeschwindigkeit
vermutlich um 20%. Und das dauerhaft! ”
� PO: “Tatsächlich!? Und warum haben wir das nicht schon früher
gemacht?! ”
� Team: “ Ähhm...weil Du das nie gefordert hast... ”
� PO: “ Ach so! Na gut, dann sollten wir es wenigstens jetzt tun! ”
Eine Alternative wäre natürlich, den Product Owner erst gar nicht vor die
Wahl zu stellen und stattdessen einen unverhandelbaren Fokus-Faktor
vorzugeben. Es gibt aber eigentlich keinen Grund, nicht erst einmal den
Konsens zu suchen.
Ist der Product Owner ein kompetenter und vernünftiger Zeitgenosse (bei
uns bisher immer), rate ich, ihn soweit möglich über alles zu informieren
und ihn die Prioritäten festlegen zu lassen. Denn, wie wir wissen, ist
Transparenz einer der Grundpfeiler von Scrum.
Bugtracker oder Product Backlog
Excel ist ein großartiges Werkzeug zur Pflege des Product Backlogs. Für
die Erfassung von Bugs ist es hingegen wenig geeignet. Aus diesem
Grund verwenden wir dafür Jira.
Wie aber beziehen wir Bugs aus Jira in das Sprint-Planungsmeeting ein?
Nur die Stories zu betrachten und Bugs zu ignorieren, ist kein Weg.
Wir haben Verschiedenes ausprobiert:
1) Der Product Owner druckt kritische Bugs aus und hängt diese im
Meeting zu den anderen Stories an die Wand. Damit trifft er
implizit die Entscheidung, wie wichtig die Behebung einzelner
Bugs im Vergleich zu anderen Stories ist.