Ich lese immer wieder, dass sich das Entwicklungsteam beim Product Backlog Grooming mit dem PM und dem Product Owner trifft und als Team die Funktionen priorisiert.
Entscheidet letztendlich der Product Owner über die Priorität (was zuerst bearbeitet und veröffentlicht werden muss)?
Wo kommt der Business Analyst ins Spiel? Ich dachte, es wäre die Aufgabe des BA, Beziehungen zu den Interessenvertretern des Unternehmens aufzubauen, die Vision zu lernen, die Bedürfnisse der Kunden zu lernen und mit dem Unternehmen zusammenzuarbeiten, um Prioritäten und Anforderungen zu bestimmen?
Kann das bitte jemand klären, danke!
Der Business Analyst arbeitet mit dem Product Owner zusammen und liefert ihm wertvolle Einblicke in den Wert und die Wichtigkeit der User Stories, aber der PO ist immer noch die Person, die die Priorität des Backlogs festlegt. Gleiches gilt für die Beteiligung des Teams. Die Teammitglieder stellen dem PO nützliche Informationen auf technischer Ebene zur Verfügung, und der PO sollte in der Lage sein, diese Informationen zu verstehen und bei der Priorisierung des Rückstands zu verwenden.
Die direkte Antwort ist, dass der Product Owner das Backlog priorisiert. Es ist natürlich etwas nuancierter als das. In einer idealen Welt würde der PO die Rückstandsartikel einfach nach Aufwand und Wert sortieren, um ihre Priorität zu schaffen – und das passiert normalerweise zuerst. Das Team wird jedoch viel Input dazu liefern, wie sich die ausgewählte Bestellung auf ihre Fähigkeit auswirkt, Produktinkremente zu liefern. Beispielsweise kann das Team sagen, dass das Voranstellen eines Elements vor einem anderen es ihnen ermöglicht, sie mit weniger Gesamtaufwand zu liefern.
Der Business Analyst ist in einer interessanten Position. Sie werden feststellen, dass es in Scrum keine BA-Rolle gibt. Die traditionelle Rolle von BA erstreckt sich sowohl auf die PO-Rolle, wenn es darum geht, Stakeholder einzubeziehen und die zu erledigende Arbeit zu identifizieren, als auch auf die Teamrolle, wenn es darum geht, technische Details, Datenbank- und Bildschirmdesign und andere Implementierungen zu untersuchen Besonderheiten. Der reine Scrum-Ansatz würde bedeuten, dass Sie sich entscheiden müssen, entweder der PO oder ein Teammitglied zu sein und dann diese Rolle zu übernehmen, aber da viele Teams beginnen, ist dies aus einer Reihe von Gründen nicht möglich oder praktikabel. Wenn Sie weiterhin eine BA-Stelle besetzen, die sich auf beide Rollen erstreckt, würde ich zwei Vorschläge machen:
1) Wissen Sie, welchen Hut Sie zu jeder Zeit tragen, und tragen Sie nur einen. Wenn Sie beispielsweise versuchen, einige User Stories für die Backlog-Verfeinerung vorzubereiten, tragen Sie Ihren PO-Hut, also achten Sie darauf, nicht in die Implementierungsdetails einzusteigen. Erstens werden Sie echte Probleme haben, den Rückstand vor dem Team zu halten, und zweitens nehmen Sie dem Team die Lösung aus der Hand, wodurch seine Eigenverantwortung und sein Verantwortungsbewusstsein verringert werden. Wenn Sie am Entwerfen oder Erstellen der Software arbeiten, behalten Sie in ähnlicher Weise Ihren Teamhut auf. Wenn Sie unbeabsichtigt zurück zu PO wechseln, wird dem Team eine Nachricht gesendet, dass Ihre Gedanken ihre übertrumpfen, und Sie verlieren erneut die Eigentümerschaft (die offensichtliche Ausnahme ist, wenn das Team Ihnen eine PO-Frage stellt).
2) Traditionell wird vom BA für Projekte erwartet, dass er die Analyse und das Design viel weiter vorantreibt, als es Scrum erfordert. Das gesamte Team sollte das Design und die Erstellung der Implementierung der User Story übernehmen. In vielen Fällen sind Sie vielleicht die Person, die es tut, aber das Team als Ganzes sollte es besitzen, und wenn Sie keine Zeit haben, sollten andere Teammitglieder einspringen. Das Entwicklungsteam sollte Ihnen das niemals aufdrängen und sagen, dass es so ist kann nicht an etwas arbeiten, weil Sie die Designdetails noch nicht fertiggestellt haben.
Die Antwort lautet: Ja, nein, es kommt darauf an, in wirklich agiler Manier. :)
Ich hatte also je nach Fall Glück oder Pech und habe noch nie in einem Unternehmen mit der Rolle des Business Analyst gearbeitet. Daher kann ich Zsolts Antwort nicht kommentieren.
Was ich weiß ist, dass wir in der agilen Community immer mehr das Konzept des Product Owner Teams sehen . Und das Konzept dessen, was ich als Pyramidenplanung bezeichne , ist in der Agilität immer noch sehr gültig.
Pyramidenplanung: Die Idee mehrerer Planungsphasen mit größeren Detailebenen. Das groß angelegte agile Modell SAFe nutzt dies ausgiebig. Auf der höchsten Ebene erfolgt die Priorisierung durch ein Geschäfts-/Strategieteam. Bei meiner derzeitigen Firma (AOL) verwenden wir dies regelmäßig. Je näher man der eigentlichen Entwicklungsarbeit kommt, desto mehr wechseln die Personen, die an der konkreten Planung beteiligt sind. VPs und Execs entscheiden über die vier großen Dinge, die in diesem Jahr erledigt werden, das Team entscheidet, was für die Iteration im nächsten Monat erledigt wird. Womit wir bei der Idee wären...
Product Owner Team: Da ich in einem früheren Leben Produktmanager war, kann ich ohne Zweifel sagen, dass nur wenige Produktmanager, wenn überhaupt, alle Entscheidungen selbst treffen können. Sie sind normalerweise kaum mehr als der Cowboy, der verzweifelt versucht, das bockende Pferd festzuhalten und es in die richtige Richtung zu lenken. Das Product Owner Team (POT)erkennt dies und formalisiert es. Der POT besteht aus den Schlüsselpersonen, die dem PO alle Daten zur Verfügung stellen können, um eine fundierte Entscheidung zu treffen. Ein POT hat oft zusätzlich zum PO einen Architekten, einen Vertreter des Entwicklungsteams, Ops/IT, Kundensupport und BAs, falls das Unternehmen sie hat. Als Team überprüfen sie User Stories und priorisieren sie basierend auf dem Gesamtbild, nicht nur einer eingeschränkten Geschäftsansicht, die häufig auftritt, wenn ein Produktmanager versucht, in einem Vakuum zu arbeiten.
Und es ist wichtig zu beachten, dass Sie immer mit dem Team zusammenarbeiten müssen, um zumindest eine grobe Schätzung des Aufwands zu erhalten. Sie, der Product Owner, denken vielleicht, dass das Teleportieren von Autos das wichtigste Feature überhaupt ist. Und Sie könnten Recht haben, nur das Entwicklerteam wird Ihnen sagen, dass es, egal wie wertvoll es ist, 100-mal länger dauern wird, als ein neues selbstfahrendes Auto zu bauen. Sie müssen immer Zeit in Ihre Priorisierung einbeziehen und nur das Team kann Ihnen eine realistische Schätzung geben.
In einem traditionellen Scrum-Team ist der Product Owner dafür verantwortlich, dass das Backlog priorisiert wird. In einem reinen Scrum-Team gibt es keine BA-Rolle.
Das Team ist dafür verantwortlich sicherzustellen, dass jeder versteht und zustimmt, dass die Prioritäten richtig sind.
Das Team und der PO sind gemeinsam für die Priorisierung des Rückstands verantwortlich.
In Wirklichkeit gibt es BAs. Wichtig ist, dass das gesamte Team zustimmt und versteht, wer dafür verantwortlich ist (stellt sicher, dass es erledigt wird), um sicherzustellen, dass das Backlog priorisiert wird, und wer dafür verantwortlich ist (macht es).
Es gibt Teams, in denen der BA rechenschaftspflichtig und in Kombination mit dem Rest des Teams verantwortlich ist. Es gibt Teams, in denen der BA nur verantwortlich ist und der PO immer noch zur Rechenschaft gezogen wird. Es hängt von Ihrer Organisation ab und davon, was für Ihr Team am besten funktioniert.
Sie möchten Situationen vermeiden, in denen 1 Person verantwortlich ist, da die Priorisierung ein komplexes Problem ist, das davon profitiert, dass mehrere Augen/Köpfe vorhanden sind, um eine optimale Priorität sicherzustellen.
Einige wirklich ausgezeichnete Antworten hier!
Da wir über Product Owner sprechen, gehe ich also von Scrum aus, möchte ich einen Link hinzufügen – Scrum Guide von der Scrum Alliance.
The Product Owner is the sole person responsible for managing the
Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and
clear to all, and shows what the Scrum Team will work on next;
- Ensuring the Development Team understands items in the Product
Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it.
However, the Product Owner remains accountable.
Wie dies zeigt, KANN der Product Owner das Entwicklungsteam mit dieser Arbeit beauftragen. Aber der Product Owner ist verantwortlich – das ist der wichtige Faktor – Verantwortlichkeit.
Hängt vom Prozess ab, der für dieses Projekt ausgewählt wurde.
Im echten Scrum ist der Product Owner derjenige, der das Product Backlog priorisiert. Es ist jedoch das Entwicklungsteam, das entscheidet, wie viele der priorisierten Storys es in den bevorstehenden Sprint einbauen kann.
Normalerweise geschieht dies in der ersten Sitzung des Sprint Plannings, wenn der PO seine Auswahl an Geschichten für den Sprint vorstellt. Das Entwicklungsteam schätzt dann die Reihenfolge und die Menge der Stories, an denen es sich bereit erklärt, in demselben Sprint zu arbeiten, und verhandelt es gegebenenfalls neu.
Es ist also der PO, der Prioritäten setzt, aber es ist das Entwicklungsteam, das das letzte Wort hat, was in das Sprint-Backlog kommt.
Das PO- und Entwicklungsteam trifft sich und diskutiert. PO präsentiert die Reihenfolge aller Stories im Product Backlog, die er im kommenden Sprint sehen möchte. Entwicklungsteam
PO & Dev.Team haben sich auf die Anzahl und Reihenfolge der Storys geeinigt, an denen während des Sprints gearbeitet wird (sie haben das Sprint Backlog definiert). Das Dev.Team entscheidet, wie an jeder Story gearbeitet wird. An diesem Punkt brauchen sie die PO bei der Besprechung nicht mehr.
Dabei spielt es keine Rolle, wer den Rückstand priorisiert. Was wirklich zählt, ist, wie das gemacht wird: durch die Analyse von Risiko, Nutzen und Auswirkungen jeder Verbesserung. Die eigentliche Rolle der Person, die diese Analyse durchführt, ist dabei zweitrangig.
jason.t.knight