Backlogs ausmisten! (II)
Warum zu große Backlogs regelmässig ausgemistet werden sollten habe ich
bereits beschrieben, jedem Product Owner lege ich den regelmässigen Griff zur Heckenschere ans Herz. Nicht festlegen würde ich mich auf die maximale Zahl vertretbarer Backlog Items, das kann je nach Einzelfall unterschiedlich sein. Meine Faustregel ist aber, dass man sich spätestens ab dem hundertsten Eintrag Gedanken machen sollte. Konkrete Ratschläge kann ich dagegen zu etwas anderem geben, nämlich dazu nach welchen Kriterien aussortiert werden sollte. Da gibt es mehrere Möglichkeiten:
Nach Priorität
Zugegeben, ein No Brainer. Je weiter nach unten eine Anforderung priorisiert ist desto verzichtbarer ist sie, weshalb man es sich ganz einfach machen kann - weg mit den unwichtigsten 10 Prozent und das Problem ist gelöst. Aber apropos Problem: an dieser Stelle gibt es eines. Die wichtigsten Anforderungen bekommt man noch irgendwie identifiziert, aber in den meisten Backlogs folgt danach eine amorphe Masse in der alles irgendwie gleich (un)wichtig ist. Wie soll man da mit dem Sortieren weitermachen? Die häufigste Antwort darauf lautet:
Nach Business Value
Okay, noch ein No Brainer. Je geringer der erzeugte Mehrwert desto eher kann eine Anforderung weg. Benutzen wir also das als Vergleichswert und wir haben ... schon wieder Schwierigkeiten. Ein paar zentrale Faktoren für ein
funktionsfähigeses MVP oder eine
bessere Vermarktbarkeit lassen sich natürlich finden, aber dann - wieder Unklarheit. Ist die intuitive Hauptnavigation jetzt wertvoller als der einfache Bezahlvorgang oder der schnelle Login? Viel Spass beim Entscheiden. Aber es gibt ja weitere Priorisierungskriterien. Zum Beispiel:
Nach Alter
Hier werden die Ersten widersprechen. Denn ich würde sagen: je älter eine Anforderung ist desto eher kann sie weg. Das widerspricht für viele den Denkgewohnheiten, schließlich könnte man meinen, dass eine Umsetzung um so dringlicher wird je länger sie sich hinzieht. Ich sehe das umgekehrt - wenn eine Anwendung so lange Zeit ohne ein Feature funktioniert, dann kann das nicht wirklich wichtig gewesen sein. Aber das nächste Dilemma kommt bereits um die Ecke - gerade zu Beginn kippen üblichweise alle Stakeholder gleichzeitig ihre Wünsche ein, wodurch ihre Anforderungen alle ähnlich alt sind. Doch auch hier gibt es einen Ansatz für eine weitere Auswahl:
Nach Stakeholder
Ja, genau, nach Stakeholder. Es soll weitergehen, es soll mehr Zeit geben, mehr Budget, mehr Ressourcen? Dann hilft es, wenn man nett zu dem ist der das Geld in der Tasche hat. Du kriegst Dein Feature, ich meine Ressourcen, beide sind glücklich. Ein Kuhhandel? Ja, ist es. Opportunistisch? Vermutlich auch. Aber hey, so ist es nun mal in der Welt. Ein grosses Geben und Nehmen. Allerdings, selbst wenn wir das machen bleiben oft noch Anforderungen übrig bei denen man nicht sicher sein kann für wen sie mal wichtig sein könnten. Im Zweifel behalten? Ach was, auch da lässt sich noch reduzieren, und zwar so:
(Festhalten:) Nach Zufall
Wait, what? Nach Zufall. Jetzt kann man losen, Glücksrad drehen, blind mit dem Finger auf etwas zeigen oder einfach jede vierte verbliebene Anforderung löschen. Alles ist erlaubt. Aberwitzig? Mitnichten! Schauen wir nochmal auf die letzten Auswahlrunden. In denen haben wir nicht nur entschieden was nach unten priorisiert wird, wir haben damit gleichzeitig auch nach oben priorisiert, das eine gehört untrennbar zum anderen. Und was in keinem dieser Durchgänge für wichtig genug befunden wurde, das kann eigentlich nur verzichtbar sein. Und deshalb kann die Zufalls-Auswahl so lange weitergehen bis das Backlog auf eine vernünftige Größe eingedampft ist. Nur zu.
AberAber: Was, wenn irgendwas davon doch wichtig war?
Ja, was dann? Was wenn wir versehentlich etwas rausgeworfen haben was wir doch ganz dringend brauchen? Ganz einfach - sobald das auffällt kommt es als neue Anforderung wieder rein. Und wenn auf diesem Weg so lange Anforderungen wieder zurückkommen bis das Backlog erneut ausufert? Na dann geht das Ausmisten eben von vorne los.
