SMART Ziele in Scrum

Die Empfehlung Ziele ‚SMART‘ zu formulieren finden wir überall in der Literatur. Die SMART Kriterien gelten als der Gold-Standard für gute Zielformulierungen. Und jetzt kommen wir in Scrum mit User Stories daher. Wo bleibt da SMART? 

Was sind SMART Ziele

SMART ist ein Akronym, das für fünf gute Kriterien steht, die wir an wirksame Ziele stellen.

• S: Spezifisch
• M: Messbar
• A: Akzeptiert
• R: Realistisch
• T: Terminiert

Diese fünf Kriterien sind sinnvoll, damit Ziele in der Praxis wirksam sein können – und nicht reine Worthülsen sind oder im Abstrakten verbleiben. Ein negatives Beispiel für eine Formulierung, die nicht diesen Kriterien entspricht, ist „Wir steigern unseren Umsatz“. Positiv wäre: „‘Wir steigern unseren Umsatz um 5% bis Jahresende.‘ Gezeichnet: das Sales Team.“ Die konsequente Anwendung von „SMART“ ergibt klare, mess- und überprüfbare Ziele.

Wo sind SMART Ziele in Scrum?

Auch in Scrum sind Ziele SMART – nur ist das erst auf den zweiten Blick ersichtlich. Hier beschreiben wir, wie die SMART Kriterien bei Scrum umgesetzt werden.

Spezifisch

Damit Ziele klar und verständlich sind, nutzen wir in Scrum die User Story Technik. Kurz zur Erinnerung: als „User Story“ bezeichnen wir Sätze, die in der folgenden Form formuliert sind: „Als <Nutznießer> möchte ich <Ziel> damit <Nutzen>.“ Ziele sind in Scrum die Einträge im Product Backlog. Diese Form der Formulierung führt dazu, dass wir nicht nur das Ziel selbst, sondern auch dessen Nutzen und dessen Nutznießer adressieren und damit präziser werden.

Also: „Spezifisch“ wird durch die User Story Technik adressiert.

Messbar

Den messbaren Teil eines Ziels nennen wir in Scrum Akzeptanzkriterien. Diese schreiben wir typischerweise auf die Rückseite der Karte, auf der das Ziel bzw. die User Story steht. Tauchen Akzeptanzkriterien wiederholt auf und beziehen sich auf alle oder die meisten Product Backlog Einträge, dann schreiben wir diese in die Definition von Fertig (Definition of Done).

Also: „Messbar“ wird durch die Akzeptanzkriterien und die Definition von ‚Fertig‘ adressiert.

Akzeptiert

Akzeptanz wird bei Scrum gleich mehrfach adressiert – weil es so wichtig ist. Zum einen wird das Product Backlog gemeinsam vom Product Owner und dem Umsetzungsteam erstellt – um eine gemeinsame Akzeptanz der Einträge zu Erreichen. Zum anderen zieht das Team eigenverantwortlich und nach eigenem Ermessen die Product Backlog Einträge in den Sprint.

Also: „Akzeptiert“ wird durch ein gemeinsames Product Backlog Refinement und durch das eigenverantwortliche Ziehen von Product Backlog Einträgen in den Sprint adressiert.

Realistisch

Beim Ziehen in den Sprint prüft das Team, ob der Product Backlog Eintrag realistisch in der Sprint Länge erreichbar ist. Durch das Zerlegen in Aufgaben („Tasks“) prüft das Team dies zusätzlich. Weniger offensichtlich ist die Prüfung im Product Backlog Refinement. Durch die gemeinsame Diskussion wird vermieden, dass nicht erreichbare Ziele ins Product Backlog überhaupt erst aufgenommen werden. Durch das ständige Inspizieren und Anpassen wird zudem der Punkt „realistisch“ andauernd neu in Bezug zum bisher Erreichten überprüft.

Also: „Realistisch“ wird durch das Ziehen in den Sprint und durch die Zerlegung in Aufgaben adressiert.

Terminiert

Eine häufige Kritik an Scrum ist, dass Product Backlog Einträge nicht terminiert sind. Nichts könnte ferner von der Wahrheit sein. Die Terminierung erfolgt an mehreren Stellen. Sie unterliegt zudem einem kontinuierlichen Inspizieren und Anpassen, um die Qualität der Terminprognosen kontinuierlich zu verbessern. Die Terminierung von Product Backlog Einträgen erfolgt zum einen dadurch, dass ein Product Backlog Eintrag in den Sprint gezogen wird. Damit wird ausgedrückt, dass der Eintrag spätestens zum Sprintende geliefert werden soll. Zum anderen werden die Schätzung und die gemessene Geschwindigkeit („Velocity“) zu einer Termin-Prognose zusammengeführt. Mit der Formel „Summe der Story Points bis zum Eintrag XYZ – geteilt durch die durchschnittliche Geschwindigkeit“ kann für jeden Eintrag XYZ eine Terminprognose abgegeben werden. Im Gegensatz zu einem Wunschdenken beruht diese Schätzung auf einer erhobenen Datenbasis – und verbessert sich so kontinuierlich mit mehr Sprints und Daten.

Also: „Terminiert“ wird kurzfristig durch das Ziehen in einen Sprint und langfristig durch Zeitprognosen auf der Basis von Story Points und gemessener Geschwindigkeit adressiert.

Fazit

Auch Ziele in Scrum sind SMART. In der Kombination mit Timeboxen und einem Inspizieren-und-Anpassen wird es sogar besonders effektiv.