Was tun, wenn der Product Owner krank ist?

Einfache Frage. Wie führen Sie das Sprint Review und die Sprintplanung durch?

Schon mal was von Konferenzbrücken gehört?
@WyattBarnett nein was ist das?
Telefonkonferenzen. Keine Entschuldigung dafür, 2011 kein Treffen zu machen. Es sei denn, Sie sitzen in einem Flugzeug, und das ist irgendwie dürftig.
Wenn jemand krank ist, wird er höchstwahrscheinlich nicht an einer Telefonkonferenz teilnehmen.
Warum habe ich diesen intensiven Drang zu sagen: „Schick ihm eine Genesungskarte oder besuche ihn im Krankenhaus“
@WyattBarnett, es gibt Zeiten, in denen die Leute nicht verfügbar sind. Ich versichere Ihnen, dass meine Kollegin, als sie an Krebs erkrankte, nicht in der Lage war, Anrufe bei der Arbeit entgegenzunehmen oder an Telefonkonferenzen teilzunehmen. Als meine Geliebte starb, war ich dazu nicht in der Lage. Es gibt keine Entschuldigung dafür zu denken, dass Menschen Maschinen sind, die 24 Stunden am Tag verfügbar sind, egal was passiert.
Als Product Owner muss ich gesund werden, damit ich am Iterationsplanungsmeeting teilnehmen kann. 5 Punkte.
Verwandtes und mögliches Duplikat: pm.stackexchange.com/questions/27590/…

Antworten (2)

Darauf sollte der Risikomanagementplan des Projekts eingehen. Wenn Sie weder auf Projekt- noch auf Iterationsebene Personen identifiziert haben, die für den Erfolg entscheidend sind, und Methoden, um die Arbeit fortzusetzen, wenn sie nicht verfügbar sind, ist dies der perfekte Zeitpunkt dafür, sobald das Team da ist. Eines der Dinge, die Sie tun sollten, ist, Alternativen für Rollen zu identifizieren, damit keine Position eins zu tief ist.

In der Zwischenzeit sollte das gesamte Team größtenteils weitermachen können.

Der Scrum Master kann Ihr Sprint Review moderieren. Wenn Sie einen Kunden- oder Benutzervertreter zur Verfügung haben, wäre dies von Vorteil, wenn Sie den Beteiligten Ihre Funktionen demonstrieren und Feedback erhalten. Da der Product Owner nicht anwesend ist, könnte es eine gute Idee sein, irgendwie eine Aufzeichnung des Meetings zu machen – eine Videoaufzeichnung, eine Audioaufzeichnung, eine Bildschirmaufnahme und Notizen – und sie nach ihrer Rückkehr zur Überprüfung vorzulegen.

Wenn Ihr Product Owner an Ihrer Sprint Retrospektive beteiligt ist, würde ich das auch wie geplant weiterführen, nur ohne den Product Owner. Schließlich reflektieren Sie die Leistung Ihres Teams und wie Sie mit Problemen umgegangen sind und Erfolge erzielt haben. Der Scrum Master als Hüter des Prozesses sollte sich der Ziele in Bezug auf Story Points, Features und aufgetretene Probleme bewusst sein. Da kein kritischer Stakeholder anwesend ist, würde ich erneut empfehlen, eine Art Umriss der Diskussion und der Ergebnisse festzuhalten.

Wenn Ihr Sprint Review und Ihre Sprint Retrospektive ein Meeting sind, sollten Personen, die nicht direkt am Prozess beteiligt sind, nicht an der Retrospektive teilnehmen. Beispielsweise habe ich erwähnt, dass anstelle des Product Owners ein anderer Vertreter der Kunden- oder Benutzergruppe Teilnehmer am Sprint Review sein könnte. Wenn diese Person nicht eng mit dem Team zusammengearbeitet hat, wird sie gebeten, die Retrospektive still zu beobachten (was nützlich sein kann, um sie als alternativen Product Owner zu schulen) oder den Raum vollständig zu verlassen.

Nach der Rückkehr des Product Owners würde ich empfehlen, dass der Scrum Master und vielleicht ein Mitglied des Entwicklungsteams ihn über die Ergebnisse des Sprint-Reviews und der Sprint-Retrospektive informieren. Mit angemessenen Aufzeichnungen und Besprechungsnotizen sollte der Product Owner in der Lage sein, diese zu lesen und eine kurze Diskussion mit dem Scrum Master und dem Teammitglied zu führen, wenn es Fragen oder Bedenken gibt.

Was die Sprint-Planung betrifft, so ist es die Aufgabe des Product Owners, das Product Backlog kontinuierlich mit neuen Storys zu aktualisieren und die Priorität aufrechtzuerhalten. Das Product Backlog sollte zu jedem Zeitpunkt priorisiert werden. Ihr Scrum Master sollte in der Lage sein, historische Projektdaten zu übernehmen und das Team im Schätzprozess von Stories zu führen. Dann kann das Team die entsprechende Anzahl von Storys basierend auf früheren Sprints abrufen.

Ich stimme der Überprüfung zu. Aber für die Planung, ohne dass der PO Details zu den Anforderungen enthält, kann es schwierig sein, ein Element des Product Backlogs zu interpretieren, oder?
@xsAce Dokumentation?
@xsAce - Ich weiß nicht, welches Tool Sie verwenden, aber unser Tool ermöglicht die Priorisierung des Backlogs und der Icebox.
@Chad Wir verwenden einfach post it
@xsAce Eine gepostete Geschichte sollte ausreichend detailliert sein, um sie zu verstehen. Auch hier geht es um das Risikomanagement, und es könnten einige Fragen auftauchen, aber wenn Sie sich in einer Situation befinden, in der Sie 0 Fortschritte erzielen können, stimmt etwas mit der Art und Weise, wie Sie das Projekt durchführen, nicht.
@xsAce - Ich finde es schwer zu glauben, dass Sie alle Informationen erfassen können, die Sie benötigen, um ein Softwareentwicklungsprojekt effektiv zu verwalten, wenn Sie Post-Its verwenden, um Ihre Geschichten zu verwalten, Ihren Fortschritt zu verfolgen und Ihre Arbeit zu priorisieren.
@ThomasOwens Danke, nun, die Sache ist die, dass wir alle ausreichenden Story-Details WÄHREND der Planung definieren, nicht vorher. Ich meine, hier findet der Wissenstransfer vom PO zum Team statt. Deshalb fällt es mir schwer, eine Planung ohne ihn zu halten. Ich bin nicht in einer Situation, in der wir nichts zu tun haben, es gibt immer Platz für Arbeit, Schuldenabbau usw. Aber neue Geschichten aufzunehmen und einen neuen Sprint abzuhalten, der einen direkten Mehrwert bringt, ist etwas, was ich habe schwer zu sehen passieren.
@xsAce Ich würde empfehlen, dass die PO kontinuierlich dafür sorgt, dass die Geschichten mit der höchsten Priorität ausreichend dokumentiert werden, damit sie in seiner Abwesenheit entwickelt und getestet werden können. Obwohl der Wissenstransfer bei einem Planungstreffen gut ist, um alle auf eine gemeinsame Seite zu bringen, bin ich der Meinung, dass Sie genug Informationen haben sollten, um etwas zu tun, auch wenn es sich um Vorarbeiten handelt. Wenn Sie am Ende Ihres geplanten Sprints aufgrund einer fehlenden Person nichts Wertvolles liefern können, müssen Sie Ihren Prozess überdenken, um dieses Allwissen in einer Person zu eliminieren.
@ThomasOwens Ich stimme zwar zu, dass eine vermisste Person den Sprint nicht unterbrechen sollte, aber wir sprechen hier nicht von einem Teammitglied. Ich meine, die PO-Rolle ist entscheidend und vom Prozess ERFORDERLICH. Wenn es so einfach wieder aufgegriffen werden könnte, bräuchten wir es gar nicht erst. Die Verantwortung würde direkt vom Team geteilt. Ich denke, die Lösung liegt eher in der Gesellschaft und darin, jemanden zu finden, der die Bestellung vorübergehend ersetzt, als den Prozess erneut zu überprüfen. Aber danke
@xsAce Der PO ist Mitglied des Scrum-Teams. Ein Scrum-Team besteht aus dem Product Owner, dem funktionsübergreifenden Produktentwicklungsteam und dem Scrum Master. Der PO könnte in einigen Fällen auch Mitglied des Produktentwicklungsteams sein. Unabhängig davon, wer der Product Owner ist und welche anderen Rollen er ausfüllt, ist es wichtig, dass Sie Zeiten berücksichtigen, in denen er nicht verfügbar ist, und dies als Risiko behandeln, für das es eine Minderungsstrategie gibt. Eine einfache Minderungsstrategie besteht darin, einen alternativen PO zu haben, der über alle Entscheidungen und Mitteilungen informiert ist, aber keine Entscheidungen trifft, es sei denn, dies ist erforderlich.
@ThomasOwens okay, ich habe jetzt deinen Punkt verstanden.
+1 für den Kernpunkt "... einen alternativen PO zu haben, der über alle Entscheidungen und Mitteilungen informiert ist, aber keine Entscheidungen trifft, es sei denn, dies ist erforderlich."
„Dein Sprint Review kann vom Scrum Master durchgeführt werden, der dafür gut geeignet erscheint. Schließlich reflektierst du die Leistung deines Teams und wie du mit Problemen umgegangen bist und Erfolge erzielt hast. Der Scrum Master als Wächter des Prozesses, sollte sich der Ziele in Bezug auf Story Points, Features und aufgetretene Probleme bewusst sein. Eine Zusammenfassung kann dem Product Owner nach seiner Rückkehr vorgelegt werden.“ ..... Hey Thomas, wolltest du hier "Sprint Retrospektive" sagen? Es hört sich so an, als ob Sie von der Retrospektive sprechen, nicht von der Sprint-Demo (auch bekannt als Sprint-Review).
@ jmort253 Im letzten Scrum-Team, in dem ich war (das war vor ~ 9 Jahren), war es dasselbe. Am Ende des Sprints gab es 1 Meeting, bei dem das Team die fertigen Stories demonstrierte und bewertete, was während des Sprints richtig/falsch gelaufen ist. Es war sowohl eine Produkt- als auch eine Prozessüberprüfung und Neubewertung vor der Sprintplanung. Basierend auf anderen Dingen, die ich lese, ist es nicht ungewöhnlich, die Demonstration des Produkts (die Überprüfung) und die Überprüfung der Ausführung (die Retrospektive) in einem Meeting zu kombinieren, und ich würde dazu ermutigen, sicherzustellen, dass alle Beteiligten anwesend sind und beteiligt.
@ThomasOwens - Soweit ich gelesen habe, betrifft die Sprint-Retrospektive nur das Scrum-Team; Andernfalls fühlen sich die Mitarbeiter möglicherweise nicht wohl dabei, über Probleme zu sprechen, die sie haben, insbesondere wenn einige der Stakeholder Manager, Führungskräfte oder Kunden sind. Laut Scrum Guide sind Review und Retrospektive getrennte Meetings, und laut Michael James, Mike Cohn und meinem CSM-Trainer nehmen nur das Scrum-Team (und in einigen Fällen nur das SM- und das Entwicklerteam) an der Retrospektive teil.
[Fortsetzung] – Es könnte sich lohnen, klarzustellen, dass Sie eine modifizierte Version von Scrum praktiziert haben, damit die Leute nicht zwischen Überprüfung und Retrospektive verwechselt werden, wenn es um Scrum geht. Ich hoffe, das hilft bei der Klärung und vielen Dank für Ihre Beiträge. Sie helfen uns sehr bei unserer Umstellung auf Agile und Scrum!
@ jmort253 Danke dafür. Ich werde zur Verdeutlichung bearbeiten. Und wenn Sie noch etwas weiter nachforschen, scheint es, als ob die Teilnehmer an einer Retrospektive ein umstrittenes Thema sein könnten - einige Leute sagen, dass es einen Mehrwert für eine Bestellung bringt, während andere behaupten (wie Sie sagen), dass es nur für das Team ist. Ich werde diese Antwort jetzt klären. Ich würde mich über Feedback zu den Änderungen freuen.

Es ist offensichtlich, dass nichts gleich sein wird, wenn PO nicht verfügbar ist. Aber natürlich sollte sich das Team bemühen, den Schaden im Sprint zu verringern. Ich denke, SM sollte das Team so führen, dass das Team an geklärten Aufgaben arbeiten und die unklaren Aufgaben der Zeit überlassen kann, zu der PO verfügbar ist. Beim Scrum wird das Projekt Schritt für Schritt fortgesetzt, indem einige Teile später entschieden werden. Höchste Verfügbarkeit ist also entscheidend.

Was tun, wenn der Product Owner krank ist?
AntwortenHierDatenschutz-Bestimmungen1y, 3v