Wann kommt Product Owner ins Daily Scrum? Ein paar Gedanken

Die tägliche Scrum-Zusammenkunft, auch bekannt als das Daily Scrum, ist ein zentrales Element im Scrum-Framework. Es bietet den Teammitgliedern die Möglichkeit, sich über das Sprint Ziel, Hindernisse und weitere relevante Themen auszutauschen. Doch eine Frage taucht manchmal auf: Sollte der Product Owner auch an diesem täglichen Event teilnehmen? Wann muss der Product Owner am Daily Scrum teilnehmen - falls er es jemals muss? Gehen wir darauf mal tiefer ein.

Gemäß dem Scrum Guide ist es dem Product Owner erlaubt, am Daily Scrum teilzunehmen, insbesondere wenn er aktiv an den Aufgaben des aktuellen Sprints arbeitet. Es gibt jedoch keine strikte Anforderung für die Anwesenheit des Product Owners. Die Entscheidung darüber, ob der Product Owner am Daily Scrum teilnehmen sollte, obliegt in gewisser Weise dem gesamten Team.

Es ist verständlich, dass einige Entwicklungsteams den Product Owner gerne dabei hätten, um schnelle Antworten auf Fragen zu erhalten oder Klarstellungen zum Product Backlog zu bekommen. Dies ist erlaubt, aber der Product Owner sollte sich darauf beschränken, die Aktivitäten der Entwickler zu unterstützen und nicht allzu aktiv im Meeting zu intervenieren.

Es gibt jedoch Teams, die bewusst darauf verzichten, den Product Owner am Daily Scrum teilnehmen zu lassen. Dies könnte damit zusammenhängen, dass der Product Owner enge Verbindungen zu Management und Stakeholdern hat, was die Offenheit der Entwickler beeinträchtigen könnte. Auch das ist in Ordnung.

Während des Daily Scrums ist es entscheidend, dass die Entwickler frei und ehrlich über Blockaden, Hindernisse und Fortschritte sprechen können. Wenn die Anwesenheit des Product Owners als unproduktiv empfunden wird, sollte es den Entwicklern überlassen bleiben, zu entscheiden, ob der Product Owner anwesend sein sollte.

Also, wann muss der Product Owner am Daily Scrum teilnehmen? Um es nochmal kurz zusammenzufassen, theoretisch muss er das nie.

Es gibt jedoch Situationen, in denen die Anwesenheit des Product Owners beim Daily Scrum sinnvoll sein kann. Zum einen kann dies die Teamkohäsion verbessern, wenn der Product Owner als stiller Zuhörer teilnimmt. Dies ist besonders wichtig, wenn es Anzeichen für eine wachsende Distanz zwischen dem Product Owner und dem Entwicklungsteam gibt. Durch die Teilnahme an einigen Daily Scrums kann der Product Owner diese Lücke schließen und die Kommunikation fördern.

Ein weiterer wichtiger Grund für die Anwesenheit des Product Owners ist die Möglichkeit, frühzeitig Feedback zu erhalten. Durch aktives Zuhören während des Daily Scrums kann der Product Owner wertvolle Einblicke in die täglichen Aktivitäten, Kapazität und Geschwindigkeit des Entwicklungsteams gewinnen. Dieses frühe Feedback ermöglicht es dem Product Owner, User Stories zu verbessern und Anpassungen am Backlog vorzunehmen.

In gewisser Weise kann die Teilnahme des Product Owners am Daily Scrum also helfen, innerhalb des Teams die kurzen Iterationsschleifen und Feedbackzyklen vorzuleben, die hoffentlich auch mit Kundenfeedback bestehen.

„Viele Teammitglieder trauen sich nicht, den Mund aufzumachen!“

Diese Challenge lösen

„Wir entdecken zu viele unerwartete Probleme und Bugs zu einem späten Zeitpunkt!“

Diese Challenge lösen

„Warum brauche ich manchmal Stunden, um eine einfache Retrospektive vorzubereiten?“

Diese Challenge lösen

Wenn ihr grundsätzlich eure Teamzusammenarbeit verbessern möchtet, eure Teamentwicklung messbarer machen möchtet, dann könnte Echometer für euch interessant sein - besonders dann, wenn ihr eventuell keinen dedizierten Vollzeit Scrum Master in eurem Team habt.

Echometer ist ein digitales Tool, dass agilen Team Leads bei agilen Retrospektiven und Team Health Checks hilft. Egal ob Remote, hybrid oder vor Ort: Es macht Team-Coaching messbar und professionalisiert so deine Arbeit, während es dir nebenbei sehr viel Arbeit spart. Schau einfach mal auf unsere Website, um mehr zu erfahren: www.echometerapp.com.

Im Zweifel, seid agil: Holt den Product Owner experimentell mit ins Daily Scrum über zum Beispiel einen Sprint, und reflektiert in der nächsten Retro, ob oder wie ihr dies beibehalten möchtet.

Christian Heidemeyer, Psychologe & Scrum Master

Zusammenfassend lässt sich sagen, dass die Teilnahme des Product Owners am Daily Scrum keine feste Regel ist, sondern von verschiedenen Faktoren abhängt. Die Entscheidung sollte im Einklang mit der Teamdynamik und den Bedürfnissen des Projekts getroffen werden. Es geht nicht nur darum, teilzunehmen, sondern darum, die richtige Balance zu finden, um die Zusammenarbeit und den Informationsaustausch im Entwicklungsprozess zu fördern.

Zuletzt, nochmal der Hinweis: Falls du mal ausprobieren möchtest, wie es sich anfühlt dein Team mit unserem Tool weiterzuentwickeln: Du kannst im Folgenden ohne Login eine agile Retrospektive starten, in dem Fall den “Keep, Stop, Start” Workshop. 

Alternativ leite gerne einfach mal unsere Website an verantwortliche Kolleg*innen weiter: www.echometerapp.com.

How to

Keep Stop Start Retro: So läuft die Retro ab

1. Random Icebreaker (2-5 Minuten)

   Echometer stellt euch einen Generator für zufällige Check-in-Fragen bereit.

2. Review der offenen Maßnahmen (2-5 Minuten)

   Bevor man mit neuen Themen loslegt, sollte man einmal zur Wirksamkeitskontrolle darüber sprechen, was aus den Maßnahmen aus vergangenen Retrospektiven geworden ist. Echometer listet automatisch alle offenen Action Items aus vergangenen Retros auf.

3. Retro-Themen besprechen

   Nutzt die folgenden offenen Fragen, um eure wichtigsten Erkenntnisse zu sammeln. Zuerst verdeckt jeder für sich. Echometer erlaubt es jede Spalte des Retro-Boards einzeln aufzudecken, um das Feedback dann anschließend zu präsentieren und zu gruppieren.

   • Continue: Was sollten wir beibehalten?
   • Stop: Womit sollten wir aufhören?
   • Start: Was sollten wir anfangen zu tun?

4. Catch-all Frage (Empfohlen)

   Damit auch sonstige Themen einen Platz haben:

   • Über was möchtest du sonst noch in der Retro reden?

5. Priorisierung / Voting (5 Minuten)

   Auf dem Retro-Board in Echometer könnt ihr das Feedback ganz einfach mit dem Voting priorisieren. Das Voting ist natürlich anonym.

6. Maßnahmen definieren (10-20 Minuten)

   Über das Plus-Symbol an einem Feedback kann man eine verlinkte Maßnahmen erstellen. Noch nicht sicher welche Maßnahme die richtige wäre? Dann öffne über das Plus-Symbol stattdessen ein Whiteboard zu dem Thema um Kernursachen und mögliche Maßnahmen zu brainstormen.

7. Checkout / Closing (5 Minuten)

   Echometer ermöglicht euch anonymes Feedback vom Team einzusammeln, wie hilfreich die Retro war. Daraus entseht der ROTI-Score ("Retrun On Time Invested"), den ihr über die Zeit tracken könnt.

Keep Stop Start Retro

Continue: Was sollten wir beibehalten?

Stop: Womit sollten wir aufhören?

Start: Was sollten wir anfangen zu tun?

Diese Retro jetzt öffnen Anpassen...