Sollten Entwickler während der Implementierung von Product Backlog Items zur Klärung direkt mit Stakeholdern kommunizieren. Oder sollte die gesamte Kommunikation über den Product Owner laufen?
Auf dem Scrum Guide können wir folgendes lesen:
Einerseits sollte der Product Owner:
Der Product Owner ist die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist. Das Product Backlog Management umfasst:
Produkt-Backlog-Einträge klar ausdrücken;
...
Andererseits:
Der Product Owner kann die oben genannten Arbeiten durchführen oder das Entwicklungsteam damit beauftragen. Der Product Owner bleibt jedoch verantwortlich.
Theoretisch kann das Entwicklungsteam also mit Stakeholdern zur Klärung des PBI kommunizieren.
Aber ist das eine gute Praxis? Ich denke immer, dass der Product Owner der einzige Einstiegspunkt für alle Anforderungen ist.
Ich sehe in dieser Situation 4 Möglichkeiten:
Entwickler können PBIs während der Implementierung mit Stakeholdern klären. Aber in diesem Fall besteht das Risiko, dass die Sicht der Stakeholder zu diesem PBI möglicherweise anders ist als die Sicht des Product Owners (z ). Der Product Owner kann die Kontrolle über den Umfang der PBIs verlieren.
Entwickler können PBIs nur mit dem Product Owner klären. So arbeite ich immer. Aber in einem Fall, den ich kenne, hat der Product Owner physisch nicht genug Zeit, um all diese Arbeit zu erledigen. Was sollen wir in diesem Fall tun?
Bitten Sie die Entwickler, mehr Initiative zu ergreifen und alle Probleme nach eigenem Ermessen zu lösen.
Erzwingen Sie, PBI sehr gut zu definieren, bevor Sie es in Sprint nehmen, und verbieten Sie den Entwicklern, nachdem es genommen wurde, irgendwelche Fragen darüber zu stellen (es ist kein Witz, es ist die reale Situation. Ich habe in diesem Artikel darüber gelesen . Leider ist es nur auf Russisch, also glauben Sie mir einfach, die beschriebene Situation ist der wahre Fall).
Also, wie sollen Entwickler PBI während seiner Implementierung klären? Vielleicht gibt es eine bessere Lösung, als oben beschrieben?
Wichtiger Hinweis: Ich spreche von PBIs, die sich bereits im Sprint befinden und während der Arbeit einer zusätzlichen Klärung bedürfen.
Ausgezeichnete Frage:
Um die Frage direkt zu beantworten, ja, die Entwickler können und sollten nach Möglichkeit mit dem Kunden sprechen. Wie Sie jedoch angemerkt haben, kann die Logistik dafür schwierig sein.
Etwas, das immer häufiger verwendet wird und dies direkt anspricht, ist das Product Owner Team (auch als agiles Geschäftsteam und agiles Kundenteam bekannt).
Product Owner Team: Dies ist eine direkte Anerkennung dafür, dass ein Product Owner oft nicht in der Lage ist, der „Single Owner“ zu sein. Sei es aus Mangel an Wissen oder weil zu viele Köche in der Küche stehen (in Großunternehmen bekommt der PO selten die endgültige Entscheidung).
Ein POT baut ein Team um den PO herum auf, dessen Produkt das Backlog ist. Die Aufgabe des POT besteht darin, sicherzustellen, dass das Backlog gut geordnet und definiert ist und der Definition von „bereit“ oder einer Story entspricht, die vom Entwicklungsteam ohne weitere Arbeit aufgenommen und ausgeführt werden kann.
Der POT besteht aus dem PO, einem technischen "Architekten", einem QA-Vertreter und möglicherweise dem Kundensupport, dem Betrieb oder sogar dem Kunden. Die Rolle des technischen Architekten kann entweder eine leitende Person mit technischen und betriebswirtschaftlichen Kenntnissen (häufiger in größeren Unternehmen), tatsächliche Vertreter des Entwicklungsteams oder beides sein. Auf diese Weise kann eine Geschichte vollständig untersucht werden, bevor Sie überhaupt zum Sprint-Planungsmeeting kommen.
Der POT ist die Methode, die ich empfehle, den Kunden für Product Backlog Items zu engagieren.
Als Scrum Master ermutige ich die Teammitglieder, mit den Stakeholdern zu sprechen. Aber ich schlage vor, dass sie es entweder in Anwesenheit des Product Owners tun oder den Product Owner so schnell wie möglich nach dem Ende des Gesprächs informieren.
Der Product Owner sieht das große Ganze. Was sich für einen Entwickler wie eine durchaus vernünftige Bitte anhört, könnte im Kontext von Gesprächen mit anderen Interessenvertretern eine schlechte Idee sein.
Dies ist keine Kritik an Entwicklern. Sie haben einfach nicht die Zeit, ständig Ideen von Stakeholdern auszutauschen und ein Verständnis für den Markt für das Produkt aufzubauen.
Die Rolle des Product Owners ist Vollzeit und sehr anspruchsvoll. Die Entwickler sollten versuchen, den Product Owner bei jeder Gelegenheit zu unterstützen, aber niemals umgehen.
Joel Bancroft-Connors