Der Scrum Product Owner, ist verantwortlich für die Verwaltung des Produktbestands, um das angestrebte Ziel des Teams zu erreichen. Die PO-Rolle ist neu und kritisch.
Es gibt viele Rollen in einem Scrum Team. Eine Rolle, der Scrum Product Owner (PO), ist verantwortlich für die Verwaltung des Produktbestands, um das angestrebte Ziel des Teams zu erreichen. Die Rolle des PO ist in Bezug auf die Qualität von Bedeutung. Er ist das einzige Mitglied im Team, das befugt ist, jede User Story als solche zu akzeptieren.
Für die meisten Unternehmen, die auf den agilen Prozess wechseln, ist die PO-Rolle eine neue und kritische Rolle. Die meisten Unternehmen stellen einen Scrum Product Owner auf Vollzeit-Basis ein, um das agile Team zu unterstützen. Die Beziehungen und Verantwortlichkeiten des PO sind nicht nur wichtig, sondern erstrecken sich auch über das lokale Team hinaus. Er arbeitet auch mit dem Rest des Projektmanagementteams, Kunden und Interessenvertretern zusammen.
Der Scrum Product Owner hat Leitungsfunktion; in der Regel ist es jemand mit einem Hintergrund in Marketing, Projektmanagement, oder kennt sich mit dem Markt und seinen Nutzern aus. Er muss auch ein klares Verständnis der Wettbewerbs- und Zukunftstrends der Domäne und der Art der zu entwickelnden Systeme haben.
Die Rolle desProduct Owners wurde ursprünglich geschaffen, um den Herausforderungen zu begegnen, vor denen viele Scrum-Teams standen. Viele Teams hatten Schwierigkeiten, sich für eine Richtung zu entscheiden. Dies führte dazu, dass das Team eine widersprüchliche Richtung, mehrere Richtungen oder überhaupt keine Richtung hatte.
Der PO verbringt viel Zeit mit dem Team, klärt die Einzelheiten des Produktbestands und entscheidet anhand der Produktspezifikationen, welche Punkte zu erledigen sind.
Der Job des Scrum Product Owners kann schwierig sein. Er muss alle Entscheidungen über das Produkt treffen, die Anforderungen des Unternehmens an das Produkt kennen und eine beträchtliche Menge an Zeit mit dem Scrum Team verbringen.Aufgrund des Arbeitsaufwandes werden die Verantwortlichkeiten oft zu gleichen Teilen auf viele Teammitglieder aufgeteilt. Unternehmen beginnen mehr und mehr, ein Werteteam zu verwenden, um die Arbeitslast zu bewältigen. Wenn Sie sich als Unternehmensinhaber für diesen Ansatz entscheiden, müssen Sie einen einzelnen Entscheidungsträger benennen.
Das ideale Verhältnis von PO zu Scrum Team ist 1:1 - ein Produktentwickler zu einem Scrum Team. Das Verhältnis wird gestört, wenn mehr als ein Team gleichzeitig am selben Produkt arbeitet. Der PO arbeitet mit mehreren Teams zusammen. Das Problem bei diesem Modell ist, dass ein Team oft vom PO ignoriert wird.
Teams, die von einem PO mehr benötigen als das, was der PO liefern kann, können einen stellvertretenden PO ernennen. Der Stellvertreter kann entweder vom aktuellen PO oder Team ernannt werden.
Vielen Teams gefällt dieser Ansatz jedoch nicht, da der Scrum Product Owner die Entscheidungen des Stellvertreters jederzeit außer Kraft setzen kann. Oft überschreibt der tatsächliche PO den Stellvertreter zu einem Zeitpunkt, der für das Team am ungünstigsten ist.
Die Rollen und Zuständigkeiten können je nach Produkt und Entwicklungsumgebung voneinander abweichen, aber es gibt viele gemeinsame Faktoren für jede Position. Jeder PO besitzt alle Verantwortlichkeiten, aber er sollte mit seinem Team zusammenarbeiten und die Arbeitslast entsprechend der Anforderungen an das Team zu delegieren.
Der PO ist verantwortlich für die Festlegung der Ziele und die Erstellung der Vision des Teams. Die Vision muss klar an alle am Projekt beteiligten kommuniziert werden, einschließlich: dem Scrum Team, den Interessenvertretern und dem Projektmanagementteam. Die Vision wird verwendet, um die Entscheidungen des Teams zu priorisieren und zu lenken.
Der PO erstellt und verwaltet die Liste der Aufgaben, die vom Scrum Team erledigt werden müssen. Er beschreibt den Produktbestand und die Annahmekriterien für jeden einzelnen Teil und vergibt dann die Arbeit, um sicherzustellen, dass die Produktvision erfüllt wird.
Der Produktbestand muss sichtbar gemacht werden, sodass jeder, der mit dem Team zu tun hat, ihn sehen kann. Auf diese Weise kann der PO die Arbeitsleistung optimieren und sicherstellen, dass der Interessenvertreter die Strategie- und Entwicklungs-Roadmap klar versteht.
Der Auftragsbestand ist immer in Bewegung und wird ständig aktualisiert. Der Bestand zeigt alle Arbeiten, die während der Entwicklung abgeschlossen werden müssen. Er wird verwendet, um sicherzustellen, dass das Team die wichtigsten Aufgaben immer iterativ und inkrementell abschließt.
Der PO ist verantwortlich für die beste Rendite. Er ist zuständig für alle wirtschaftlichen Entscheidungen auf der Freigabe- und Produktebene des Sprints. Das eiserne Leistungsdreieck - Budget, Zeit und Qualität - kann je nach Bedarf angepasst werden. Eine Kosten- und Nutzenbewertung jedes Teils im Produktbestand können auch verwendet werden, um die Reihenfolge der Arbeit zu bestimmen.
Der Scrum Product Owner muss das Scrum-Team einbeziehen. Er muss die Vision der Organisation mitteilen, die Fragen des Teams beantworten und sich die Vorschläge zum Hinzufügen, Löschen, Ändern oder Verbessern des Benutzerziels anhören. Der PO motiviert das Team und holt Feedback ein.
Der Scrum Product Owner definiert auch die Grenzen und Engpässe, die die Zielerreichung beinflussen. Mit Einschränkungen muss umgegangen werden können. Es kann sich um terminliche, kostenbezogene, speicherplatzabhängige Einschränkungen oder um Mindestgeschwindigkeiten handeln.
Der PO muss darauf achten, keine unrealistischen oder technisch unmöglichen Ziele zu setzen. Wenn unrealistische Ziele eingereicht werden, ist eine gute Kommunikation zwischen dem Benutzer, dem Vertreter des Benutzers und dem Scrum Team der Schlüssel zur Früherkennung.
Die Priorisierung von Aufgaben auch während des Sprints ist wichtig, um die Teamziele zu erreichen. Die Teams arbeiten zunächst an den wichtigsten Segmenten. Wenn sie abgeschlossen sind, können sie diese Segmente an den Benutzer oder Kunden freigeben. Segmentierungsaufträge können höhere Produktwertschöpfung und positive Renditenergebnisse erzielen. Das kann auch dazu beitragen, Teile des Produkts früher auf den Markt zu bringen.
Projekte können eine lange Zeit dauern; daher ist jedes Feedback wichtig. Ob gut oder schlecht, Feedback bedeutet in der Regel, das Projekt zu verändern, zu eliminieren oder Ziele hinzuzufügen. Da die Änderungen vorgenommen werden, während das Projekt bereits läuft, sind die Kosten geringer als wenn das Projekt bereits beendet wäre.
7. Teilnahme an der Entwicklung
Der PO spielt eine wichtige Rolle bei der Entwicklung von Ereignissen wie der Planung, Verfeinerung, Retrospektiven und Rückblicken auf Sprints und tägliche Scrums.
Er arbeitet mit den Interessenvertretern während der Planungsaktivitäten zusammen, um festzulegen, welche Schritte und Inhalte für die nächste Iteration, Freigabe oder Produktebene erforderlich sind.Während der wöchentlichen Verfeinerungssitzungen arbeitet der PO mit dem Scrum-Team zusammen, um Produkt Backlogs zu definieren, auszuarbeiten, abzuschätzen, zu vergeben oder zu löschen.
Er arbeitet mit dem Team zusammen, um die nächsten Maßnahmen zur Verbesserung der Arbeit festzulegen. Während des Sprints arbeitet der PO mit dem Scrum Team zusammen; er beantwortet Fragen und nimmt abgearbeitete Produktbestände an. Der Product Owner ist jedoch der einzige, der die Berechtigung hat,
Arbeiten hinzuzufügen oder zu entfernen, den Sprint abzubrechen oder die Entwicklung des Projekts zu stoppen.
Er kann an täglichen Scrums teilnehmen, um das Team bei der Arbeit im Sprint zu koordinieren und mit ihm zusammenzuarbeiten.
Scrum Product Owners haben diese fünf gemeinsamen Merkmale:
Der PO ist voll in das Projekt involviert. Er arbeitet täglich mit dem Scrum Team zusammen; beantwortet Fragen und ist verfügbar, wenn Probleme auftreten, die das Projekt verzögern könnten.
Die Organisation ermächtigt den PO, Entscheidungen zu treffen und für seine Entscheidungen verantwortlich zu sein. Alle Entscheidungen müssen auf Produktebene getroffen werden, um die Entwicklungsgeschwindigkeit zu erhalten.
Die Organisation muss darauf achten, den PO nicht zu übersteuern oder das Risiko einzugehen, dass das Team die Hierarchie des Unternehmens umgeht.
Der Scrum Product Owner muss die Fragen des Teams zeitnah und verbindlich beantworten. Verzögerungen können verhindern, dass die Arbeit rechtzeitig abgeschlossen wird. Die Aufhebung früherer Entscheidungen führt zu mangelndem Vertrauen.
Der PO hat die beste Rolle, um Entscheidungen auf Basis von Kundenwissen und mit der Unterstützung der Interessenvertreter zu treffen.
Der PO versteht die Bedürfnisse des Zielkunden. Er verfügt über fundiertes unternehmerisches Wissen, um die Produktentwicklung des Teams in Abstimmung mit allen Interessenvertretern zu leiten. Er hat ein starkes unterstützendes Netzwerk innerhalb der Organisation und kann gute Beziehungen zu Kunden und Lieferanten aufbauen.
Der PO muss ein ausgezeichneter Kommunikator, Kollaborateur sein und mit Menschen gut umgehen können. Er kann seine Vision teilen, Menschen zusammenbringen, ihre Anstrengungen konzentrieren und das Team motivieren. Seine hohe emotionale Intelligenz hilft bei der Zusammenarbeit und führt die Produktentwicklung zu einem erfolgreichen Abschluss.
Scrum Product Owners sind nicht nur Administratoren, sondern auch Kunden. Während es wichtig ist, die Interessenvertreter anzuhören und den Bestand entsprechend zu bearbeiten, ist es auch wichtig, auf den Kunden zu hören und seine Bedürfnisse zu entdecken.
Großartige PO tun mehr, als nur die User Story mechanisch in einen Produktbestandsartikel zu integrieren, bevor er an die Entwickler gesendet wird. Sie denken über Möglichkeiten nach, die User Story in ein Produktmerkmal zu verwandeln, das den Benutzer erfreut.
Sagen wir zum Beispiel, ein Auftragsbestandsartikel für ein Unternehmen, das Mitfahrgelegenheiten anbietet, ist, den Benutzern eine E-Mail-Quittung zu senden. Ist der Benutzer sehr beschäftigt? Muss er für den Beleg einen Spesenbericht in Excel erstellen? Gibt es zusätzliche Informationen wie Zahlungsmethode,
Dokumentoptionen, Abhol- oder Ausstiegsort, Entfernung - was wäre hilfreich? Ein guter PO wird sich das Gesamtbild ansehen.
Um ehrlich zu sein, wenn die Rolle des POs von einer Person im Scrum-Rahmenwerk übernommen wird, ist es unmöglich, dass eine Person alles verwaltet. Wenn die Arbeit ins Wanken gerät, schaffen viele Teams eine zusätzliche, parallele Rolle. Zum Beispiel können Teams auch einen technischenProduct Owner hinzufügen, um für die PO zu kompensieren, die sich nicht in einer Leitungsfunktion sehen.
Teams müssen delegieren und ein hilfreiches, informelles Team aufbauen, wenn sie überleben und Erfolg haben wollen. Warte, klingt das wie ein Scrum Team? Ja und nein. Sie können wählen, ob Sie einen Scrum Master und verschiedene Scrum Team Mitglieder hinzufügen möchten. Aber ein separates, informelles POr-Team hilft Ihnen bei verschiedenen Aufgaben, insbesondere wenn Sie in bestimmten Bereichen kein Experte sind.
Es ist nichts falsch daran, zu sagen, dass Sie auch ein Entwickler sind. Im Scrum sind die Teams oft in den delegierten Rollen gefangen. Obwohl das hilfreich ist, wenn Scrum gelehrt wird, ist es sonst nicht immer hilfreich. Die Rollen können leicht überbewertet werden, das verlagert dann den Fokus weg von der Wertschöpfung der Leistung dazu, wer was tut.
Als PO kann man leicht denken "Mir gehört der Produktauftragsbestand. Mir gehören die User Storys. Ich gebe sie dem Scrum Team und das entwickelt sie." Das mag zutreffen, aber Sie sind immer noch Teil eines Teams; nicht nur der Teamleiter. Das gesamte Team liefert einen Mehrwert. Wenn Sie Ihre Rolle als Mitglied des Teams sehen und den Rest der Mitglieder darin anleiten, was gebaut werden soll, wird Ihre Zusammenarbeit mit Anderen besser sein.
Wenn Sie Entwickler sind, sind Sie auch Wissensmakler. Sie können den Produktbestand repräsentieren und als Schnittstelle zwischen dem Scrum Team und dem Interessenvertreter fungieren, aber das bedeutet nicht, dass Sie ein Experte für das Produkt sind. Wenn Entwickler Code schreiben, kommen sie möglicherweise nicht weiter, wenn sie mit Ihnen sprechen.
Stattdessen sollten sie mit den Experten sprechen: den Interessenvertretern, die die Nutzer repräsentieren. Ein Teil Ihres Jobs besteht darin, mit den Entwicklern zu kooperieren und zu diese ermächtigen, indem Sie die richtigen Experten finden, mit denen Sie sprechen können. Wenn diese Diskussionen zu Änderungen führen, sollten Sie auf dem Laufenden gehalten werden.
Wenn das nicht möglich ist, sollten Sie die Entwickler beauftragen, Ihnen die benötigten Informationen zu beschaffen.
Wer mit Konflikten nicht umgehen kann, sollte kein Scrum Product Owner sein. In der Produktentwicklung werden Sie mit inhärenten, konfliktreichen Situationen konfrontiert, besonders wenn Menschen über Ressourcen und Politik streiten. Starke Konfliktlösungsfähigkeiten sind wichtig, um die Eskalation von Konflikten zu verhindern.
POs müssen mutig, selbstbewusst und in der Lage sein, mit schwierigen Situationen umzugehen. Und Sie sollten wissen, dass Sie normalerweise Konflikt bewältigen müssen, um eine Lösung zu erreichen. Zu wissen, wie man vermittelt und zusammenarbeitet, minimiert das Negative.
Egal, wie gut Sie in Konfliktlösung sind, irgendwann müssen Sie eine Situation in der Befehlskette eskalieren. Die Eskalation bezieht sich nicht auf kleine Streitereien, sondern auf das Feedback, das das Management hinsichtlich widersprüchlicher Ziele gegeben hat. Wenn beispielsweise zwei Interessenvertreter demselben Team zwei verschiedene Aufgaben zugewiesen haben, die nicht zusammenpassen, liegt ein Konflikt vor.
Die besten PO haben bereits Konflikt-Eskalationsmechanismen parat. Während Sie zweifellos versuchen werden, Konflikte so gut wie möglich mit den Interessenvertretern zu lösen, werden Sie immer noch die Fähigkeiten brauchen, die Managementkette auf und ab zu navigieren. Anstatt auf eine Krise zu warten, sollten Sie Ihren Eskalationsplan vorab erstellen und testen.
Sie können das tun, indem Sie nach Möglichkeiten suchen, kleine entsprechende Interaktionen schnell zu eskalieren, damit Sie die Fähigkeiten beherrschen. Zu einer Zeit, wo die großen Probleme passieren, werden Sie bereit sein, und sicher damit umgehen können.
Es gibt zahlreiche Fähigkeiten, die Sie als PO kultivieren können. Diese sieben Qualitäten geben Ihnen aber einen Vorsprung für Ihre Rolle.
Agile Transformation: Product Owner vs. agiler Wirtschaftsanalyst
Eine der ersten Herausforderungen, vor der Unternehmen beim Umstieg auf Agile stehen, ist das Verständnis der neuen Rollen, die zur Durchführung ihrer Initiative benötigt werden.
Die Rolle des POs ist die kritischste und das neueste Konzept für Unternehmen. Eine von Unternehmen häufig gestellte Frage lautet: "Was unterscheidet diese Product Owner-Rolle von einem agilen Wirtschaftsanalysten?" Die Unterschiede zwischen den beiden Rollen sind wichtig. Das Verständnis dieser Unterschiede ist entscheidend für Ihren Erfolg.
Die Rolle eines Product Owners besteht in der Zusammenführung mehrerer Rollen - Unternehmensvertreter, Wirtschaftsanalyst, Projektmanager, und andere Rollen. Diese Rollen sind zu einer zusammengefasst, um den Scrum-Ansatz zu unterstützen. Sie ist so konzipiert, dass sie ein Ausmaß an Verantwortlichkeit bietet, das es sonst nicht gibt.
Da es sich um eine neue Rolle handelt, ist es wichtig, die Personen zu identifizieren, die das Potenzial haben, die für die Arbeit erforderlichen Fähigkeiten zu entwickeln. Ich empfehle Ihnen, jemanden aus dem Unternehmen zu wählen, der nicht aus das IT-Ecke kommt, um diese Rolle auszufüllen. Sie sollten jemanden auswählen, der für das Schreiben von User Stories und für das Definieren der Akzeptanzkriterien eingeschult werden kann.
Sie wollen auch jemanden auswählen, der die Unterstützung und das Verständnis des Managements hat, dass die für diese Rolle erforderliche Verpflichtung weit größer ist als alles, was sie jemals zuvor erlebt haben. Ich möchte auch empfehlen, dass der Manager viele der bestehenden Verantwortlichkeiten der Person auf andere Mitarbeiter überträgt.
Warum sollten Sie also einen PO dazu ausbilden, User Stories zu schreiben und die Akzeptanzkriterien zu definieren, wenn Sie bereits einen Wirtschaftsanalysten mit denselben Fähigkeiten haben? Die Antwort ist Rechenschaftspflicht. Wenn eine Unternehmensressource den Inhalt von jedem Sprint eignet, gibt es niemanden, der Schuldzuweisungen machen kann, sodass zwischen IT und den Projektmanagern weniger Reibung entsteht.
Die Entwicklung einer Rolle, die Verantwortung für die Akzeptanz der User Stories hat, ist wesentlich, weil niemand in IT die Autorität hat, User Stories zu akzeptieren. Nur das Unternehmen selbst kann entscheiden, ob die abgeschlossene Arbeit akzeptabel ist und dem Zweck entspricht.
In Scrum ist nur eine Person für das Definieren und Akzeptieren von User Stories verantwortlich. Und ich kann nicht genug betonen, wie wichtig es ist, diese Verantwortlichkeiten nicht aufzuteilen.
Neben der Rechenschaftspflicht ist auch die Kommunikation wichtig. Wenn die POs aus dem Unternehmen kommen, besteht eine bessere Chance, dass die Kommunikation zwischen denProduct Owners und den Produktmanagern natürlicher und flüssiger wird.
Das wird es dem Team erleichtern, Probleme zu lösen und gleichzeitig mit den Geschäftszielen in Einklang zu bleiben. Es wird auch weniger Überraschungen während der Sprintdemonstrationen geben. Ein Produkteigner kann buchstäblich im Scrum Team "sitzen" und dann effektiv dem Produktmanager berichten; das überbrückt die Lücke zwischen den Management- und IT-abteilungen.
Wenn das Unternehmen sowohl mit dem PO als auch mit dem agilen Wirtschaftsanalysten kooperiert, können diese eine ganzheitliche Perspektive auf Problemlösungen entwickeln. Der PO bietet einen Benutzerfokus-Ansatz, während der Wirtschaftsanalyst den Fokus auf das System hat.
Der PO findet heraus, was der Benutzer wünscht, und entscheidet dann über die beste Möglichkeit, die beste Wertschöpfung zu liefern, während der Wirtschaftsanalyst die Anlaßfälle, Fehlerbedingungen, Abhängigkeiten und Auswirkungen auf andere Bereiche des Systems oder anderer Systeme identifiziert.
Es besteht kein Zweifel, dass der Wirtschaftsanalyst für das Team von großem Wert ist, aber der PO muss das ausschließliche Recht behalten, User Stories zu akzeptieren und Prioritäten zu verwalten, um die Verantwortlichkeit aufrecht zu erhalten.
Zusammenfassung
Da der PO für viele Organisationen eine neue Rolle ist, empfehlen wir Ihnen, Personen zu identifizieren, die über die für die Rolle erforderlichen Attribute verfügen.
Dazu gehören: starke Kommunikationsfähigkeit, ein guter Geschäftssinn, schnelle Entscheidungsfähigkeit, eine technische Grundlage und vor allem jemand, der sowohl mit dem Team als auch mit dem Produktmanagement ein gewisses Maß an Vertrauen aufbauen kann. Sobald Sie die richtige Person identifiziert haben, empfehle ich, den Kandidaten in ein vorbereitendes Training, Werkzeug-Training und fortlaufendes Coaching zu schicken.
Damit diese neue Rolle erfolgreich ist, muss die gesamte Organisation die Entscheidungen des Product Owners respektieren. Alle Entscheidungen sollten in den Inhalten und im Produktauftragsbestand sichtbar sein.
Ich hoffe, dieser Beitrag hat Ihnen klar die Verantwortlichkeiten und notwendigen Fähigkeiten eines Product Owners gezeigt.
Wenn dieser Beitrag hilfreich war, teilen Sie ihn bitte mit Ihren Freunden und Kollegen.
Wir ermöglichen Führungskräften, durch die Anpassung ihres projektzentrierten Unternehmens zu einem produktorientierten Unternehmen, hoch geschätzt und anerkannt zu werden.
Die Gesellschaft hat sich verändert und Führungskräfte benötigen Unterstützung, um ihre Unternehmen an das digitale Zeitalter anzupassen. Aus diesem Grund wurde die ADAPT Methodology® geschaffen!
Wenn Sie wissen möchten, ob Ihr Unternehmen projektzentriert oder produktgeführt ist, machen Sie einfach unseren „Project To Product Scorecard“.
Wenn Sie wissen möchten, wie wir Ihnen bei Ihrem Transformationsbeginn helfen können, werfen Sie einen Blick auf unser: „Projekt zu Produkt Schulung“.
Wenn Sie an einer Transformation in Ihrem Unternehmen interessiert sind, sehen Sie sich bitte unser Angebot an: „Projekt zu Produkt Beratung“.