Ich habe eine Anfängerfrage. Nehmen wir an, dass wir für ein Sprint Backlog eine User Story aus dem Product Backlog auswählen: „Als Fotografie-Junky möchte ich in der Lage sein, eine Sammlung von Lieblingsfotos zu erstellen“.
Und dann möchten wir einige detailliertere Aufgaben hinzufügen, zum Beispiel „Mockup erstellen“ für UX-Designer, „Änderungen am Modell vornehmen“ für Backend-Entwickler und Frontend-Implementierung von Designideen.
Was ist also die beste Vorgehensweise dafür? Fügen wir diese Teilaufgaben dem Sprint-Backlog hinzu oder erstellen wir ein separates „detailliertes To-Do“-Backlog? Fügen wir jeder Unteraufgabe Story Points hinzu?
Bei Stories-Punkten ist das ein besonders interessantes Problem, denn wenn wir Unteraufgaben zum Sprint-Backlog hinzufügen, zählen wir die Aufgaben doppelt: erstens für die User-Story im Allgemeinen und zweitens für ihre Teile in Form von Unteraufgaben.
Um die technische Arbeit zu erfassen, die zum Abschließen einer Story erforderlich ist, werden Aufgaben erstellt, die sich unter oder als Teil der Story befinden.
Wenn Ihre Tools das Erstellen von Unteraufgaben für eine Story nicht unterstützen, können Sie diese Aufgaben einfach als Aufzählungszeichen in die Beschreibung der Story schreiben.
In jedem Fall sind diese technischen Aufgaben keine Backlog-Items und werden daher weder dem Produkt- noch dem Sprint-Backlog hinzugefügt. Wenn eine Story zu einem Sprint hinzugefügt wird, werden die Aufgaben dieser Story automatisch mitgeliefert.
In Bezug auf die Schätzung nehmen einige Teams eine Schätzung in Stunden der Aufgaben der Stories vor, die während der Planung zum Sprint hinzugefügt wurden, um zu überprüfen, dass keine Disziplin innerhalb des Teams mit Arbeit überlastet ist. Diese Art der Schätzung ist völlig optional und unabhängig von den Story-Point-Schätzungen der Geschichten selbst.
Das Sprint-Backlog ist die Menge der für den Sprint ausgewählten Product-Backlog-Elemente sowie ein Plan für die Lieferung des Produktinkrements und die Verwirklichung des Sprint-Ziels.
User Stories sind eine mögliche Technik, keine Voraussetzung, um Product Backlog Items (PBI) auszudrücken. Wenn Story Points verwendet werden, sind sie im Allgemeinen an nichts unterhalb des PBI angehängt. Die ausgewählten PBIs werden vom Entwicklungsteam prognostiziert (nicht zugesagt oder zugesagt), und der Plan muss nur so detailliert sein, wie es vom Entwicklungsteam benötigt wird.
Die vom Entwicklungsteam für die ersten Tage des Sprints geplante Arbeit wird am Ende dieses Meetings zerlegt. (Sprintplanung)
Das Entwicklungsteam modifiziert das Sprint Backlog während des Sprints, und das Sprint Backlog entsteht während des Sprints.
Das Sprint Backlog ... gehört ausschließlich dem Entwicklungsteam.
Die Antwort darauf, wie die Arbeit aufgeteilt wird, muss das Entwicklungsteam bestimmen: Selbstorganisation. Das Erstellen von Aufgaben ist eine mögliche Technik, keine Voraussetzung, um die Arbeit zu zerlegen. Nicht alle ausgewählten PBIs sollten beim Sprint Planning zerlegt werden, sondern nur die ersten Tage der Arbeit: Reagieren auf Änderungen statt Befolgen eines Plans ( Manifest für agile Softwareentwicklung ).
Scrum erkennt keine Titel für andere Mitglieder des Entwicklungsteams als Entwickler an, unabhängig von der Arbeit, die von der Person ausgeführt wird; es gibt keine Ausnahmen von dieser Regel.
Das Denken und Ausführen in Begriffen wie Frontend-Entwickler, Backend-Entwickler, Tester, Technischer Redakteur usw. ist ein Indikator für Verbesserungsmöglichkeiten. ( Menschen mit Farbtropfen )
Anhand der INVEST-Kriterien können Sie entscheiden, was eine User Story ausmacht.
Die von Ihnen genannten Beispiele „Erstellen eines Modells“ und „Vornehmen von Änderungen am Modell“ bieten dem Endbenutzer keinen Mehrwert. Es sind also keine Geschichten.
Wenn Sie Schwierigkeiten haben, eine Geschichte aufzuteilen, können Sie die SPIDR-Techniken von Mike Cohn verwenden .
Die zusätzlichen Details (und die damit verbundenen Aufgaben) sollten vor dem Sprint Planning während regelmäßiger Backlog-Grooming-Sitzungen erläutert werden.
Wenn Sie bis zur Sprint-Planung oder später warten, um zu definieren, was Sie tatsächlich tun werden, um eine Geschichte zu liefern, geraten Sie bereits ins Hintertreffen – was ist, wenn Sie nach Beginn des Sprints feststellen, dass es zu viel Arbeit ist, um es abzuschließen, oder dass es so weit ist ist ein signifikanter Blocker für den Fortschritt?
Ihr Team sollte nur mit einem Backlog arbeiten, sonst wird die Priorisierung zum Problem.
Sie können Story Points entweder auf der breiteren Story-Ebene oder auf der kleineren „Unteraufgaben“-Ebene erfassen. Ich würde vermeiden, Story Points auf Unteraufgabenebene hinzuzufügen, wenn sie bereits einer übergeordneten Aufgabe zugewiesen wurden, einfach wegen der Gefahr der Doppelzählung. Wenn Ihre übergeordnete Geschichte groß ist, scheint das Team (und das Unternehmen als Ganzes) bis zum Schluss keine Fortschritte zu machen – kleinere Ergebnisse machen es einfacher, Fortschritte zu zeigen.
Sie werden auch feststellen, dass die Software, die Sie zum Verwalten von Geschichten verwenden, Einfluss darauf hat, wie Sie sie strukturieren, da es bestimmte Ansätze gibt, die besser zur Software passen.
RibaldEddie