Eine Geschichte in Teilaufgaben herunterbrechen

Ich persönlich bevorzuge es, die übergeordnete Geschichte so zu behandeln, als gäbe es keine Unteraufgaben.

Das heißt, sobald jemand mit der Arbeit an einer der Unteraufgaben beginnt, wechselt die übergeordnete Story zu In Bearbeitung . Es bleibt in Bearbeitung , solange eine seiner Aufgaben bearbeitet wird oder aufgenommen werden könnte. Tatsächlich hat es den Vorteil, dass die Story als In Bearbeitung gekennzeichnet ist, dass klarer wird, dass die noch nicht begonnenen Aufgaben dieser Story Vorrang vor einer anderen Story haben sollten, die noch nicht begonnen wurde.

Wenn alle (verbleibenden) Aufgaben derzeit blockiert sind , bedeutet dies, dass die Story blockiert ist . Sie könnten auch argumentieren, dass es blockiert ist, wenn eine seiner Aufgaben blockiert ist. Definiere einfach eine klare Regel und befolge diese.

Sie können ähnliche Regeln für andere Spalten anwenden. Zum Beispiel ist die Story als Ganzes bereit zum Testen, sobald alle ihre Aufgaben entweder erledigt oder selbst bereit zum Testen sind .

Und natürlich kann eine Story nur dann zu Done gehen , wenn alle ihre Aufgaben erledigt sind .

Eine Sache, die sofort festgestellt werden muss, ist die Tatsache, dass dies eine Teamleistung ist. Während der Product Owner für die Priorisierung des Backlogs und die Erfassung der Anforderungen des Unternehmens und der Benutzer verantwortlich ist, sind die Entwickler wirklich am besten in der Lage zu verstehen, welche technischen Fähigkeiten entwickelt werden müssen und wie viel Aufwand damit verbunden ist.

Bei der Aufteilung von User Stories in Aufgaben sind einige wichtige Dinge zu beachten:

Halten Sie die Aufgaben klein, aber nicht zu klein. Als Faustregel gilt, dass eine Aufgabe innerhalb eines Tages erledigt werden kann, aber auch nicht in ein paar Minuten. Aufgaben im Umfang sehr präzise halten. Erstellen Sie keine Aufgaben mit so vagen Aussagen wie „Codierung“ oder „Implementierung“ und denken Sie, dass jeder für Details einfach auf die übergeordnete User Story verweisen kann. Schreiben Sie etwas Aussagekräftigeres, das auch den Umfang sehr deutlich macht. Zum Beispiel: „Entwickle die Login-Klasse.“ Verwenden Sie die Akzeptanzkriterien der User Story als Ausgangspunkt und ihre Definition of Done als Checkliste. Die Akzeptanzkriterien helfen Ihnen zu bestimmen, welche Funktionen implementiert werden müssen, und die Definition of Done ist eine Checkliste für alle User Stories, die Ihnen auch dabei helfen kann, festzustellen, ob Ihnen Aufgaben für die zu erledigende Story fehlen.

Dies hängt von Ihrem Arbeitsablauf ab – sowohl vom Issue-Arbeitsablauf für die übergeordnete Aufgabe und Unteraufgabe als auch von den Spalten auf dem Board, die diesen Arbeitsablauf darstellen. Es hängt auch davon ab, was Ihre übergeordneten und untergeordneten Aufgaben darstellen.

Für Teams, mit denen ich arbeite, hat das übergeordnete Problem den primären Arbeitsablauf. Beispielsweise durchläuft das übergeordnete Problem Zustände wie „To Do“, „In Development“, „Code Review“, „Integration“, „Ready for Release“, „Released“, während die Subtasks „To Do“, „ In Bearbeitung“ und „Fertig“. Je nachdem, was die Unteraufgabe ist und wie sie sich auf die übergeordnete Aufgabe bezieht, wirkt sich dies darauf aus, wann Zustandsübergänge stattfinden. Wenn es sich bei der Unteraufgabe um eine Entwicklungsaufgabe handelt, müsste sie "Fertig" sein, bevor die übergeordnete Aufgabe mit "Codeüberprüfung" fortfahren kann. Wenn es sich bei der Unteraufgabe jedoch um eine Integrations- und Testaktivität handelt, wäre sie „Fertig“, bevor die übergeordnete Aufgabe zu „Bereit zur Veröffentlichung“ wechseln kann. Und wenn die Teilaufgabe eine Release-Aktivität ist,

Aufgrund solcher Fragen vermeide ich persönlich gerne die Verwendung von Teilaufgaben als Jira-Issues. Für die Aufgabenzerlegung füge ich normalerweise eine Liste der Arbeiten zum Beschreibungsfeld des Problems hinzu oder füge ein benutzerdefiniertes Feld hinzu, aber es gibt auch Checklisten-Plugins, mit denen Sie sie als Kontrollkästchen hinzufügen können, die abgehakt werden können. Wenn es Aufgaben gibt, die unabhängig voneinander durch den Entwicklungsworkflow geführt werden können, wird es zu einem neuen Top-Level-Problem und entsprechend mit Beziehungen wie "blockiert" oder "wird getrennt von" oder "bezieht sich auf" je nach Art der Beziehung verknüpft.

Es ist viel einfacher, die übergeordnete Geschichte weiterzuverfolgen, als gäbe es keine Unteraufgaben, als irgendetwas anderes weiterzuverfolgen. Sobald eine Unteraufgabe ausgeführt wurde, wird sie auf „in Bearbeitung“ verschoben und der Prozess wird fortgesetzt, bis alle Aufgaben abgeschlossen sind, wodurch die übergeordnete Story auf „erledigt“ gebracht wird.

Dies beseitigt Verwirrung.