Ist es sinnvoll, in Scrum User Stories eine Prioritätsbegründung zu verlangen?

Um nicht zu metaphorisch zu werden, aber ich war gerade dabei, eine Geschichte zu schreiben, um der Scrum-Software unseres Unternehmens "Prioritätsbegründung bei Änderung erforderlich" hinzuzufügen. Und ich dachte, als Scrummaster ist das nicht eines der beiden Dinge, die wir formulieren müssen, um Dinge zu erledigen (dh die User Story und die Akzeptanzkriterien). Aber ich würde es gerne zu einigen Geschichten hinzufügen, damit die PO wissen kann, warum ich denke, dass es eine höhere Priorität haben könnte, obwohl ich nicht derjenige bin, der die endgültige Priorisierung durchführt.

Sind es also nützliche Informationen in Scrum für die Person, die die Geschichte schreibt, um zu sagen, warum sie sie früher oder später brauchen, oder gehen diese Informationen normalerweise einfach im Unkraut verloren?

Antworten (2)

Die Antwort auf Ihre Frage liegt in den "3 C's der User Stories". Das erste C der User Story ist die Karte (das Ding, das Sie schreiben), das als eine Art Erinnerung und Platzhalter für das zweite C, das Gespräch, dient. Viele der Leute, die User Stories eingeführt und populär gemacht haben, haben darauf hingewiesen, dass der Grund für die Verwendung von Karteikarten darin bestand, dass nicht genügend Platz vorhanden war, um alles Notwendige auf die Karte zu schreiben, und Sie dadurch gezwungen waren, das Gespräch zu führen.

Also, speziell zu Ihren Fragen, der „damit“-Teil der kanonischen User Story auf der Karte kann auf die Notwendigkeit hinweisen, aber ein Großteil der Erklärung dafür, warum sie priorisiert werden sollte, kommt aus dem Gespräch mit dem Product Owner.

Ich denke, wir könnten diese Gespräche führen, aber die Wahrscheinlichkeit, dass er sich daran erinnert, Prioritäten zu setzen, oder sich daran erinnert, warum er Prioritäten gesetzt hat, ist ziemlich gering – vielleicht bedeutet das einfach, dass der Rückstand zu groß ist.
Das ist sehr gut möglich. Ein Teil der Aufgabe des Product Owners besteht darin, zu verstehen, was sich im Backlog befindet, und sicherzustellen, dass es angemessen priorisiert wird. Wenn er Gegenstände aus den Augen verliert und warum sie dort sind (aus irgendeinem Grund), ist das definitiv ein Problem, das behoben werden sollte.

Sehen wir uns den Scrum Guide an .

Der Product Owner ist verantwortlich für das Product Backlog, einschließlich seines Inhalts, seiner Verfügbarkeit und seiner Anordnung.

Damit der Product Owner erfolgreich ist, muss die gesamte Organisation seine Entscheidungen respektieren. Die Entscheidungen des Product Owners sind im Inhalt und in der Reihenfolge des Product Backlogs sichtbar.

Der Wunsch, „Prioritätsbegründung bei Änderung zu fordern“ verstößt gegen das Scrum-Framework.

Schauen wir uns auch die Prinzipien aus dem Manifest für agile Softwareentwicklung an.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das persönliche Gespräch.

Obwohl es das Entwicklungsteam angibt , würde es auch gelten

Ich würde es gerne zu einigen Geschichten hinzufügen, damit die PO wissen kann, warum ich denke, dass es eine höhere Priorität haben könnte

Das Aufzeichnen des Warum der Änderung der Reihenfolge (nicht der Priorität) könnte etwas sein, das der Product Owner nachverfolgen möchte, aber wahrscheinlich keine Anforderung sein sollte.

Beachten Sie auch, dass die User Story , obwohl sie häufig verwendet wird, kein Aspekt des Scrum-Frameworks ist.

+1 dafür. Wie das Product Backlog strukturiert ist, entscheidet der PO, sofern es ordinal ist. Und Backlog Refinement ist der richtige Ort, um mit dem PO darüber zu sprechen; Das Überladen von PBIs mit Informationen, die ein Gespräch sein sollten, ist ein agiles Anti-Muster.
Ist es sinnvoll, in Scrum User Stories eine Prioritätsbegründung zu verlangen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v