Rückschau: Warum Prioritäten Quatsch sind (und was du wirklich brauchst)

Priorität ist kein Beschleuniger. Sie ist nur ein Label.

Alles ist "Prio 1"

Es gibt wichtige Tickets und es gibt nicht so wichtige Tickets. Und dann gibt es die noch wichtigeren Tickets. Und dann kommen garantiert die superwichtigen Tickets dazu. Und von denen gibt es dann drei (natürlich...). Das frustrierende daran? Allen ist eigentlich klar, dass es ganz natürlich eine Reihenfolge geben muss. Du kannst nicht drei Tickets gleichzeitig bearbeiten. Du kannst nur an einem arbeiten. 

In der Podcast Folge NBA08 "Prioritäten sind quatsch" habe ich genau darüber gesprochen. In diesem Rückblick will ich meinen Blickwinkel zu dem Thema weiten.

Priorität vs. Kapazität

Schauen wir aus etwas Entfernung auf die Situation von oben. Warum bekommen Tickets Prioritäten? Oft genug, weil jemand der Meinung ist, dass man die Aufgabe damit beschleunigen kann. Und das stimmt aus einer gewissen Perspektive auch: Wenn das System Kapazität hat, dann macht es auf jeden Fall Sinn, genauer zu schauen, welche Arbeit als nächstes angegangen wird. Doch was, wenn das System schon voll ist? Was, wenn es das dritte "Prio 1" Ticket ist? Nunja, dann haben wir nur zwei Möglichkeiten.

Bestehende Arbeit pausieren

Nicht die beste Wahl in meinen Augen. Wenn etwas in Arbeit ist, dann haben wir schon Zeit und Geld investiert. So bald wir die Arbeit daran unterbrechen und sie später wieder aufnehmen, ist das teuer. Das mag in Ausnahmesituationen trotzdem Sinn machen. Wenn es zur Routine wird, ist es aber Geldverschwendung. 

Das neue Ticket hinten anstellen

In der Regel ist das die bessere Wahl. Wir können die Arbeit, die noch nicht angefangen ist, jeder Zeit priorisieren. Und eine Umpriorisierung sollte in jedem System möglich sein. Ist das nicht der Fall, empfehle ich dir hier anzusetzen.

Die große Gefahr

Wenn wir viele Tickets haben, die alle wichtig sind, dann stimmt was in unserem System nicht. Nur weil ein Ticket eine hohe Priorität hat, schreibt sich der Code nicht schneller, denn die Kapazität deines Teams bleibt ja gleich. Zu viele hohe Prioritäten führen unweigerlich zu hohem Work-in-Progress (WIP), ständigem Kontext-Switching und am Ende zu Stillstand. Und wenn unsere Arbeit dann noch eine große Varianz (Stories haben unterschiedliche Größen) hat, wissen wir, dass alles nur noch länger dauert (wenn dich der Hintergrund dazu interessiert, schau gerne in meine Flow Physics).

Sequenzierung statt Kategorisierung

Die Lösung liegt auf der Hand und sie ist auch sehr natürlich. Wir brauchen keine Prioritäten, wir brauchen eine Sequenz. Es gibt zu jedem Zeitpunkt eine Reihenfolge der anstehenden Stories. Die kann sich ändern, das ist ok und gewollt. Sie muss aber stabil bleiben, wenn Arbeit einmal angefangen ist.

Dies bedeutet, dass der PO hier gefordert ist. Er (oder sie) muss mit den Stakeholdern permanent daran arbeiten, dass die Reihenfolge stimmt und auch Sinn macht. Das ist nicht immer einfach, aber wichtig. Tut er dies nicht, verstopft er das System in dem du lebst und findet dann als einziges Hilfsmittel das Jira DropDown "Priorität". Dass er damit einen Flow nicht beschleunigt, sondern eher nur noch mehr verstopft, wird oft ignoriert. 

Du kannst ihm helfen: Frag deinen PO nicht: "Was ist wichtiger?", sondern: "Wenn du nur eines dieser beiden Tickets morgen Abend fertig auf Produktion sehen könntest – welches wäre es?" Das zwingt zur Sequenz.

Kleine Stories

Eine Reihenfolge von Tickets, die jeweils 50 Tage groß sind, funktioniert nicht. Eine Reihenfolge von 2-Tage-Stories hingegen schon.

Wenn euer PO sich nicht entscheiden kann, was wichtiger ist, helft ihm, die Dinge so klein zu schneiden, dass die Entscheidung leicht fällt. "Wollen wir zuerst, dass der User sich einloggen kann, oder dass er sein Profilbild ändern kann?"

Um Verstopfungen in eurem System zu verhindern, ist die Größe der Arbeit wichtig. Je gleichförmiger die Größe ist, desto leichter das Handling. Indem ihr als Team gut darin seid, Arbeit so zu schneiden, dass sie Wert liefert und trotzdem ähnlich groß ist, desto leichter fließt die Arbeit durch euer System. Zum so genannten Slicing habe ich in dem Artikel Backlog Refinement Technik: Tickets schneiden wie ein Pro ein bisschen mehr geschrieben.

Und mit solchen Stories fällt es allen auch leichter, gar nicht mehr über Prioritäten sprechen zu müssen.

Und was jetzt?
Wenn ihr die Reihenfolge geklärt habt, müsst ihr dafür sorgen, dass die Arbeit auch fließt. Hier sind deine nächsten Werkzeuge:
WIP-Limits einbauen: Warum „Stop starting, start finishing“ dein Gehirn schont.
Daily Scrum für Entwickler: Wie ihr das Meeting nutzt, um die Sequenz jeden Morgen neu zu schützen.
Warum gute Entwickler keine Tickets abarbeiten: Der Deep-Dive, warum wir über Probleme reden sollten, nicht über Jira-Status.