Was sind die verschiedenen Ansätze und wie oft wird der Rückstand priorisiert? [abgeschlossen]

Welche unterschiedlichen Aspekte eines PBIs (Product Backlog Items) oder allgemein gesprochen Merkmale würden Sie bei der Priorisierung des Backlogs berücksichtigen? Risiko, ROI, Time-to-Market, Verzögerungskosten, nach Ermessen des PO usw.

Würden Sie eine Kombination oder sogar eine gewichtete Kombination davon in Betracht ziehen, um den Rückstand zu priorisieren?

Wie oft muss die Priorisierung überprüft werden? Bei jedem Sprint? täglich? oder nach Ermessen von PO?

Wie derzeit geschrieben, ist diese Frage zu weit gefasst. Bitte verbessern Sie die Frage, indem Sie einen Kontext zu Ihrer spezifischen Situation angeben, was Sie bereits versucht haben und warum das bei Ihnen nicht funktioniert.
Höchster Wert, höchstes Risiko, niedrigste Kosten

Antworten (2)

Lassen Sie mich die beiden Teile Ihrer Frage etwas getrennt angehen.

So priorisieren Sie

Der Scrum Guide sagt: „Der Product Owner ist verantwortlich für das Product Backlog, einschließlich seines Inhalts, seiner Verfügbarkeit und seiner Reihenfolge.“ Am Ende des Tages hat der Product Owner das letzte Wort darüber, welches der von Ihnen aufgelisteten Kriterien der beste Weg ist, um das Backlog zu priorisieren. Das gesamte Team sowie die Stakeholder können jedoch einbezogen werden, um dem Product Owner dabei zu helfen, die Komplexität, den ROI, das Risiko usw. einer PBI zu beurteilen. Mit anderen Worten, Ingenieure, Designer, Business-Analysten, Interessengruppen, QA-Analysten und andere können wertvolle Beiträge leisten, um dem PO zu helfen, einen Anruf zur Priorisierung zu tätigen.

Im Allgemeinen habe ich ein paar Methoden gefunden, die Product Ownern helfen, sich mit der Priorisierung auseinanderzusetzen:

  • MoSCoW-Priorisierung – kategorisieren Sie High-Level-Features/Epics nach „Muss“, „Sollte“, „Könnte“ und „Wird nicht“ für eine kommende Veröffentlichung. In Zusammenarbeit mit dem Entwicklungsteam, um den Zeitplan und die Risiken zu verstehen, kann der PO bestimmen, welche Funktionen es in die nächste Version des Produkts schaffen müssen, und dann zwei separate Ebenen von „Nice-to-Haves“. Won't Have hilft auch, weniger wichtige Funktionen gezielt auszuschließen. Ich empfehle DRINGEND , für diese Übung echte Pinnwände mit Haftnotizen oder Karteikarten zu verwenden.
  • User Story Mapping – Hier ziemlich gut erklärt , wenn Sie bestimmte User Storys geschrieben haben, können Sie diese nach Funktionalität priorisieren und dann Ihre MMF/MVP-Linie basierend darauf ziehen, welche Funktionen absolut notwendig sind und welche nicht. Das geht ganz einfach auf einem Whiteboard oder einem großen Blatt Papier mit Haftnotizen.
  • Die „Hundert-Dollar“-Methode – Der Product Owner und wichtige Stakeholder erhalten 100 „Dollar“ oder „Punkte“, die sie den verschiedenen User Stories oder Features auf einer Pinnwand oder einem Whiteboard zuweisen können. Die Teilnehmer können beliebig viele ihrer Punkte für ein bestimmtes Feature einsetzen. (Ingenieure können viele Punkte auf das Refactoring eines Legacy-Produkts legen, während das Marketing viel auf eine auffällige neue Funktion legen kann. Der CEO kann alle seine Punkte auf das legen, was seiner Meinung nach den größten ROI haben wird.) The PO kann diese Informationen dann verwenden, um ihnen bei der Priorisierung ihres Rückstands zu helfen.

Wann priorisieren

Für eine High-Level-Feature-Priorisierung empfehle ich, mindestens einmal pro Quartal eine Release-Planungssitzung abzuhalten. Wenn mehrere Releases für ein Quartal geplant sind, sollte jedes Release seine eigene Release-Planungssitzung haben. Hier kann ein PO MoSCoW-Priorisierung oder andere Methoden verwenden, um auf hoher Ebene zu bestimmen, was in einer bevorstehenden Version enthalten sein wird.

Während der Entwicklung kann die Priorität des Product Backlogs jederzeit vom Product Owner geändert werden, wobei die Notwendigkeit der Pflege/Verfeinerung von Elementen berücksichtigt wird, bevor sie in einen Sprint gebracht werden. Mit anderen Worten, Teams sollten sich niemals auf Elemente festlegen, die sie als nicht vollständig gepflegt betrachten, selbst wenn sie ganz oben im Backlog stehen.

Teams sollten zumindest die kurzfristige Priorisierung von Elementen mit dem Product Owner bei jedem Sprint Review und Grooming-Meeting überprüfen, um sicherzustellen, dass sie die richtigen Elemente für den nächsten Sprint verfeinern und an den Funktionen mit der aktuell höchsten Priorität arbeiten.

Ich hoffe, das hilft – lassen Sie es mich gerne wissen, wenn ich hier etwas nicht behandelt habe!

Ich habe dies für das Story Mapping verwendet winnipegagilist.blogspot.ca/2012/03/… Danke für den Link zur ScrumAlliance.
Die von Ihnen erwähnten Methoden sind Methoden zur Priorisierung des Rückstands, sie sprechen nicht über die Faktoren, die bei der Priorisierung berücksichtigt werden. Welche Faktoren werden bei der Priorisierung berücksichtigt?
Ich denke, Sie haben die entsprechenden Faktoren in Ihrer Frage genau klassifiziert. Ich glaube nicht, dass Ihnen jemand eine Formel geben kann, die besagt: „Es sind X % ROI, Y % Kundenanfragen und Z % Risiko.“ Ein Teil der Aufgabe eines PO besteht darin, herauszufinden, was für seine Organisation und sein Produkt am besten funktioniert, wenn es um Priorität geht, und das ist ein iterativer Prozess. Die Überprüfung, wie Ihr letztes Release gelaufen ist, sollte zu einer Anpassung Ihres Priorisierungsprozesses führen.
Um hier nur ein wenig anzuhängen – in meiner Firma haben wir an Projekten von medizinischen Geräten über mobile Verbraucher-Apps bis hin zu Risikomanagementsystemen auf Unternehmensebene gearbeitet. Ich hatte noch nie zwei Product Owner, die auf die gleiche Weise priorisiert haben.

Meiner Meinung nach hängt es davon ab, was das Ziel Ihres Produkts ist. Gemäß dem Scrum Guide bezüglich Product Backlog Verantwortlichkeiten:

Ordnen der Elemente im Product Backlog, um Ziele und Missionen am besten zu erreichen;

Ich denke, dass jede Entscheidung gemeinsam mit Ihrem Kunden getroffen werden muss, was die Produktmission ist. In meinem Unternehmen verwende ich den ROI normalerweise zuerst, um zu ranken, und das Risiko, das zweite, um ein Unentschieden zu lösen.

Wenn Sie eine Entscheidung mit dem Kunden treffen, meinen Sie meiner Meinung nach, mit dem Kunden an den Entscheidungen zusammenzuarbeiten und sein Feedback einzuholen. Der Kunde kennt möglicherweise nicht den Prozess, den Sie durchlaufen, und ist möglicherweise verwirrt, oder? Beispiel: Ein Kunde fragt nach einem Feature und der PO arbeitet mit dem Team zusammen, um es in kleinere PBIs zu zerlegen und diese einzeln bereitzustellen. Ich stimme Ihnen zu, den Input des Kunden zu 100 % zu erhalten.
Nun, der Kunde kennt vielleicht nicht den Softwareentwicklungsprozess, aber er muss wissen, was am meisten benötigt wird. In Ihrem Beispiel sollten alle Geschichten, die sich auf dieses Epos beziehen, eine höhere Priorität erhalten, stimmen Sie zu?
Was sind die verschiedenen Ansätze und wie oft wird der Rückstand priorisiert? [abgeschlossen]
AntwortenHierDatenschutz-Bestimmungen1y, 0v