Gedanken eines frisch gebackenen Product Owners

Wahrscheinlich ist es meine Verantwortung für den ROI, die mich immer wieder dazu verleitet, die Priorisierung einzig und allein vom Wert der User Story in Euro und Cent, also dem originären Business Value ableiten zu wollen. Doch der Versuch, einen absoluten Wert hinter die Story zu schreiben, den der Kunde im Endeffekt sicher bezahlen wird, lässt mir eher graue Haare wachsen als ein priorisiertes Backlog gedeihen.Denn machen wir uns doch nichts vor: Das, was ich hier im Backlog formuliere, sind Hypothesen. Wenn der Kunde noch nichtmal weiß, dass er das bald unbedingt haben will, weiß er doch auch heute noch nicht, wie viel er dafür zu bezahlen bereit sein wird. Ok, das Risiko bleibt also mal wieder an mir hängen. Ich muss mir sicher sein, dass meine Hypothese so gut ist, dass es sich lohnt, die Jungs und Mädels ein paar Tage dran zu setzen.Auf der anderen Seite: Zu den Zeiten, in denen mir der Kunde vorgegeben hat, was er als Nächstes haben möchte und auch gleichzeitig den Preis mitgeliefert hat, möchte ich auch nicht zurück. Ok, also erstmal keine Euros ... aber wie komme ich dann zu meiner Priorisierung? Irgendjemand hat mir mal gesagt, dass Scrum viel mit Menschenverstand zu tun hat ... also ...Bauchgefühl? Hm, hat zwar weniger mit Verstand zu tun, aber dafür habe ich davon eine ganze Menge :-) Aber reicht das? Ich hätte da lieber was, mit dem ich die Komplexität zumindest scheinbar etwas greifbarer machen kann.Was könnte greifbarer sein als die gute alte Deadline? Verliert ein Feature seinen Wert oder wird er erheblich verringert, wenn ich es erst nach der bestimmten Deadline auf den Markt bringe? Oder schlimmer noch: Muss ich vielleicht sogar mit einer Strafe rechnen, wenn ich das Feature nicht rechtzeitig zur Verfügung stelle? Klingt nach zwei guten Kategorien.Wen muss ich denn mit dem Produkt beglücken? Gibt es Stakeholder, die ich vorrangig zufrieden stellen muss und oder kann ich einzelne Stories bestimmten Themen zuordnen, die als Gesamtpaket unterschiedlich wertvoll oder wichtig für das Produkt sind?Da wir mit Scrum auch endlich mal unsere Systeme in den Griff bekommen wollen, könnte ich mir natürlich auch genau die Stories raussuchen, die die meisten Systeme gleichzeitig anfassen. Oder die Stories, die sich erstmal mit dem zentralen Sorgenkind beschäftigen. So können wir möglichst schnell identifizieren, wo die größten Probleme liegen. Apropos Probleme - was ist eigentlich mit Risiken? Könnte in die Kategorie Systemarchitektur fallen, aber auch der auslaufende Vertrag mit dem Zulieferer könnte zu einem Risiko werden, wenn wir noch vorher die entsprechende Unabhängigkeit der Daten sicherstellen.Da fällt mir die Kooperation mit der Uni ein. Die haben bestimmte Vorlaufzeiten, damit sie die Studenten auftreiben können.Puh, was könnte noch eine Rolle spielen?Naja, wir hatten uns ja bei der Ausrichtung des Produktes damals so viele Gedanken gemacht, was es eigentlich für die Firma bringen soll. Vielleicht kann ich bewerten, wie gut das Feature dieses Ziel unterstützt? Falls mir das noch nicht reicht, könnte ich eine Kombination mit Methoden wie z. B. MuSCoW oder Kano versuchen:MuSCoW: Must - Should - Could - Won'tKano: Basis-, Leistungs-, Begeisterungs- und Zurückweisungs-Merkmale! Ok, bevor ich das alles ausprobiere, erstmal zum PO Weekly. Immerhin gibt es auch noch die Abhängigkeiten zu den anderen Teams, die Einfluss auf meine Prio nehmen könnten. Und jetzt, wo wir so viele neue Scrum-Teams haben, könnten wir doch eigentlich eine übergreifende Priorisierung vornehmen und dabei die gleichen Kriterien anwenden. Mal sehen wie die anderen es machen - bekanntlich ist es ja einfacher, wenn man ab und zu die Köpfe im Team zusammensteckt.Wir könnten im PO Team einfach mal aufschreiben, wer wie priorisiert und sehen, wo die Gemeinsamkeiten und Unterschiede sind und welchen Nutzen die einzelnen Aspekte für den jeweiligen PO haben. Macht es Sinn, dass wir die gleichen Kriterien anwenden und was verstehen wir eigentlich genau darunter? Und wahrscheinlich hat mein ScrumMaster auch noch ein paar Ideen und kann mir bei der Fülle der Möglichkeiten für die Priorisierung helfen ... Aber wahrscheinlich wird er am Ende wieder sagen: "Triff einfach eine Entscheidung!" Product Owner sein heißt Entscheidungen treffen, und die trifft man per Definition unter Unsicherheit! Man muss es trotzdem tun und vor allem dazu stehen.