Artikel

Scrum Antipatterns: Spec Backlog

Geschrieben von Christoph Hochstrasser vor 8 Monaten

Ein Entwicklungsteam, das ich unterstützt habe, hatte ein großes E-Commerce Projekt für eine bekannte Supermarktkette an Land gezogen.

Der Kunde forderte vom Unternehmen, dass das Projekt nach Scrum durchgeführt werde, weil ihre Entwicklungsabteilung ebenfalls nach Scrum arbeite.

Also war mein Auftrag dem Team einen Crash Kurs in Scrum zu geben. Ich begleitete am Anfang die Grooming & Estimation Meetings und sah dann dort zum ersten Mal das Backlog für das Projekt.

Das Backlog

Das Backlog bestand von Anfang an aus vielen kleinen Stories, mindestens 100. Viele Stories, die keinen klaren Business Value kommunizierten, wie z.B. „Als UX Manager möchte ich…” oder „Als Product Owner möchte ich…”.

Ich stellte mir die Frage: Wie kommt man auf so ein furchtbares Backlog?

Es stellte sich heraus, dass die UIs für den Shop von einer kundeninternen Grafikabteilung geliefert wurden und nicht von jemanden aus dem Team.

Dadurch entstand eine Hand Off Situation zwischen zwei Teams, die eigentlich ein gemeinsames Cross Functional Team sein sollten. Die Grafikabteilung hat natürlich viel Zeit und Geld in die fertigen Screen Designs investiert und möchte dann nicht mehr experimentieren, sondern genau diese Designs 100% geliefert bekommen.

Dadurch hat der PO (der noch dazu nur ein Proxy PO) war, den Druck ein Backlog zu schreiben, das alle Screens genau wie vorgegeben umsetzt.

Also der PO wurde nicht am Business Value gemessen, den er/sie geschaffen hat, sondern an der Vervollständigung des Backlogs (genauso das Team).

Dadurch ergab sich ein Backlog, wo jede Story ein Acceptance Test für den Product Owner war, wo er messen konnte ob die Story den vordefinierten Screen umgesetzt hat.

Dadurch waren es kleine, nicht zusammenhängende Stories, die dem Team nie ein gesamtes Produktkonzept zeigten.

Dadurch gab es auch immer wieder Spannungen, wenn vom Team bessere Wege aufgezeigt wurden um schneller Business Value zu generieren.

Der Product Owner konnte von den Screens nicht abweichen, weil sie an der Vervollständigung des Backlogs gemessen wurde.

Was kann man hier anders machen?

  • Grafik und Design gehört in das Team. Cross Functional Teams eliminieren solche Hand Off Situationen und sparen dadurch Zeit und Geld.
  • Nicht die vollständige Abarbeitung aller Stories im Backlog ist der Erfolgsfaktor für das Projekt und die PO, sondern ob der Business Value geschaffen wurde. Sobald für den Kunden ausreichend Value geschaffen wurde sind genug Stories implementiert. Es dürfen Stories am Ende des Projekts übrig bleiben.
  • Der Product Owner muss Teil des Teams sein und gemeinsam mit dem Team eine gemeinsame Partei am Projekt stellen. Nur so kann der PO auf das Team reagieren und flexibel sein, wenn bessere Wege gefunden werden, die mit weniger Aufwand mehr Business Value erzeugen.
  • Das ist auch in der aktuellen Ausgabe des Scrum Guides genau so definiert: Scrum Team = Developer Team + Product Owner + Scrum Master