In größeren agilen Projekten kommt immer wieder die Frage auf, wie Sprintziele gewählt werden sollen. Unter einem großen Projekt verstehe ich hierbei eines, welches mit mehreren Teams gleichzeitig an einer Software arbeitet und wo es nötig geworden ist, die Gruppe der Product Owner mit einem Chief Product Owner zu hierarchisieren. Typischerweise geht das bei fünf bis acht Scrum-Teams zu je 8 bis 12 Personen los.
Das Sprintziel sollte in ein bis drei Spiegelstrichen ausgedrückt werden können (in Ausnahmen auch bis zu fünf). Formuliert werden sollten wirkliche Ziele, also was man erreichen möchte, nichts was man tun will, denn das steht ja schon in den Stories. Also: nicht „Refactoring der Datenbankschicht“ sondern „Entkopplung des Datenbankzugriffs vom Session-Parameter“ o.ä. nicht „Implementiere drei Varianten des Identity-Providers“ sondern „Umsetzung der gesetzlichen Mindestanforderungen für Identitätsprüfung“
Ein großes Projekt hat seine Zielsetzung allerdings durch ein Geschäftsziel, d.h. es gibt eine Management-Ebene, die ein Software-Projekt zur Erreichung eines gewissen Geschäftsziels eingesetzt hat. Insofern müssen die Sprintziele auch diesem Geschäftsziel zuarbeiten. Im Idealfall ist die Summe aller Sprintziele das, was man braucht, um das Geschäftsziel zu erreichen.
Die Aufgabe des Product Owners ist es nun, das Geschäftsziel über die Sprints herunter zu brechen in Sprintziele, die das Team versteht. Ein Geschäftsziel ist zu vage, um es zu operationalisieren. Stories sind zu konkret, um sie direkt auf ein Geschäftsziel zu beziehen.
Insofern sind inhaltliche Sprintziele für mich ein essentieller Bestandteil eines agilen Entwicklungsprozesses. Sie liefern konkrete Themen, an denen sich ein Team abarbeiten kann. Sie sind auch eine gute Grundlage für die täglichen Entscheidungen im Sprint. Ein Sprintziel sollte man unter keinen Umständen aufgeben. Eine Story kann man ggf. nicht umsetzen oder muss sie aufteilen.
Gute Software und Software-Architektur 