Wie teilt man eine User Story auf, die sich über mehrere Sprints erstreckt?

Ich habe eine User Story, die eine Reihe von Aufgaben enthält, ähnlich wie diese:

User Story: Beheben Sie jedes defekte JavaScript im CMS

  • Aufgabe: Fehlerhaftes JavaScript im Inhalt finden und reparieren
  • Aufgabe: Fehlerhaftes JavaScript in der Codebasis finden und reparieren
  • Aufgabe: Defektes JavaScript in statischen Dateien finden und reparieren
  • Aufgabe: Fehlerhaftes JavaScript in der Bibliothek finden und reparieren
  • Aufgabe: Fehlerhaftes JavaScript in Katalogdateien finden und reparieren

Ich habe also eine Reihe von Aufgaben, um Code und Dateien durchzugehen und JavaScript zu reparieren. Nehmen wir an, dass alle oben genannten Aufgaben nicht von mir in einem 2-Wochen-Sprint erledigt werden können.

Wie teile ich das in mehrere Geschichten auf? Die Aufgaben können in beliebiger Reihenfolge erledigt werden und sind in keiner Weise voneinander abhängig. Es gibt also keinen logischen Weg, sie in Untergruppen zu unterteilen. Würde ich einfach machen:

User Story: Defektes JavaScript im CMS reparieren (Teil 1)

und

User Story: Defektes JavaScript im CMS reparieren (Teil 2)

Das scheint ein schlechter Weg zu sein, dies zu verwalten. Was ist ein besserer Ansatz für diese Art von Problem, bei dem Aufgaben nicht besser gruppiert werden können, Sie aber die Geschichte trotzdem aufteilen müssen?

Eine einzelne User Story sollte niemals länger als ein einzelner Sprint sein. Siehe die umfassendere Antwort unten.
um ziemlich pedantisch zu sein, dies scheinen keine Benutzergeschichten zu sein - im Allgemeinen folgt eine Benutzergeschichte dem Format von: mountaingoatsoftware.com/agile/user-stories Als <Typ von Benutzer> möchte ich <irgendein Ziel>, damit < irgendein Grund>.
Warum möchten Ihre Benutzer defektes JavaScript im CMS reparieren?
Lange Rede, kurzer Sinn: Große E-Commerce-Plattform, bei der Teile von Einmalseiten-JS über ein CMS eingefügt werden, da keine Code-Veröffentlichung erforderlich ist. Aber das ist nur ein Beispiel.

Antworten (3)

Verwenden Sie INVEST für die Definition und Dimensionierung von Storys

Sie haben Probleme mit der Zerlegung Ihrer Arbeit, weil Ihre Geschichten nicht der INVEST-Mnemonik folgen . Insbesondere die von Ihnen aufgelisteten Aufgaben sind nicht testbar. Wie können Sie möglicherweise feststellen, ob Sie "Fehlerhaftes JavaScript in Katalogdateien finden und beheben" erfolgreich abgeschlossen haben, oder den damit verbundenen Arbeitsaufwand abschätzen?

Wie bei der testgetriebenen Entwicklung im Allgemeinen sollten die besten User Stories das Verhalten beschreiben . Zum Beispiel:

Als Benutzer erwarte ich, dass mich
das JavaScript auf der Katalogseite überrollt
, sodass ich genervt und weniger produktiv sein kann.

Jetzt ist klar, woran der Entwickler arbeiten muss und (was noch wichtiger ist) wie er diese Arbeit validieren kann. Sie haben testbares Verhalten beschrieben, anstatt den Umfang, das erwartete Verhalten und die testbaren Erfolgskriterien von Hand zu schwenken.

Zusammenfassende verwandte Artikel

Geschichten sollten granular sein, aber nicht lächerlich. Wenn Sie viele verwandte Korrekturen haben, können Sie sie in einen Topf werfen . Zum Beispiel:

Als Webentwickler
möchte ich die rickroll.js- Logik auf allen 27 Aufrufen fixieren
, damit ich alle Kunden unabhängig von der Einstiegsseite irritieren kann.

Auch dies definiert testbares Verhalten, hat einen klaren und messbaren Umfang und bietet genügend Kontext, damit das Team die damit verbundene Arbeit einschätzen kann. Ob Sie einzelne Geschichten haben oder sie zusammenfassen sollten, hängt von der Teamkapazität und der Größe der Geschichte ab, aber zumindest haben Sie jetzt Optionen!

Als Entwickler halte ich Geschichten, die mit „Als Entwickler ich …“ beginnen, für sinnlos. Der Sinn einer User Story besteht darin, die Arbeit aus der Perspektive des Benutzers zu verstehen. Andernfalls hätten Sie auch einfach aufzeichnen können, welche Arbeiten in einfachen Worten erledigt werden müssen.
@GlenThomas Trotz des Namens erwartet das User-Story-Format, dass ein Wertverbraucher definiert wird, nicht unbedingt ein Endbenutzer. Wenn Sie eine Frage dazu haben, öffnen Sie bitte eine andere Frage, da Kommentare nicht für eine ausführliche Diskussion vorgesehen sind.
Von StackExchange definierte Verwendung von Kommentaren: "Verwenden Sie Kommentare, um nach weiteren Informationen zu fragen oder Verbesserungen vorzuschlagen". Ich schlage Verbesserungen Ihrer Antwort vor. Ich habe keine Fragen zu stellen. User-Story-Definition: „User-Storys sind kurze, einfache Beschreibungen einer Funktion, die aus der Perspektive der Person erzählt werden, die die neue Funktion wünscht, normalerweise ein Benutzer oder Kunde des Systems.“
@GlenThomas Ihr Zitat zum Standpunkt einer Geschichte besagt, dass die Rolle sein sollte (Hervorhebung von mir): "Die Person, die die neue Fähigkeit wünscht , [die] normalerweise ein Benutzer oder Kunde des Systems ist." Es ist absolut nicht erforderlich, dass der Wertverbraucher ein Endverbraucher ist. Sie missverstehen das Format und den Zweck der Rollendefinition in einer User Story. Kurz gesagt, Ihr ursprünglicher Kommentar ist sachlich falsch, obwohl es sich um ein häufiges Missverständnis handelt, da schlecht geschriebene User Stories den Wert des Verbrauchers oft falsch zuordnen.

Anstelle von „beliebig“ würde ich eine genaue Zahl verwenden, oder das Beste wäre, eine Untersuchung in Sprint 1 durchzuführen, Probleme für jedes gefundene Problem zu erstellen und die spezifischen Probleme in den kommenden Sprints zu erledigen.

Mein Problem mit dem aktuellen Setup ist, dass es überhaupt nicht spezifisch ist. Wahrscheinlich bedeuten sie für zwei verschiedene Personen in Ihrer Organisation unterschiedliche Dinge.

Was ist, wenn die Untersuchung und der Schritt, mehr Aufgaben für jedes Problem zu erstellen, mehr Zeit in Anspruch nehmen, als die eigentliche Aufgabe selbst zu erledigen? Das scheint ineffizient.
Sagen wir zum Beispiel für eine Aufgabe oben, ich untersuche und finde 100 Stellen, an denen Code repariert werden muss. Aber die Zeit, die benötigt wird, um diese 100 Code-Korrekturen durchzuführen, nimmt weniger Zeit in Anspruch als die Untersuchung und Erstellung von 100 einzelnen Aufgaben.
Ich halte mich an die 10-Minuten-Regel: Wenn ich denke, dass ich es in 10 Minuten schaffe, mache ich es, sonst erzeuge ich ein Problem.

Mein persönlicher Ansatz wäre, die technischen Schulden basierend auf der Funktionalität der Anwendung anzugehen.

Reparieren Sie beispielsweise defektes JavaScript (alle Kategorien) auf den Registrierungsseiten. Testen Sie es dann (einschließlich Regressionstests) und fahren Sie dann mit dem nächsten Funktionsbereich fort.

Sie werden wahrscheinlich feststellen, dass die ersten paar Funktionsbereiche die meiste Arbeit erfordern und dass dann, während Sie mit der Entwicklung von JavaScript fortfahren, viele der zugrunde liegenden JavaScripts durch frühere Geschichten behoben wurden.

Wie teilt man eine User Story auf, die sich über mehrere Sprints erstreckt?
AntwortenHierDatenschutz-Bestimmungen1y, 0v