Ein Sprintziel, das ihr erfinden müsst, ist keins

Einige von euch wissen es: Vor längerer Zeit habe ich mit meinem Team fünf Jahre lang Scrum gemacht. Meine Rolle im Team: PO. Da wir Projekte für verschiedene Kunden machen, war eine Sache immer schwierig: das ominöse Sprintziel. Wie legt man das fest, wenn in einem Sprint Galerie, Job-Liste V2 und DAM-Anbindung gemacht wird? (Kleiner Hint: einer der Gründe, warum wir damals zurück zu Kanban sind, dazu unten mehr).

Wenn du das kennst, habt ihr kein Sprintziel-Problem. Ihr habt Arbeit, die nicht in Sprints passt. Ein Sprintziel, das nach dem Planning aus der Story-Liste zusammengereimt wird, ist Theater. Das Theater kostet alle zwei Wochen eine Stunde Diskussion, und am Ende steht ein Satz, den im Daily niemand mehr erwähnt.

Was ein Sprintziel ist

Der Scrum Guide ist hier kurz. Ein Ziel, Singular. Ein Satz, der sagt, warum dieser Sprint für den Kunden wertvoll ist. Er entsteht im Planning, bevor ihr die erste Story zieht, und die Stories folgen dann erst aus dem Ziel, nicht umgekehrt.

Das ist der ganze Trick. Erst der Satz, dann die Liste. Wer die Liste zuerst hat, bekommt daraus keinen Satz mehr, der etwas aussagt.

Hier drei Symptome, dass euer Ziel keins ist.

Es wird nach dem Planning geschrieben. Die Stories stehen schon im Sprint, und jemand füllt das Feld in Jira aus, weil es leer so schlecht aussieht und im Review jemand fragen könnte.

Es heißt „alle Stories fertig“ oder eine Variante davon: „Sprint 42 liefern“, „die geplanten Themen umsetzen“. Das ist kein Ziel. Das ist der Scope mit anderem Namen.

Im Daily erwähnt es niemand. Der Guide sagt, das Daily prüft den Fortschritt zum Ziel. Wenn zwei Wochen lang keiner das Wort sagt, gibt es keins.

Eins davon reicht wahrscheinlich schon.

Warum das bei gemischter Arbeit nicht geht

Nimm den Sprint von oben: Galerie, Job-Liste V2, DAM-Anbindung. Drei Vorgänge, drei Kunden, drei Zwecke. Der ehrliche Satz dazu hat zwei „und“ drin. Ein Satz mit zwei „und“ gibt niemandem Orientierung, wenn am Mittwoch etwas Ungeplantes reinkommt und jemand entscheiden muss, was liegen bleibt.

Genau dafür wäre das Ziel da. Es soll entscheiden, was im Konfliktfall liegen bleibt. In der Praxis entscheidet das der PO in zwei Minuten: blockierte Story raus, andere rein. Dafür braucht niemand einen Satz, über den im Planning eine Stunde diskutiert wurde.

Ich habe das fünf Jahre lang gemacht, als zertifizierter PO mit zertifiziertem Scrum Master. Wir haben Kapazität für Ungeplantes reserviert, und der Prozentsatz hat nie gepasst. Wir haben Ziele formuliert, die am Ende „alles fertig“ bedeuteten. Irgendwann haben wir aufgehört, das Scrum zu nennen. Warum, steht in Kanban vs. Scrum.

Mike Cohn schreibt inzwischen selbst, dass das Sprintziel bei Arbeit für mehrere Kunden oft nicht klappt, und rät dann: weglassen. Was er nicht sagt: Ein Sprint ohne Ziel ist kein Sprint. Er ist ein Kalender mit zwei Wochen Rhythmus.

Zwei ehrliche Wege

Erster Weg: Der Sprint bekommt ein Ziel, und der Rest heißt Rest. Ihr sucht die eine Sache, die in zwei Wochen beim Kunden anders sein soll. „Die Galerie ist am Freitag beim Kunden live.“ Daraus kommen drei Stories. Job-Liste und DAM-Anbindung laufen als Kapazität nebenher und stehen nicht im Ziel. Das ist erlaubt. Der Guide verlangt ein Ziel, keinen Sprint, in dem jede Story dem Ziel dient. Wichtig ist nur: Im Konfliktfall gewinnt das Ziel, und das wissen alle vorher.

Zweiter Weg: Der Sprint fällt weg. Wenn es die eine Sache nicht gibt, weil jede Woche drei Kunden gleich wichtig sind, ist Scrum das falsche Werkzeug. Ihr macht Kanban, mit WIP-Limit und einem Ziel je Vorgang: Was ist beim Kunden anders, wenn das Ticket durch ist? Das steht im Ticket selbst, nicht in einem Feld, das alle zwei Wochen neu erfunden wird und das nach dem Planning niemand mehr aufmacht.

Was ihr nicht tun solltet: Planning, Daily, Review, Rollen und Schätzungen behalten, nur Sprint und Ziel streichen, und das Ganze Kanban nennen. Marco von SCRUMschau hat das in NBA25 auf den Punkt gebracht. Dann nennt es Scrum Light und sagt dazu, welche zwei, drei Dinge ihr bewusst weglasst und warum. Weglassen ist in Ordnung. Nicht sagen, dass man weglässt, ist das Theater.

Nächstes Planning

Schreibt das Ziel, bevor ihr die erste Story zieht. Ein Satz, ohne „und“, mit dem Kunden drin. Habt ihr den Satz in zehn Minuten, nehmt Weg eins. Habt ihr nach zehn Minuten drei Sätze auf dem Board, mögt keinen davon und merkt, dass jeder ein anderes Kundenprojekt meint, habt ihr eure Antwort. Dann nehmt Weg zwei und sagt es laut.

Feedback oder Widerspruch? Schreib mir auf Mastodon an @nobsagile oder per Mail an nobsagile@gmail.com.