Als Tech Lead in einem „Scrum“-Team nerven mich einige festgelegte Regeln.
Es ist festgelegt, dass nur Product Owner, Business Analyst und Scrum Master (und schließlich der Produktmanager) am User-Story-Priorisierungsprozess (Backlog-Priorisierung) teilnehmen.
Sie sortieren US anhand von Story Points, ohne weitere softwareorientierte Fakten und Kenntnisse.
Es ist erwähnenswert, dass diese Story Points aus einem schnellen und wahrscheinlich „blinden“ Makroschätzungsprozess hervorgegangen sind, nicht aus einem tiefen.
Sie beurteilen anhand dieser Makroschätzungen, welche wertvollen US-Dollar geliefert werden könnten und wann .
Ich bemerke, dass ihre Entscheidung oft auf falschen Annahmen und falschen Hypothesen basiert; was zu einer Neueinstellung der Sortierung führt und somit Zeit verschwendet.
Sind Sie der Meinung, dass ein technischer Leiter (oder ein anderer qualifizierter Entwickler) Teil dieses Priorisierungsprozesses sein sollte, um die Priorisierung basierend auf Programmierkenntnissen zu unterstützen?
Wie ein Garant für Machbarkeit.
Der Scrum Guide ist zu diesen Aspekten sehr klar :
Product Backlog Refinement ist der Akt des Hinzufügens von Details, Schätzungen und Reihenfolgen zu Elementen im Product Backlog. Dies ist ein fortlaufender Prozess, in dem der Product Owner und das Entwicklungsteam an den Details der Product Backlog-Einträge zusammenarbeiten.
Das Management des Product Backlogs umfasst... das Ordnen der Einträge im Product Backlog, um Ziele und Missionen bestmöglich zu erreichen; ...wer die Priorität eines Product Backlog Items ändern möchte, muss sich an den Product Owner wenden.
Das Entwicklungsteam ist für alle Schätzungen verantwortlich. Der Product Owner kann das Entwicklungsteam beeinflussen, indem er ihm hilft, Kompromisse zu verstehen und auszuwählen, aber die Leute, die die Arbeit ausführen, treffen die endgültige Schätzung.
Der Scrum Guide schweigt sich jedoch zu technischen Schulden aus. Im Scrum Guide werden technische Schulden oder ähnliches nicht erwähnt. Wenn das Entwicklerteam der festen Überzeugung ist, dass eine technische Schuld priorisiert werden muss, da es sonst später zu größeren Problemen kommen wird („Ein Stich in der Zeit spart neun“), sind sie machtlos, dies zu priorisieren. Wenn der PO sich weigert, den Ansichten des Entwicklerteams zu diesem Aspekt genügend Aufmerksamkeit zu schenken, rate ich meinen Entwicklerteams, die technische Schuld in ihre Einschätzung der damit verbundenen Funktionen einzubeziehen.
Also die Antwort auf deine Frage:
Denken Sie, dass ein technischer Leiter (oder ein anderer qualifizierter Entwickler) Teil dieses Priorisierungsprozesses sein sollte ...
ist JA , haben Sie ein Teilnahmerecht. Der Scrum Guide sagt es.
Es hört sich so an, als ob bei Ihrem Scrum-Prozess eine ganze Menge schief läuft.
Es ist wichtig zu erkennen, dass ein Product Backlog nicht priorisiert wird. Es ist bestellt. Es gibt nirgendwo im Scrum Guide einen Hinweis auf ein priorisiertes oder nach Priorität geordnetes Product Backlog. Im Abschnitt des Scrum Guide über einen Product Owner wird impliziert, dass einzelne Product Backlog Items eine Priorität haben. Die erforderlichen Attribute eines Product Backlog Items sind jedoch eine Beschreibung, eine Reihenfolge, eine Schätzung und ein Wert.
Der Product Owner ist die Person, die für die Verwaltung des Product Backlogs verantwortlich ist. Zwei der Product-Backlog-Management-Aktivitäten sind „Ordnen der Elemente im Product-Backlog, um Ziele und Missionen am besten zu erreichen“ und „Optimieren des Werts der Arbeit, die das Entwicklungsteam leistet“. Das einfache Ordnen der Arbeit basierend auf der Priorität von jemandem bringt die Elemente wahrscheinlich nicht in die Reihenfolge, die diese beiden Aktivitäten ausführen kann.
Die Verfeinerung (oder Pflege) des Product Backlogs ist eine Zusammenarbeit zwischen dem Product Owner und dem Entwicklungsteam. Dies ist eine Zeit für den Product Owner, dem Entwicklungsteam die Absichten hinter den Product Backlog Items zu erklären und sie zu überprüfen und zu überarbeiten. Dies ist auch eine gute Gelegenheit für das Entwicklungsteam, technische Abhängigkeiten zwischen Product Backlog Items hervorzuheben. Die Diskussionen während der Verfeinerungsaktivitäten sollten den Product Owner informieren, um bessere Entscheidungen bei der Bestellung des Backlogs treffen zu können.
Aufgrund der Beschreibung des Prozesses habe ich auch andere Bedenken.
Es scheinen drei produktbezogene Rollen erwähnt zu werden – Product Owner, Business Analyst und Product Manager. Es ist wichtig, dass es einen Product Owner für das Product Backlog gibt. Es ist in Ordnung, wenn diese Person von einem Team unterstützt wird. In einer skalierten Umgebung mit mehreren Teams, die an einem einzigen Product Backlog arbeiten, möchten Sie möglicherweise auch jemanden in jedes Team einbetten. Aber egal was passiert, es gibt eine Person mit der Rolle des Product Owners, wie sie in Scrum beschrieben wird.
Der Scrum Master scheint auch stark in die Arbeit eingebunden zu sein. Der Scrum Master ist ein Coach. Sie sagen nicht, was ihre Rolle bei der Verwaltung des Product Backlogs ist, aber dass sie zulassen, dass das Product Backlog ohne Eingaben des Entwicklungsteams bestellt wird, sie etablieren und lehren keine guten Verfeinerungs- oder Pflegeaktivitäten, die das Ganze einschließen Team, und sie lehren den Product Owner nicht, Wert zu optimieren und Ziele zu erreichen, ist problematisch.
Es gibt auch potenzielle Fallstricke in Bezug auf eine Führungsposition in einem Scrum-Team, aber diese können im Allgemeinen überwunden werden, indem das gesamte Team zum richtigen Zeitpunkt eingebunden wird, und können für den langfristigen Erfolg eines Teams wertvoll sein.
Beide vorherigen Antworten von Thomas und Ashok sind genau richtig (+1!) Und ich wollte nur eine etwas andere Perspektive nicht auf die Antwort selbst, sondern auf die Frage werfen.
Sollte eine technische Person am Priorisierungsprozess der User Stories teilnehmen?
Es ist festgelegt , dass nur Product Owner, Business Analyst und Scrum Master (und schließlich der Produktmanager) am User-Story-Priorisierungsprozess (Backlog-Priorisierung) teilnehmen.
Manchmal neigen Menschen dazu, an Methoden, Richtlinien, Regeln festzuhalten ... und wenn es passiert, schlage ich vor, einen Schritt zurückzutreten und erneut zu fragen, warum es Methoden gibt . Nun... sie sind nicht das Ziel , sie sind der Weg zu einem bestimmten Ziel .
Now, thinking about goals, what's the goal of the backlog prioritization? To deliver as much value as possible, optimising time and capacity. That's (potentially) applicable if the team is a Scrum, a "Scrum", an Agile, a "Fragile" or a completely chaotic team... they all want to deliver.
With that in mind, can one justify that a presence of a technical people could help to achieve the goal? If your answer is "yes", you won't need to justify that a technical people needs to attend "because Scrum says so". Depending on the environment you work, there might be more or less resistance to jargons like Scrum, but I doubt no one would be against a proposal that could add value to the team.
Mich378
Thomas Owens
Thomas Owens