Susanne Mühlbauer, HOOD GmbH, am Swiss Requirements Day 2011 über die Arbeit des Scrum Product Owners und Tipps für seine Arbeit.
Requirements Engineering ist ein komplexes Thema. Noch dazu sind neue Ideen wie Scrum zunächst ungewohnt und allenfalls schwer verständlich.
Was ist der Unterschied zwischen Projektleiter und Product Owner?
In welchem Status der Scrum-Einführung steht man, wer kann die Rolle des Product Owners wahrnehmen? Einem Product Owner steht ein Scrum Master und ein Entiwicklungsteam gegenüber.
Der Product Owner stellt die Kommunikation mit den Stakeholdern sicher. Der Product Owner muss also Business Knowhow, Planungs-Knowhow, Requirements Engineering, Prioritäten, Releaseplanung und die Kommunikation beherrschen.
Wie füllt der Product Owner das Backlog?
Sind alle Anforderungen und Wünsche aller Stakeholder an das Produkt für den kommenden Sprint im Backlog enthalten? Anforderungen müssen verfügbar sein, priorisiert, nach Aufwand geschätzt, Investkriterien erfüllt und verstanden sein.
Aus Vision, Business Plan und Business Drivern wird der Minimum Marketable Product identifiziert. Daraus wird die Releaseplanung und das Product Backlog anhand von User Stories generiert.
Aus der Stakeholder- und User-Analyse identifiziert man, wann man wen ansprechen muss. Der Fokus liegt auf dem Business Value und hohem Projekterfolg. Politische Einflüsse sind dabei nicht zu unterschätzen.
Die Priorisierung orientiert sich am Business Value: Für den Kunden, für das Unternehmen (Folgekosten, Kostensenkung). Auch Stakeholder, Themen, MuSCoW, Risiko, Kano (Leistungsfaktoren, Begeisterungsfaktoren), nicht-funktionale Abhängigkeiten, Organisation, zeitliche Vorgaben (Launch-Date) sind weitere Kriterien für die Priorisierung.
Der Priorisierungspoker ist ein beliebtes unterstützendes Tool.
Was unststützt den Product Owner dabei, User Stories zu erstellen?
Grooming the Backlog: Striegeln sorgt bei Pferden dafür, dass im Fell keine Rückstände den Halt des Sattels behindern. Analog versucht man im Backlog auf das Wichtigste zu fokussieren.
Im Requirements Management unterscheidet man zwischen Problem und Lösung. Die Methoden werden entsprechend aufgeteilt.
Für alle im Problembereich liegenden Aktivitäten ist der Product Owner zuständig. Für die Lösung ist das Team verantwortlich unter Beizug des Product Owners. Dort sollte er sich allerdings mit neuem Input zurückhalten. Er sollte nur Fragen beantworten.
‹INVEST in good stories‹, Bill Wake. Eine User-Story ist keine fertige Spezifikation sondern verhandelbar nach den Kriterien Indipendent, Negotiable, Valuable, Estimable, Small, Testable.
In einem ‹Vertical Slice› sollten alle Ebenen der Software überprüft werden, nicht nur die Daten-, Logik- oder GUI-Schicht.
Wie stellt der PO sicher, dass er agil arbeitet?
Embrace Change ist ein wichtiges Konzept in Scrum. Inhalte eines Sprint Backlogs dürfen aber nicht geändert werden, deshalb sind die Iterationen mit 2 bis 3 Wochen ja auch so kurz.
Die Definition von Done soll umfassen: Dokumentation, Tests (Integration, Regression), Refactoring. «Nur fertig ist fertig», Ralf Wiedemann.
Tipps für Scrum Product Owner
- Beziehen Sie das Team in die Anforderungsmanagementaktivitäten ein
- Beziehen Sie die Stakeholder mit ein und vergessen Sie externe Stakeholder nicht
- Holen Sie sich Hilfe vom Team beim Formulieren und Schneiden von User Stories
- Definieren Sie nicht die Lösung – fragen Sie die Experten
- Versuchen Sie auch die technische Lösungsfindung zu verstehen
- Seien Sie aktiv, bringen Sie sich ein und geben Sie Feedback
http://twitter.com/#!/WalterSchaerer/status/83465057224232960
Ein Kommentar
Ich bin selber als Product Owner tätig und habe hier in meinem Blog meine Erfahrungen zusammengefasst.