Wie löse ich widersprüchliche Anforderungen von Product Owner und Team Lead?

Nehmen wir an, ein Product Owner, der alle Arbeiten genehmigt, bevor sie in die Produktion gehen, schreibt die Anforderungen als X.

Der Teamleiter (leitender Entwickler), der alle Codeänderungen genehmigt, sagt „do Y“, was im Widerspruch zu X steht.

Wie lösen Sie widersprüchliche Richtungen zwischen zwei Personen, die beide die Autorität über ein Projekt haben?

Haben Sie einen von ihnen darauf hingewiesen, dass es einen Widerspruch in den Anforderungen gibt?
Sind das technische Anforderungen oder funktionale Anforderungen? Der Product Owner ist dafür verantwortlich, was das Produkt tut, der Teamleiter ist dafür verantwortlich, wie es es tut.

Antworten (2)

Dies ist ein Fall, in dem Sie die beiden zuerst in einen Raum bringen und sie sich austoben lassen.

In einem agilen Workflow definiert der Product Owner die Anforderungen. Der Teamleiter hat eine Stimme, während die Story ausgearbeitet wird ( so wie alle Teammitglieder ), aber sobald die Story im Sprint ist, sollten sich die Anforderungen nicht ändern .

Wenn die beiden sich nicht einigen können, sprechen Sie mit Ihrem Vorgesetzten darüber , da dies möglicherweise ein Problem ist, das Sie nicht selbst lösen können.

Im Moment scheint es jedoch, dass Ihr Teamleiter daran erinnert werden muss, dass der Product Owner die Anforderungen definiert und es Sache des Teams als Ganzes ist, dies umzusetzen (umzusetzen).

Hinweis : Wenn es einen technischen Grund gibt, dass eine Anforderung möglicherweise geändert werden muss, sollte dies vor der Codierung mit dem Product Owner besprochen werden .

Es ist in Scrum möglich, dass sich Anforderungen während eines Sprints aufgrund von Dingen ändern, die während des Sprints gelernt wurden, und es ist auch nicht unbedingt eine schlechte Sache.
@Erik hat als Ausnahme und nicht als Norm zugestimmt.
@Erik Per Definition möchten Sie, dass die Anforderungen für die Elemente, die während des Sprints erstellt werden, in Stein gemeißelt sind. Andernfalls sind diese Anforderungen noch nicht gut genug verstanden, um dieses Element in einem Sprint zu übernehmen. Einer der wichtigsten Punkte bei Scrum ist, dass bis zum Sprint alles flüssig ist, sodass man einigermaßen sicher sein kann, dass man tatsächlich ein den Anforderungen entsprechendes Inkrement liefern kann. Wenn sich die Anforderungen ändern, müssen Sie neu bewerten, ob Sie sie erfüllen können oder nicht, was Zeit kostet, um das Inkrement zu erstellen.
@Cronax Nein, tust du nicht. Wenn etwas Seltsames passiert und Sie sich entscheiden müssen, ob Sie die Anforderungen ändern oder das Falsche erstellen möchten, möchten Sie die Anforderungen ändern. Wie Neo sagt, sollte es eine Ausnahme sein, aber es ist immer noch besser als die Alternative, wenn es passiert.
@Erik Ich sage, dass Sie nicht möchten, dass dies ein Standardarbeitsablauf ist, da Sie zu diesem Zeitpunkt nie sicher sein werden, ob Sie tatsächlich einen Sprint liefern können oder nicht. Ich würde in der Tat argumentieren, dass das angestrebte Vorgehen eher darin besteht, den Sprint komplett zu stoppen und, wenn das Feature immer noch der wichtigste und angemessenste Weg zur Wertschöpfung ist, es ausreichend zu verfeinern und dann zu starten, als die sich ändernden Anforderungen einfach so zu nehmen neuer Sprint. Das Team verpflichtet sich zum Sprint-Backlog, wenn Sie die Anforderungen ändern, tun Sie nicht mehr das, wozu Sie sich verpflichtet haben.
Wenn wir das weiter besprechen müssen, würde ich vorschlagen, dass wir es in einen Chat verschieben.
@Cronax-Teams haben sich seit 2011 nicht mehr zu Sprint-Rückständen verpflichtet :)
@Erik das Wort Engagement war schlecht gewählt, das Konzept steht immer noch: Ohne einen vereinbarten Umfang können Sie niemals einen erfolgreichen Sprint abliefern.

Sie tun, was Ihr Teamleiter sagt. Sie weisen ihn darauf hin, aber am Ende gibt es eine Befehlskette, und Sie sind in einem Team und er ist der Teamleiter, und solange Sie darauf hinweisen können, dass Sie das Problem angesprochen haben, ist es seine Aufgabe, seine Verantwortung und damit auch sein Versagen.

Beachten Sie, dass Check-in-Kommentare ein großartiger und unveränderbarer Ort sind, um darauf hinzuweisen, dass diese Änderung den Anforderungen des Product Owners widerspricht, aber vom Teamleiter gefordert wird.

Wie löse ich widersprüchliche Anforderungen von Product Owner und Team Lead?
AntwortenHierDatenschutz-Bestimmungen1y, 0v