Product Backlog: Sortierung statt Priorisierung

Das Product Backlog ist eine geordnete Liste, keine priorisierte Liste. Das sagt der Scrum Guide:

Das Product Backlog ist eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll.

Scrum Guide, 2017, Abschnitt „Product Backlog“

Was ist jedoch der Unterschied zwischen Priorisierung und Sortierung?

Priorisierung

Priorisierung ist eine Clusterung/Zusammenfassung in Wichtigkeits-Gruppen. In der Praxis gibt es oft 3 oder 5 Prioritätsstufen (Prio 1 bis 3 bzw. Prio 1 bis 5). Fragt man einen Projektleiter oder den Chef, dann ist erfahrungsgemäß natürlich alles Prio 1 oder Prio 2. Damit kommen wir zum Problem mit der Priorisierung. Womit soll man denn dann anfangen, wenn so viele Aufgaben Prio 1 sind? Und zack, ist „Prio1plus“ entstanden.

Alternativ zu einer Nummerierung gibt es die MoSCoW-Priorisierung

MoSCoW ist ein Akronym und steht für:
M – Must have (unbedingt erforderlich)
S – Should have (sollte umgesetzt werden, wenn alle Must-Anforderungen trotzdem erfüllt werden können)
C – Could have (kann umgesetzt werden, wenn die Erfüllung von höherwertigen Anforderungen nicht beeinträchtigt wird)
W – Won’t have (wird diesmal nicht umgesetzt, ist aber für die Zukunft vorgemerkt).

https://de.wikipedia.org/wiki/MoSCoW-Priorisierung

Auch hier gibt es bei „Must have“ viele Einzelthemen, die untereinander geordnet werden müssten.

Die Priorisierung eines Backlog-Items kann durch das Item selbst und unabhängig von den anderen Themen festgelegt werden.

Sortierung

Bei der Sortierung, werden alle Backlog-Items „einfach“ untereinander geordnet. Es gibt keine 2 Elemente, die nebeneinander stehen. Sind zwei Items gleich wichtig, dann muss trotzdem eine Entscheidung getroffen werden, welches Item oben und welches unten steht.

Die Sortierung eines Backlog-Items kann somit nur im Vergleich zu anderen Backlog-Items erfolgen.

Ganz oben steht das wichtigste Backlog-Item, das als nächstes bearbeitet werden sollte. Ganz unten steht das (für diesen Moment) unwichtigste Item.

Die Priorität des jeweiligen Backlog-Items kann eine Hilfe für die Sortierung innerhalb des Backlogs sein. Es können aber auch weitere Parameter in die Entscheidung der Reihenfolge einfließen (Mehrwert, betriebswirtschaftliche Kennzahlen usw.)

Best Practise: Backlog = hohe Priorität

Im Übrigen sollte (als Best Practise!) das Backlog nur mit wichtigen (hohe Priorität!) Themen befüllt sein. Ein Backlog sollte überschaubar bleiben und im besten Fall kein Themenspeicher für Themen sein, die in weiter Zukunft („vielleicht irgendwann wenn Zeit ist“) liegen.

Vorteil der Sortierung statt Priorisierung

Bestand das Backlog zu Beginn aus Backlog-Items der Prio 1 bis PrioX und wurden in der Zwischenzeit alle Prio 1 Items „abgearbeitet“, dann würden die Prio 2 Items zu Prio 1 Items werden, weil sie nun am wichtigsten sind (und die Prioritäten der anderen Backlog-Items müssten neu ermittelt werden). Das gesamte Backlog müsste also neu priorisiert werden.

Bei einer Sortierung ist das nicht notwendig. Wird das Backlog sortiert (oben=wichtigste Items, unten = unwichtigste Items) und das Backlog Sprint für Sprint „von oben abgearbeitet“, dann wird es immer wieder eine neue „Spitze“ der Wichtigkeit geben. Kommt ein neues Backlog-Item hinzu, dann wird dieses Item in die bestehende Liste einsortiert. Es ist echt einfach.

Umsetzung in JIRA

Schaut man sich das Thema Priorisierung und Sortierung im System JIRA an, dann wird man sehen, dass die Backlog-Sortierung sehr einfach und individuell (durch Drag&Drop) erfolgen kann. Die Priorisierung des Backlog-Items, die in dem Item einzeln festgelegt wird, hat keinen Einfluss darauf. Backlog-Items mit einer niedrigeren Priorisierung können ohne Probleme vor Backlog-Items mit einer hohen Priorität sortiert werden. Das ist kein Widerspruch und kein Fehler.