Wie sollte der Product Owner das Backlog priorisieren?

Es gibt viele Möglichkeiten, den Rückstand zu priorisieren.

Erstens ist der Kunde nicht immer der Product Owner – der Product Owner kann eine Reihe von Stakeholdern vertreten, darunter mehrere Kunden, oder Personen mit einer längerfristigen Perspektive. Der Product Owner muss wirklich alle Bedürfnisse verstehen und die beste Methode zur Priorisierung finden.

Also sollte in erster Linie die erste Regel lauten: Tue zuerst das Wichtigste/die größte Wirkung. Da es in Wirklichkeit immer zu viel zu tun gibt, stelle ich die goldene Frage: „Muss das wirklich passieren oder kann es warten?“. Stellen Sie sicher, dass jede Anforderung ein echtes Ziel hat – lassen Sie sich nicht täuschen, dass etwas wichtig ist, wenn es nicht gerechtfertigt werden kann.

Als nächstes denken Sie über das Risiko nach – stellen Sie sicher, dass Sie ein ausgewogenes Portfolio an Artikeln haben – Dinge, von denen Sie wissen, dass sie ein geringes Risiko darstellen und daher erledigt werden, plus ein paar risikoreiche Artikel (die wahrscheinlich zu den wichtigsten gehören), die Sie haben erledigen wollen. Aus offensichtlichen Gründen (Risiko wird definiert als Dinge, die Unbekanntes/technische oder logistische Herausforderungen beinhalten) keine Veröffentlichung voller risikoreicher Elemente haben.

Schließlich können Sie beispielsweise den Wert oder die Auswirkungen der Arbeit quantifizieren. Es gibt einige gute Bücher über Agile Estimating and Planning – siehe Teil 3 von Mike Cohns Buch über Wünschbarkeitsplanung http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning

Es gibt keine universelle Methode zur Priorisierung von Backlogs. Viel hängt von der Arbeitsweise des Teams und vom Kunden ab, z. B. wie oft er Anforderungen ändert.

Je näher Sie dem Standardmodell (nach Vorschrift) folgen, desto näher kommen Sie im Allgemeinen der folgenden Lösung:

1. Zu Beginn des Projekts erfolgt eine allgemeine Priorisierung von grobkörnigen Features. Oft wird im Gespräch mit dem Kunden besprochen, welche Features Must-haves und welche Nice-to-haves sind. Dies sollte nach Möglichkeit mit dem Kunden erfolgen. Sonst würden Sie raten, was wirklich wichtig ist und was nicht.

2. Dann sollte vor jedem Sprint der verbleibende Rückstand auf feinkörniger Ebene priorisiert werden. Es spielt keine Rolle, ob PO es kurz vor dem Sprint oder während des vorherigen schafft. Wichtig ist, dass das Team seine Prioritäten für die nächste Iteration kennt. Idealerweise wird diese Priorisierung mit dem Kunden durchgeführt, aber wenn der allgemeine Plan vom Kunden genehmigt wird und sich nicht viel ändert, kann der Product Owner auf der Grundlage seines Wissens eigene Anrufe tätigen.

Wenn Sie in einer Umgebung arbeiten, in der sich die Anforderungen sehr schnell ändern, können Sie eine ständige Neupriorisierung in Betracht ziehen, was im Grunde passiert, wenn Sie mit dem Kanban-Rückstand umgehen. In diesem Fall priorisiert PO Funktionen jedes Mal, wenn sich etwas ändert.

Der Product Owner und der Kunde sollten dieselbe Person sein. Der Projektmanager sollte die Person sein, die die Details durchgeht, die Ressourcenzuweisung ausarbeitet und den Fortschritt verfolgt (unter Verwendung aller verfügbaren Tools). Der Product Owner ist die Person, die dafür verantwortlich ist, a.) auf hoher Ebene zu beschreiben, was die Anforderungen sind, und b.) die Liste der Features, die sich aus der Anforderungsliste ergeben, zu priorisieren.

In der Regel wird eine Liste von Funktionen (/Anforderungen) vom Team auf hoher Ebene festgelegt, wodurch jeder einen Überblick darüber erhält, wie teuer (zeitlich / $$$) eine bestimmte Funktion ist. Dies ist wichtig, wenn der PO die Entwicklung priorisieren soll (wenn etwas sehr kostspielig zu entwickeln ist, kann es auf der Prioritätenliste nach unten geschoben werden).

Wenn Features ganz oben auf der Prioritätenliste stehen, werden sie immer detaillierter aufgeschlüsselt, bis zu dem Zeitpunkt, an dem ein Sprint beginnt, jedes Feature auf Aufgabenebene von der für seine Lieferung verantwortlichen Person (d. h. einem Entwickler und nicht) beschrieben und geschätzt wird ein Projektleiter).

Wir verwenden Fogbugz und durchlaufen einen Prozess, bei dem Funktionen in Aufgaben zerlegt werden, die dann geschätzt werden. Der Rückstand wird dann nach Funktion (nicht Aufgabe) priorisiert, und die Schätzung für jede Funktion ist die Summe aller Schätzungen der untergeordneten Aufgaben.

Die Priorisierung sollte ein kontinuierlicher Prozess sein, obwohl es hilfreich ist, wenn der Fokus des Teams nicht innerhalb einer bestimmten Iteration verschoben wird.

Der Product Owner sollte den Kunden und seine besten Interessen vertreten. Wenn Sie den Kunden auch in Ihrem Team haben, großartig! Denken Sie daran, dass der Product Owner das Projekt in die Richtung lenken soll, die dem Kunden am meisten nützt, und gleichzeitig die Unternehmensinteressen (begrenzte Ressourcen, Zeit usw.)

Dies sollte idealerweise ausreichend vor dem Sprint-Planungsmeeting geschehen, damit das Team die Storys mit der höchsten Priorität aufnehmen und mit der Arbeit beginnen kann. Aus dieser Perspektive ist die Sprint-Planung nur Sache des Teams, um zu entscheiden, wie es so viele der Storys mit der höchsten Priorität wie möglich in den Sprint einfügt, und zwar in der Reihenfolge der Prioritäten.

Die anderen beiden Antworten (@pawelbrodzinski, @Hugo Rodger-Brown) stellen zwei weitere Ansätze dar – Abspaltung auf einer grobkörnigen Ebene und Abspaltung nach Merkmal. Was auch immer für Ihr Team funktioniert, sollten Sie tun. (Ich bin mit der Priorisierung nach Feature nicht einverstanden, da Sie oft „gerade genug“ von mehr als einem Feature in einem einzigen Sprint erledigen möchten.)