Sollten wir standardmäßig Unteraufgaben für jede Story erstellen, die alle verschiedenen Arten von Arbeit darstellen, die die Story erfordert

Einer meiner Kollegen schlug eine Idee vor, Stories standardmäßig jedes Mal, wenn wir Stories für das Projekt schreiben, in Teilaufgaben aufzuteilen, um verschiedene Arten von Arbeit darzustellen, die eine Story hat.
Wir verwenden Scrum und Jira bei der Arbeit.

Die Vorteile dieses Ansatzes sind meiner Meinung nach:

  • Transparenz
  • wahrscheinlich bessere Schätzungen ("wahrscheinlich", weil dies schwieriger sein wird, eine Summe von Schätzungen mehrerer Story Points aus der Unteraufgabe mit der Fibonacci-Folge in Einklang zu bringen)

Die Nachteile sind meiner Meinung nach jedoch ziemlich erheblich:

  • mehr Arbeit, um den Arbeitsablauf zu organisieren
  • enormer Anstieg der Anzahl von PBIs (Product Backlog Items), die die Statistik der Sprints durcheinander bringen werden
  • Das Team hat immer noch Probleme damit, die Elemente auf dem Kanban-Board zu verteilen und die richtigen Personen in verschiedenen Entwicklungsstadien neu zuzuweisen. In dem vorgeschlagenen Szenario müssen wir Teilaufgaben miteinander verbinden und dann die PBIs manuell durchlaufen, um sicherzustellen, dass bestimmte Entwicklungsphasen abgeschlossen sind
  • Es muss einen Grund dafür geben, dass jede PBI im Backlog existiert – wenn ich PBIs erstelle, nur weil ich standardmäßig alle Storys aufteile, wird der gesamte Prozess weniger aussagekräftig und ich lasse es einfach schleifen
  • Wir haben bereits mehr als 1500 PBIs, daher wäre es schwierig, mitten im Projekt zwischen den Tracks zu wechseln, selbst für nur offene Geschichten

Am Ende denke ich, dass ich es einfach halten sollte, aber ich würde gerne Ihre Ideen bekommen, damit ich sicherstellen kann, dass ich eine gut informierte Entscheidung treffe und nichts verpasse.

Verwenden Sie derzeit überhaupt Unteraufgaben? Wenn ja, wie werden sie derzeit verwendet?
@BartvanIngenSchenau Ja, wir verwenden Unteraufgaben, aber nur, wenn eine Geschichte zu groß ist, um sie in einem Zeitrahmen von einem Sprint zu liefern. Ansonsten teilen wir Geschichten nicht in kleinere Teile auf.
Ich glaube nicht, dass die Transparenz verbessert wird. Normalerweise beenden wir LayerA nicht, beginnen dann mit der Arbeit an LayerB und dann an LayerC. Oft schreiben wir sie alle gleichzeitig. Alle diese Teilaufgaben werden also zur gleichen Zeit gestartet und beendet - und stellen somit eine atomare Aufgabe dar.

Antworten (3)

Der Vorschlag zum Hinzufügen von Teilaufgaben zu jeder User-Story im Voraus für jede Art von Arbeit, die mit der Fertigstellung der User-Story verbunden ist, geht von einer anderen Art der Arbeit mit Teilaufgaben aus, als Sie es derzeit tun.

Vermutlich hatte die Person, die den Vorschlag gemacht hat, im Sinn, dass die User-Story die PBI bleiben würde, die geschätzt und geplant wird. Die Teilaufgaben wären dann einerseits eine Erinnerung an das Team beim Abschätzen der Story, welche Arbeit mit der Fertigstellung der User Story verbunden ist, und würden andererseits eine einfache Arbeitsteilung geben, wenn mehrere Personen mit der Arbeit an der Story beginnen.

Dies bedeutet, dass diese Teilaufgaben nicht einzeln geschätzt (und schon gar nicht in Story Points gemäß einer Fibonacci-Folge) und auch nicht einzeln geplant würden. Das alles passiert auf der User-Story-Ebene.

Wenn Sie sich für diesen Vorschlag entscheiden, müssen Sie sich überlegen, wie Sie mit User-Storys umgehen, die für eine Iteration zu groß sind und die Sie derzeit in Teilaufgaben aufteilen, da die gleichzeitige Verwendung beider Praktiken nur zu Problemen führen würde Verwirrtheit. Eine Alternative könnte hier sein, in zwei User-Storys aufzuteilen und entweder die zu große Story zu einem Epic zu machen oder beide neuen Storys unter dasselbe (bestehende) Epic zu stellen.

Dies ist ein ziemlich üblicher Ansatz, der von vielen Teams gewählt wird. Oft finden es die Teams hilfreich, diese Unteraufgaben zu haben, um ihre Arbeit zu organisieren. Gleichzeitig ist es nicht unbedingt erforderlich. Viele Teams kommen gut ohne sie aus. Die einzige Falle dabei ist, dass Sie sicherstellen müssen, dass der Fokus nicht so sehr auf die Teilaufgaben verlagert wird, dass die Aufmerksamkeit die Backlog-Elemente verlässt. Diese Backlog-Elemente liefern immer noch Wert.

Ein weiterer Punkt, den ich teilen möchte, ist, wie diese Unteraufgaben normalerweise erstellt werden. Wenn Sie sich die Struktur des Sprint Plannings im Scrum-Leitfaden ansehen, gibt es drei Teile: Das Warum, das Was und das Wie. Teil eins legt die Richtung für den Sprint fest, was normalerweise zu einem vorläufigen Sprintziel führt. Teil zwei identifiziert, an welchen Rückstandspunkten gearbeitet werden muss, die zu dem in Teil eins vorgeschlagenen Ergebnis führen werden. Teil drei ist Raum für das Team, um einen ersten Plan für die Umsetzung dieser Elemente zu erstellen. Dies ist normalerweise der Ort, an dem diese Unteraufgaben erstellt werden. Bis zu diesem Punkt sind die richtigen zu erstellenden Unteraufgaben diejenigen, die dem Team helfen, seine Arbeit zu organisieren, um die ausgewählten Backlog-Elemente zu liefern und das Sprint-Ziel zu erreichen. Dies führt zu wertvollen Teilaufgaben, die mit der zu erledigenden Arbeit übereinstimmen.

Vielen Dank für Ihren Kommentar. Wir sind von der Erstellung von PBIs genau beim Sprint Planning abgekommen, denn wenn wir das tun, wird die benötigte Zeit in die Höhe schnellen und die PBIs am Ende der Liste werden aufgrund der Ermüdung der Teammitglieder übersehen oder nicht richtig geschätzt. Stattdessen führen wir Refinement Calls entlang des Sprints durch, um das zukünftige Sprint Backlog im Voraus vorzubereiten. So wählen wir beim Sprint Planning zur Definition des Sprint-Umfangs nur aus, woran gearbeitet werden soll, geleitet von Dringlichkeit und ROI und besprechen neben allem Abhängigkeiten und Blockaden (Ziel, Verfügbarkeit, Situationsübersicht usw.).
Auch dies ist meiner Meinung nach ein guter Rat, sich nur auf das zu konzentrieren, was hilft, die Arbeit zu erledigen. Wenn es nur ein Ritual oder eine Anweisung ohne Zweck dahinter ist, sollte es überdacht werden. Hier komme ich zu dem Schluss, dass das gedankenlose Erstellen von Unteraufgaben standardmäßig eine schlechte Idee ist und ich bei dem bleiben sollte, was ich habe.

Meiner Meinung nach ist der Vorschlag Ihres Kollegen ausgezeichnet . „‚Geschichten‘ beziehen sich auf das, was der Benutzer schließlich sehen wird – nicht auf die Fingerfertigkeit, die erforderlich sein wird, um ihn endlich sehen zu lassen!

Wenn es so kommt, dass in Ihrem „Shop“ die eintreffenden „Geschichten“ sinnvoll in Klassen unterteilt werden können – insbesondere Klassen, die irgendeine Art von gemeinsamer Implementierung oder wiederverwendbarem Ansatz vorschlagen – dann sollten Sie meiner Meinung nach sofort zupacken auf die Idee und laufe damit.

„Geschichten“ sind schließlich absichtlich eine Abstraktion. Aber in Ihrer Ausgangssituation ist das etwas Konkretes.

Danke für deinen Kommentar Mike. Im Moment teilen wir Geschichten in Unteraufgaben auf, wenn eine Geschichte zu groß ist und in ein paar untergeordneten Tickets dargestellt werden muss. Die Frage ist nicht, ob wir die Geschichten aufteilen sollten, sondern ob wir sie standardmäßig aufteilen sollten, was bedeutet, dass wir einfach einem Dummy-Verfahren folgen und jedes Mal, wenn eine neue Geschichte eintrifft, einen festen Satz von Geschichten erstellen. Gemäß der Scrum-Methodik ist die Menge an Arbeit, die an einem Element erledigt werden muss, alles, was das Entwicklungsteam benötigt, um ein potenziell auslieferbares Inkrement zu liefern. Das ist schließlich alles, was zählt. Lass mich wissen was du denkst.
Sollten wir standardmäßig Unteraufgaben für jede Story erstellen, die alle verschiedenen Arten von Arbeit darstellen, die die Story erfordert
AntwortenHierDatenschutz-Bestimmungen1y, 0v