Aufschlüsselung der User Story – Technische Aufgabe + Benutzerfunktion

Mein Team erstellt eine Webanwendung mit der folgenden allgemeinen Benutzergeschichte:

Als Benutzer hätte ich gerne die Möglichkeit, Komponenten aus einem bestimmten Land massenweise auszuschließen.

Die Arbeit gliedert sich in zwei unterschiedliche Aufgaben.

  1. Erstellen Sie die Webanwendungsfunktion, die Komponenten nach Land ausschließt.
  2. Abrufen von Komponenten - Landesverbandsdaten auf täglicher Basis

Zuerst habe ich begonnen, dies in zwei User Stories aufzuteilen. Die zweite Aufgabe passt jedoch nicht wirklich in ein typisches User-Story-Format. Ich fing an so etwas zu schreiben:

Als System werde ich Länderdaten aus dem XYZ-Feed parsen.

Einerseits ist diese Aufgabe nicht benutzerzentriert. Andererseits ist die Fähigkeit zum Abrufen von Komponenten-Länderdaten eine klar definierte, vertikal unterteilte Aufgabe, die unabhängig überprüfbar ist.

Wie sieht die richtige Aufschlüsselung der User Story für diese Art von Szenario aus? Ist es unangemessen, eine systemorientierte User Story zu haben?

Warum muss man das überhaupt aufteilen? Es scheint, als ob das Abrufen der Länderdaten Teil des Vorgangs sein wird, sie ausschließen zu können.
@Daniel Ich erwäge, es aufzuteilen, da jedes Element eine gut gekapselte Funktionalität darstellt und jede Schätzung eine gesonderte Überprüfung jeder unabhängigen Funktion erfordert.

Antworten (3)

Achten Sie auf das „V“ in der INVEST-Mneumik .

Ein PBI muss den Stakeholdern einen Mehrwert bieten.

Fragen Sie sich selbst : Bietet die Möglichkeit, Länderdaten aus dem XYZ-Feed zu parsen, einen Mehrwert für die Projektbeteiligten?

Wenn ja: Gut, teilen Sie es auf. Wenn nein: Nein, behalte es so wie es ist (oder teile es möglicherweise auf eine andere Weise auf, die INVEST nicht ungültig macht.

Hinweis: „Das System“ ist wahrscheinlich kein Projektbeteiligter.

Es ist erwähnenswert, dass Sarov den Begriff PBI verwendet, nicht User Story. Der Computer will nichts, also sollte es nicht das „Wer“ in der User Story sein. Finden Sie entweder heraus, wer es wirklich will, oder verwenden Sie keine User Story. Scrum sagt nicht, dass alle PBIs User Stories sein müssen. Das mag dogmatisch erscheinen, aber diese Praxis verwässert den Wert von User Stories wirklich.

Sprint-Backlog-Aufgaben sind nicht von Natur aus User Stories

Sie verschmelzen User Stories und Tasks. Product Backlog Items beginnen oft als User Storys im Product Backlog, aber Scrum schreibt das User Story-Format nicht vor. Diese Product-Backlog-Einträge werden während der Sprint-Planung in das Sprint-Backlog importiert. Stories werden an diesem Punkt oft weiter verfeinert, und während des Sprints werden oft zusätzliche Stories und Aufgaben im Zusammenhang mit der geplanten Arbeit generiert.

Der entscheidende Punkt ist jedoch, dass Aufgaben keine vollwertigen User Stories sein müssen, selbst wenn Ihr Product Backlog das Format verwendet. Fahren Sie fort und verwenden Sie User Storys, wenn es sinnvoll ist, aber Implementierungsdetails sind als User Story selten sinnvoll, weil:

  1. Der Wertkonsument ist oft das Team, da Implementierungsdetails eher dem Team oder dem System als einem Benutzer dienen.
  2. Es gibt kein Gespräch außerhalb des Teams, da das Team der Konsument der Aufgabe ist.
  3. Oft kommt gar kein Gespräch zustande. Normalerweise hat das Team zu dem Zeitpunkt, an dem etwas auf die Ebene „Ich werde X von Y parsen“ zerlegt ist, bereits die Planungs- und Entwurfsdiskussionen rund um die Implementierung geführt und die Tests für die geplante Arbeit entworfen.

User Stories sind Platzhalter für Konversationen und bieten im Allgemeinen einen Wertverbraucher, eine Kurzbeschreibung der Funktion und etwas Kontext, um die Implementierung und die anschließenden Diskussionen zu leiten. User Stories sind keine Vorgaben! Beschränken Sie Ihren Prozess also nicht zu sehr, indem Sie versuchen, Implementierungsdetails oder -spezifikationen in das User-Story-Format zu pressen. Normalerweise ist der Saft den Druck nicht wert.

Ich stimme zu, dass das tägliche DB-Abrufen eine Aufgabe sein könnte, die Teil der angeforderten User Story ist.

Wenn Sie jedoch aus irgendeinem Grund nicht beide Aufgaben im selben Sprint bearbeiten möchten oder können, kann es hilfreich sein, sich auf den Wert zu konzentrieren, der geliefert würde.

Die DB-Abrufaufgabe liefert keinen Wert für den Benutzer, aber sie liefert einen Wert für die Bestellung, indem sie die Kosten für die Implementierung der User Story reduziert.

Aufschlüsselung der User Story – Technische Aufgabe + Benutzerfunktion
AntwortenHierDatenschutz-Bestimmungen1y, 0v