PO #

Acceptance Criteria, Defenition of Ready и Defenition of Done

Запомни РО - это Value Maximizer - ты увеличиваешь ценность продукта всеми доступными способами дла конечного клиента
- Это значит что тебе надо знать чего хочет клиент, а это значит что надо говорить и/или “говорить” с клиентом; уметь определять-составлять Persona пользователя; что есть у конкурентов = анализ рынка и т.д. и
Уметь приоретезировать задачи (MoSCoW, Cost of Delay, Value-Complexity Matrix - уже будет достаточно) и выставлять цели разработчикам
Уметь писать User Stories (наиболее распространнёная формула As a < type of user > (тут лучше использовать User_Persona, но можно и User_Role, но лучше Персона - больше понимания и эмпатии), I want < some goal > so that < some reason > Читать на эту тему вот https://www.mountaingoatsoftware.com/agile/user-stories https://blog.easyagile.com/how-to-write-good-user-stories-in-agile-software-development-d4b25356b604
- Помнить что US должны соответствовать INVEST criteria
Уметь дробить US - Ищи SPIDR Technique (https://i.pinimg.com/originals/4c/8e/85/4c8e851a374274d65206401828a31e7f.jpg если быстро)
Уметь ставить цели на спринт и не вмешиваться в КАК разработки, а руководить ЧТО разрабатывать
Быть визионером для команды

Инструменты ПО #

https://www.aha.io/roadmappin g/guide/product-management/which-tools-do-product-managers-use

Je nachdem, was ich zu tun habe, werde ich das richtige Werkzeug verwenden. Ich bin der Meinung, dass man sich nicht an den Werkzeugen aufhängen sollte. Es ist wichtig, das Ziel nicht zu vergessen. Vieles lässt sich in einfachem Excel erledigen: Gantt-Diagramme, Nutzwertanalyse, Product Backlog, Netzplantechnik und kritische Wegfindung.

Es gibt etliche tools für kanban. Google Analitycs und google forms.

Es gibt auch bewerte methoden, wie jira, figma, Sketch, mockup, Balsamiq Wireframes, FreeMind, slack, trello, zoom

Product Roadmap #

Welche Bedeutung hat die Product Roadmap im Rahmen der Produktentwicklung? Die Product Roadmap beschreibt einen zeitlichen Rahmenplan, der die Strategie und Vision hinter einem Produkt und seine Entwicklung dorthin zeigt. Dabei fließen sowohl kurzfristige als auch langfristige Ziele ein. Die Product Roadmap bildet also ab, welche Schritte wann erfolgen, um die Produkt-Vision zur Realität werden zu lassen.

Auf der einen Seite dient sie damit als visualisierter Weg der Produktentwicklung für Kunden und Stakeholder. So ist jederzeit nachvollziehbar, welche Features und Meilensteine wann zu erwarten sind und ob das Projekt konsequent in die richtige Richtung läuft.

Auf der anderen Seite ist die Product Roadmap ein klarer Fahrplan für die an der Entwicklung beteiligten Teams, auf dem nicht nur die angestrebten Ziele, sondern auch die Zuständigkeiten für deren Erfüllung abgebildet werden.

Insbesondere in kleineren Unternehmen fällt der Aufbau einer Product Roadmap oft in den Aufgabenbereich des Product Owners. Aber auch in größeren Strukturen ist der Rat des Product Owners bei der Erstellung gefragt. Schlussendlich dient die Roadmap als Grundlage für das Aufgaben-Backlog. Aus ihr werden User Stories abgeleitet, die wiederum in Form von konkreten Anforderungen (Items) ins Backlog aufgenommen werden.

Product Owner gleichzeitig Scrum Master #

Kann ein Product Owner gleichzeitig Scrum Master eines Teams sein? Nein. Diese beiden Rollen verfolgen unterschiedliche Ziele die z.T. in Konflikt zueinander stehen können. Daher sollte ein Product Owner niemals gleichzeitig die Position des Scrum Masters einnehmen.

Während es die Aufgabe des Product Owners ist, pro Sprint ein Maximum an Entwicklungsfortschritt im Sinne des Auftraggebers bzw. Produkts zu erzielen, liegt die Verantwortung des Scrum Masters darin, ein möglichst störungsfreies Arbeitsumfeld für das Entwicklerteam sicherzustellen. Der Scrum Master ist also in erster Linie dafür zuständig, das Team organisatorisch im Entwicklungsprozess zu unterstützen, vor ungeplanten Anforderungen von außen zu schützen und bei der Beseitigung von Hindernissen (Impediments) zu helfen.

Im Gegensatz dazu besteht die Hauptaufgabe des Product Owners darin, die Interessen von Kunden oder Stakeholdern zu vertreten und deren Anforderungen an das Produkt möglichst schnell und effizient durch das Scrum-Team umsetzen zu lassen. Dazu organisiert und priorisiert der Product Owner die bestehenden Anforderungen (Items) in einem Product Backlog.

Wie priorisieren Sie das Product Backlog sinnvoll? #

Die Betreuung des Product Backlogs ist ein wesentlicher Verantwortungsbereich des Product Owners, da es die Gesamtheit aller projektbezogenen Anforderungen enthält. Es wird laufend gepflegt und bei Bedarf um neue Items ergänzt. Der Product Owner ist außerdem für die Priorisierung der einzelnen Items im Product Backlog zuständig und entscheidet darüber, welche Anforderungen als nächstes umgesetzt werden sollen. Da die Priorisierung einen maßgeblichen Einfluss auf die Produktentwicklung hat, gibt es verschiedene praxiserprobte Techniken, die der verantwortliche Product Owner hierzu nutzen kann:

MoSCoW – Mo (Must be), S (Should be), Co (Could be), W (Won’t be)

Um die geplanten Features eines Produkts sinnvoll zu priorisieren muss man sich zunächst in den Benutzer und seine Anforderungen an das Produkt hineinversetzen. Aus dieser Perspektive heraus werden die Items des Backlogs dann in die folgenden Kategorien eingestuft:

Mo (Must) Ohne dieses Feature ist das Produkt nicht nutzbar.

S (Should) Should beschreibt ein Feature, ohne das das Produkt zwar grundsätzlich nutzbar ist, das aber einen immensen Mehrwert liefert.

Co (Could) Mit Could wird ein Feature bezeichnet, das „nice-to-have“ wäre und beispielsweise eher dem visuellen Erscheinungsbild dient, ohne die grundlegende Funktionalität des Produkts zu beeinflussen.

W (Won´t) Won´t beschreibt Anforderungen, die zunächst keinen oder nur einen sehr kleinen Mehrwert liefern und deshalb vernachlässigbar sind. Diese Anforderungen können in einem späteren Kontext noch einmal aufgegriffen werden.

Nachdem jedes Item entsprechend der o.g. Kriterien klassifiziert wurde, stellt das Entwickler-Team ein Set an Anforderungen zusammen, die im nächsten Sprint umgesetzt werden können und sollen (Commitment).

Alternativ oder auch ergänzend zu der MoSCoW-Methode kann das Prinzip Weighted Shortest Job First (WSJF) angewendet werden. Hierbei werden die Anforderungen des Product Backlogs anhand ihres jeweiligen Verhältnisses von Wert für das Produkt und dem zeitlichen Aufwand ihrer Umsetzung priorisiert. Der Wert eines Features für das Produkt wird mithilfe einer Formel als sogenannter Cost of Delay ermittelt.

Weitere Methoden die bei der Priorisierung des Product Backlogs zum Einsatz kommen können sind das simple Stack Ranking oder der 100-Dollar-Test, bei dem die Stakeholder gebeten werden fiktive Dollar auf die verschiedenen Items zu verteilen.

Welche Eigenschaften zeichnen einen guten Product Owner Ihrer Meinung nach aus? #

Der Product Owner nimmt eine zentrale Rolle im Scrum-Prozess ein, da er eine Art Brücke zwischen den Stakeholdern auf der einen und dem Entwicklerteam auf der anderen Seite schlägt. Dabei ist es unerlässlich, dass er und seine Entscheidungen innerhalb der gesamten Organisation respektiert werden. In dieser Position sind deshalb einige Eigenschaften des Product Owners besonders wichtig:

Fachliches Verständnis #

Ausgeprägte Kenntnisse der Domäne und des Marktes sind essentiell für die erfolgreiche Arbeit eines Product Owners. Er muss das Produktumfeld und die dazugehörigen einflussnehmenden Faktoren gut kennen, um die Bedürfnisse des Kunden richtig zu verstehen und die Anforderungen an das Produkt entsprechend einstufen zu können.

Kommunikation #

Aufgabe des Product Owners ist es nicht nur, das Backlog zu priorisieren, sondern seine Entscheidungen auch verständlich und nachvollziehbar gegenüber dem Team zu kommunizieren. Der Product Owner ist dafür zuständig, die Produkt-Vision, also das große Ganze, zu visualisieren. Er hilft dem Entwicklerteam dabei, nicht den Blick auf den Sinn und Zweck hinter dem Umsetzen von Anforderungen zu verlieren.

Technisches Verständnis #

Insbesondere in der Zusammenarbeit mit Entwicklerteams ist es ein großer Vorteil, wenn der Product Owner selbst zumindest ein grundlegendes Verständnis für den Entwicklungsprozess mitbringt. So kann er mögliche Hindernisse (Impediments) besser einschätzen und damit zusammenhängende Verzögerungen gegebenenfalls auch in Richtung der Stakeholder fundiert rechtfertigen.

nicht-funktionalen Anforderung #

Was verstehen Sie unter einer nicht-funktionalen Anforderung und wie integrieren Sie sie in den Entwicklungsprozess? Als nicht-funktionale Anforderungen (non-functional requirements NFRs) werden Produkt-Eigenschaften beispielsweise in Bezug auf Sicherheit, Zuverlässigkeit, Skalierbarkeit oder auch Usability bezeichnet. Sie spielen eine wichtige Rolle für die Systemarchitektur. Um diese Anforderungen im Entwicklungsprozess abzubilden, gibt es verschiedene Optionen:

Man kann nicht-funktionale Anforderungen ebenso wie funktionale Anforderungen in Form von User Stories verpacken und daraus entsprechende Backlog Items ableiten.

Ebenso können sie in der sogenannten Definition of Done (DoD) erfasst werden, eine Art Liste auf der das Team für alle User Stories festlegt, wann diese als erfolgreich erledigt betrachtet werden können. Die Definition of Done enthält beispielsweise Elemente wie Programmierstandards, Testing und Dokumentationserstellung.

Eine weitere Möglichkeit zum Umgang mit nicht-funktionalen Anforderungen besteht darin, sie als notwendiges Akzeptanzkriterium (Acceptance Criteria AC) für eine User Story aufzunehmen. Erst wenn neben der funktionalen Umsetzung auch alle notwendigen Akzeptanzkriterien erfüllt sind, kann eine Anforderung als vollständig erledigt eingestuft werden.

Die nachdenkliche Muse des Product Owners #

Lieber PO, sag einmal … #

wieviel Prozent deiner Arbeitszeit wendest du dafür auf, um mit dem Team und deinen Stakeholdern über dein Projekt zu kommunizieren?
wer außer dir darf in dein Product Backlog schreiben?
könnte es Sinn machen, die Sprintlänge im Projekt zu verkleinern?
welche Hilfsmittel und Tools verwendest du, um deine Arbeit zu gestalten? Bist du damit noch effektiv?
gibt es Personas in deinem Projekt?
wie häufig mussten User Stories schon zerschnitten werden?
war das vielleicht noch nicht häufig genug?
organisierst du dich mit deinen Stakeholdern und dem Team in einem gemeinsamen Wiki?
spielt Ihr noch Planning Poker oder macht Ihr schon Magic Estimation?
bist du immer bei jedem Sprint Planning und jedem Sprint Review zuverlässig dabei? … kennt dein Team die Vision deines Projekts/Produkts? … kennen deine Stakeholder die Vision des Projekts/Produkts? … wie häufig werden die Projektfortschritte an den Markt released? … ist das häufig genug, um am Markt zu bestehen? … wann hast du die letzte (Release-)Party für das Team organisiert? … es wird mal wieder Zeit dafür, nicht wahr? … bist du durchsetzungsstark und kannst du gleichzeitig alle Interessen mit einbeziehen? … kennst du Methoden des Konsent und des systemischen Konsensierens? … ich finde dich ja toll – aber hast du auch einen Co-PO, der dich bei Krankheit und Urlaub vertreten kann? … was hält eigentlich das Team von dir? … bist du bei den Projekt-Retrospektiven mit dabei? … wie hoch ist die Defekt-Rate in deinem Projekt? … budgetierst du regelmäßig & proaktiv User Stories zum Abbau technischer Schulden? … betreibst du aktiv Erwartungsmanagement gegenüber den Stakeholdern in Hinblick auf Releases? … machst du regelmäßig mit dem Team Backlog Grooming? … wie häufig groomst du und wie lange? … bist du eigentlich noch on budget mit deinem Projekt? … kennst du die Ansichten und Meinungen der Nutzer deines (Online-)Projekts? … arbeitest du Feedback deiner Nutzer in das (Online-)Projekt mit ein? … ist dein Product Backlog stets mit werthaltigen User Stories gefüllt? … was passiert, wenn dem mal nicht so ist? … begleitet ein (externer) Coach dein Projekt? … wie drückst du deine Dankbarkeit gegenüber dem Team aus? … kennt dein Team deine Sprint-Ziele? … hast du eine Definition of Ready für User Stories? … aber wenigstens eine Definition of Done für User Stories? … geben deine Stakeholder/Projektsponsoren dir aktives (positives) Feedback? … kennt dein Team das Feedback deiner Stakeholder/Projektsponsoren? … kannst du nachts gut schlafen? … bist du für dein Team gut erreichbar? … weist dich das Team auf Unstimmigkeiten in User Stories hin? … sind deine Akzeptanzkriterien klar definiert? Könntest du sie noch verbessern? … ist dein Projekt mit deinem Team Role Model für andere im Unternehmen? … warum (nicht) ? … sind Nicht-Ziele des Projekts klar definiert? … welche Maßnahmen ergreift Ihr zur Vermeidung/Senkung technischer Schulden? … dein wievieltes Projekt als PO ist das jetzt aktuell? … fühlst du dich wohl damit? … Lieber PO, du machst einen klasse Job. Weiter so!

https://www.knowledgehut.com/interview-questions/product-owner

https://doitsmartly.ru/all-articles/management/99-agile/117-decomposition-techniques.html

https://age-of-product.com/42-scrum-product-owner-interview-questions/ https://www.knowledgehut.com/interview-questions/product-owner

https://i.imgur.com/KSRkPTA.png Введение в Project Management