dot.tipp - Wie werde ich Product Owner? (Teil 1/2)

Wir werden oft gefragt: "Wie werde ich zum Product Owner?" - eine einfache Frage mit sehr vielschichtigen Antworten, die wir in diesem Blog beantworten möchten. Bist du auch betroffen, dann musst du unbedingt weiter lesen!

Was ist deine aktuelle Rolle? Vielleicht eine von diesen:

• Business Analyst
• Solution Architect
• Projektleiter
• Requirements Engineer
• Solution Designer
• Entwickler
• Business Engineer
• Sachbearbeiter

Leider kann man diese Rollen nicht alle in einen Topf werfen, sondern findet schnell heraus, dass die einen Rollen eine fachliche und die anderen eine technische Ausprägung haben. Je nach Rolle wird dein Weg ein etwas anderer sein.

Ich zeige dir gerne einen möglichen Weg, der aus der Basis und zwei "Add-Ons" besteht:

• Basiswissen erlangen
• Add-On 1: Von der technischen Ausprägung zum Product Owner
• Add-On 2: Von der fachlichen Ausprägung zum Product Owner

Wichtig ist aber für alle Rollen: Die Basis zum Product Owner ist immer die Gleiche!

Basiswissen erlangen - Scrum

Was macht eigentlich ein Product Owner den ganzen Tag? Die schnellste Antwort findest du im Scrum Guide: Backlog-Management! Aus was besteht denn Backlog-Management?

Dies kann man auf folgende Themen reduzieren:

• Die Einträge im Backlog klar formulieren
• Das Product Backlog so zu priorisieren, dass Ziele und Mission des Vorhabens Best möglichst erreicht werden
• Den Wert der Arbeit optimieren, welche durch das Team gemacht wird
• Er stellt sicher, dass das Backlog transparent und für alle zugänglich ist
• Er stellt sicher, dass sein Team alle Backlog Einträge im erforderliche Mass versteht

Verstehst du alles?

Wenn ja, weiter zum nächsten Kapitel! Wenn nein, musst du dich zuerst über Scrum informieren oder dir in einem Kurs die Basis aneignen. Hierzu eignen sich die folgenden zwei Kurse am besten:

• Scrum Master
• Product Owner

Basiswissen erlangen – Requirements Engineering

Was viele vergessen ist, dass die meisten Tätigkeiten des Product Owners mit Methoden aus dem Requirements Engineering zu tun haben.

Diese kann man - nach IREB - grob in die folgenden vier Schritte zusammenfassen:

• Anforderungen erheben
• Prüfen und abstimmen
• Dokumentieren
• Verwalten

Viele steigen ohne Unterstützung oder das Fundament des Requirements Engineerings in die Rolle des Product Owners ein, was dann meistens in folgenden Situationen mündet:

• Mehrdeutige Anforderungen
• Keine Roadmap vorhanden
• Ungenügend priorisierte Anforderungen
• Ein Team ohne klare Ziele und Ausrichtung

Die Schwierigkeit liegt in vielen Faktoren versteckt. Ist eine Anforderung zu technisch, kann man sie nicht mit den Leuten aus dem Business diskutieren, sind sie voller Fachausdrücke, müssen die Entwickler kapitulieren.

Jede Anforderung entwickelt sich weiter und darum ist es wichtig, dass diese im ersten Moment mit dem Business besprochen werden können. Im Anschluss kann dann mit den IT-Fachkräften um die Lösung gerungen werden.

Hier gilt der Grundsatz: Füge Details dann hinzu, wenn diese nötig sind!

Wie ein möglicher Pfad für fachlich oder technisch affine Product Owner aussieht, möchte ich dir in meinem zweiten Teil dieses Blogs erklären.