Agile Priorisierung
Posted April 15th, 2009 by bishoph
Wie priorisiert man eigentlich richtig in einem agilen Umfeld? Auf diese Frage bekommt man eine Menge Antworten und viele sind rein theoretisch. Der oft beschriebene Ansatz ist sehr einfach: Erstelle eine priorisiertes Backlog. Der wichtigste Punkt kommt nach oben und der unwichtigste nach ganz unten. Dazwischen packe alle anderen Punkte - aber darauf das richtig priorisiert wurde. Von diesem Schritt ausgehend, ziehe einfach alle Punkte auf das Release Backlog, welches dann in den einzelnen Sprints aufgehen wird.
Das Konzept ist klar und einfach. Allerdings gibt es in vielen Projekten ein Backlog, welches weit mehr als 20 Einträge beinhaltet. Und mitunter recht viele "Stakeholder" welche eine eigene Sicht der Dinge vertreten. Und da kann es mitunter dauern bis alle Einträge priorisiert wurden und in die Reihenfolge feststeht. Hier kann es helfen ein Release in einzelne Abschnitte zu unterteilen, welche den Stakeholdern oder Abteilungen sehr nahe sind. Durch dieses "Aufbrechen" kann die Priorisierung dann sehr viel einfacher und schneller in kleinen Teams diskutiert und festgelegt werden.
Es folgt eine Variante des "Aufbrechens" in einzelne Themenbereiche:
- StrategieEs folgt eine Variante des "Aufbrechens" in einzelne Themenbereiche:
Hier haben CEO, CTO und andere Strategen Platz, die wichtigsten Punkte unterzubringen. Es passen aber auch sehr profane Dinge wie Qualität in diesen Topf, oder aber einfacherer/bessere Bedienbarkeit etc.
- Kundenanforderungen/Sales
Sales vertritt den Kunden und es gibt mit Sicherheit einige Punkte in einem Release, die schon fest zugesagt sind, oder aber (schon länger) vom Kunden gefordert werden. Diesen Topf kann man nun vortrefflich befüllen bis er voll ist. Der Product Owner nimmt mit Sicherheit gerne eine vorpriorisierte Liste entgegen und gleicht diese mit der Realität ab.
- Entwicklung
Ich sage nur: Refactoring. Die Entwickler haben eigentlich immer Baustellen, die es aufzuräumen gibt und welche (später) die Arbeit erleichtern. Dieser Topf wird gerne und oft vergessen. Gänzlich zu unrecht aus meiner Sicht.
Wenn die Themenbereiche feststehen, kann man nun prima die Themenbereiche mit Prozentpunkten versehen. Da die (Vor-)Priorisierung aus den Interessensgruppen kommt, ist das Backlog quasi abgebildet bzw. es ergibt sich (fast) automatisch. Natürlich können jetzt wieder einzelne Kriterien und Maßnahmen angewand werden und es kann eine Umpriorisierung erfolgen. Für diesen Teil gibt es gängige Methoden.
Die einzelnen Themenbereiche können (und sollten) unterschiedliche Prozentsätze bekommen, je nach Sinn und Zweck eines Releases. Bei Neuentwicklungen wird man andere Schwerpunkte setzen als bei einem Maintenance-Release. Es empfiehlt sich, etwas Platz zu lassen - denn schließlich arbeitet man ja agil. Alle o.g. Themen bekommen als Beispiel je 30% und die restlichen 10% bleiben einfach offen (und werden später mit Sicherheit gefüllt).
Hoffe das ganze ist verständlich und hilfreich. Gerne könnt ihr mir auch eure Erfahrungen oder Ansätze mitteilen. Ich freue mich über alle Rückmeldungen.
Die einzelnen Themenbereiche können (und sollten) unterschiedliche Prozentsätze bekommen, je nach Sinn und Zweck eines Releases. Bei Neuentwicklungen wird man andere Schwerpunkte setzen als bei einem Maintenance-Release. Es empfiehlt sich, etwas Platz zu lassen - denn schließlich arbeitet man ja agil. Alle o.g. Themen bekommen als Beispiel je 30% und die restlichen 10% bleiben einfach offen (und werden später mit Sicherheit gefüllt).
Hoffe das ganze ist verständlich und hilfreich. Gerne könnt ihr mir auch eure Erfahrungen oder Ansätze mitteilen. Ich freue mich über alle Rückmeldungen.