5 Gründe, die Reihenfolge von Items zu ändern

Ein Product Owner gibt seinem Team 10 Story Cards (Karteikarten mit je einer User Story). Die Teammitglieder lesen sie und geben dem Product Owner die fünfte und sechste Karte wieder zurück. Am Ende des Sprints liefert das Team die Funktionalität der Karten 1, 2, 3, 4 und 7 aus. Allerdings wurde mit den Aufgaben auf den Karten 5 und 6 noch nicht begonnen.

Meines Erachtens ist das in Ordnung.

Eine standardmäßige Empfehlung bei agilen Methoden ist, dass das Team in der Reihenfolge an den Backlog Items arbeiten muss, die der Product Owner vorgibt. Auch wenn das bis zu einem gewissen Punkt sinnvoll ist, machen gute agile Teams immer wieder Ausnahmen von dieser Regel.

Es gibt viele gute Gründe für ein Team, die vorgegebene Reihenfolge nicht einzuhalten. Hier habe ich einige davon aufgelistet, die als Rechtfertigung ausreichen sollten:

1) Synergieeffekte

Oft gibt es Synergieeffekte zwischen den Items ganz oben im Product Backlog. Während ein Team z. B. an Item Nr. 3 arbeitet, sollte es auch an Item Nr. 6 arbeiten dürfen. Wenn sich zwei Items im gleichen Teil des Systems befinden und schneller zusammen erledigt werden können, sollte der Product Owner das auch erlauben.

2) Abhängigkeiten

Ein Team entscheidet vielleicht, dass Item 4 wichtiger ist als die Items 5 und 6. Leider kann an Nr. 4 jedoch erst gearbeitet werden, wenn Nr. 7 fertig gestellt ist. Eine solche Abhängigkeit reicht normalerweise aus, um es einem Team zu erlauben, von der vorgesehenen Reihenfolge abzuweichen.

3) Verfügbarkeit von Fachwissen

Ein Team würde vielleicht gerne an dem viertwichtigsten Item des Product Owners arbeiten, aber die richtige Person dafür ist leider nicht verfügbar. Natürlich kann das ein Anzeichen dafür sein, dass mehr Teammitglieder in der Lage sein sollten, funktionsübergreifend zu arbeiten – aber das ist eher eine langfristige Lösung. Eine kurzfristige Lösung wäre, einfach so lange an anderen Items zu arbeiten, bis das Teammitglied mit den benötigten Fähigkeiten wieder zur Verfügung steht.

4) Es ist interessanter

Okay, über diesen Punkt lässt sich streiten. Ich sage nicht, dass das Team an den Items Nr. 1, 2, 3, 4 und dann an Nr. 600 arbeiten sollte. Aber die Items wie in meinem Beispiel auszuwählen (1, 2, 3, 4, 7) ist in Ordnung, wenn die Arbeit auf diese Art etwas spannender wird.

In manchen Projekten stoßen Teams gelegentlich auf eine ganze Reihe von Product Backlog Items, die nicht wirklich viel Spaß machen. Wenn ein Team ab und zu ein Item vorziehen kann, das etwas Abwechslung bietet, kann sich das positiv auf die Moral der Teammitglieder auswirken. Und das ist wiederum gut für den Product Owner.

Bonus: 4.1.) Es ist interessanter für Stakeholder

Wenn wir schon beim Thema sind: Ich behaupte einfach mal, dass es auch in Ordnung für ein Team ist, die Reihenfolge zu verändern, wenn bestimmte Items für die Stakeholder interessant sind.

Manchmal kann es eine ziemliche Herausforderung sein, alle wichtigen Personen dazu zu bewegen, an den Sprint Reviews teilzunehmen. Besonders schwer wird es, wenn die letzten Reviews eher langweilig waren. Grund dafür kann die hohe Priorität von bestimmten Arbeiten sein (z. B. von wichtigen Dingen, die für die Stakeholder aber nicht wirklich sichtbar sind).

In einem solchen Fall kann es klug sein, dem nächsten Sprint Review ein wenig Sexappeal zu verpassen. Wenn nämlich das Team an etwas arbeitet, was die Stakeholder interessant finden, werden diese auch eher an dem Meeting teilnehmen.

5) Größe

Falls die bisherigen Gründe Sie noch nicht überzeugt haben, habe ich mir den überzeugendsten Grund für den Schluss aufgehoben. Er beweist, dass jedes Team auch mal von der vom Product Owner vorgegebenen Reihenfolge abweichen darf: Ein Team darf beispielsweise das Item Nr. 5 überspringen, wenn es zu groß ist. Also nimmt das Team das nächste Item, das größenmäßig in den Sprint passt.

Wäre das nicht erlaubt, würde das Team nur die Items 1, 2, 3 und 4 auswählen und dann aufhören. Dann wäre eventuell ein beachtlicher Teil des Sprints unausgefüllt. Natürlich könnte das Team wenigstens einen Teil von Item 5 erledigen und dann ein anderes in Angriff nehmen. Das ist aber in vielen Fällen nicht besonders sinnvoll. Daher wird das Team zumindest ab und zu von der ursprünglichen Reihenfolge abweichen.

Product Owner sind nicht perfekt

Ein perfekter Product Owner würde das alles wissen. Ein perfekter Product Owner würde wissen, dass die ersten vier Items im Backlog schon so viel datenbankbezogene Arbeit bedeuten, dass er nicht noch ein solches Item auf Rang 5 setzt. Ein perfekter Product Owner würde wissen, dass sich die Items 2 und 5 auf die gleiche Java-Klasse beziehen und sie somit bei der Priorisierung zusammenlegen.

Den meisten Product Ownern fällt es aber schwer, perfekt zu sein. Die beste Lösung ist einfach, den Product Backlog so gut wie möglich zu priorisieren und dann dem Team den Feinschliff zu überlassen.

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.

agile100: Roger Martin

=> Im Februar 2021 sprachen wir mit Roger L. Martin über sein Buch "When more is not Better".

Agiles Arbeiten bei MAN

=> Wie agil ist MAN Truck & Bus SE und wie funktioniert die agile Arbeit in der Automobilbranche?

Certified Scrum Product Owner Training

=> Werde zertifizierter Product Owner mit der Agile Academy!