Wie groß sollten Backlog Items in Scrum sein?
Wenn man in Agile bzw. Scrum einen Sprint oder eine Iteration plant, ist es wichtig, sich zu überlegen, wie groß die einzelnen Tasks sein sollten.
Man möchte keine zu großen Tasks
Man kann nur schwer den Fortschritt des Teams beurteilen, wenn man mit zu großen Tasks arbeitet, denn dann ist man gezwungen, einzuschätzen, wie viel Prozent dieser Tasks schon fertig gestellt wurden bzw. wie viele Stunden noch übrig bleiben.
Und das ist wirklich nicht einfach. Es macht es einem viel leichter, wenn Tasks wie in Scrum ganz klar einem binären Zustand wie entweder To Do oder Done zugeordnet werden können. Das bedeutet aber nicht, dass unsere Tasks zu klein sein sollten.
Auch zu kleine Tasks können Probleme verursachen
Ein größerer Koordinationsaufwand ist dann vonnöten, weil es mehr Tasks in der Iteration gibt.
Im Iteration Planning wird mehr Zeit für die Erstellung der Tasks benötigt.
Während der Iteration braucht man mehr Zeit für das Verwalten und Tracken der Tasks.
Wenn nun also die Tasks in einer Iteration weder zu groß noch zu klein sein sollten, was wäre dann eine angemessene Größe?
Es gibt zwei gute Richtlinien. Kombiniert können diese beiden Richtlinien Ihrem Team dabei helfen, Tasks mit einer guten Größe für das Sprint Backlog bzw. Iteration Backlog zu erstellen.
Tasks sollten innerhalb eines Tages zu erledigen sein
Überlegen Sie nur einmal, wie toll es wäre, wenn alle Teammitglieder jeden Tag im Daily Standup sagen könnten: „Gestern habe ich diesen Task erledigt und heute werde ich diesen neuen Task fertigstellen.”
Allerdings ist es unrealistisch zu sagen, dass jeder einzelne Task genau einen Tag benötigen sollte. Daher gehen wir einfach davon aus, dass die durchschnittliche Dauer für die Tasks einen Tag betragen sollte. Einige werden etwas länger dauern, andere benötigen weniger Zeit. Einen Tag als Ziel für die durchschnittliche Task-Größe zu nehmen, ist jedoch ein gutes Ziel.
Aber gibt es denn wenigstens angemessene Ober- und Untergrenzen für die Größe der Tasks? Kann ein Team einen 10-Tage-Task haben, wenn sich das mit einigen 5-Minuten-Tasks wieder ausgleicht? Die Antwort darauf ist Richtlinie Nr.2.
Tasks sollten sich innerhalb einer Spanne von 1 Stunde bis zu 2 Tagen für die Fertigstellung bewegen
Wenn man eine solche durchschnittliche Task-Größe anstrebt, ist es sinnvoll, einige Grenzen für eine geeignete Größe festzulegen. Ich würde eine Spanne von einer Stunde bis zwei Tage vorschlagen.
Versuchen Sie, Tasks zu vermeiden, die geschätzt weniger als eine Stunde dauern werden. Ein Teammitglied wird sich Zeit nehmen müssen, um sich um den Task Gedanken zu machen. Die Person wird evtl. mit jemandem sprechen müssen, bevor mit dem Task begonnen werden kann. Unter Umständen muss auch ein 10-Minuten-Task dreimal gemacht werden, bevor endlich alles richtig ist usw.
Wenn Ihr Team tatsächlich etwas identifiziert hat, das 10 Minuten dauern würde, sollten sie einfach eine Schätzung für 1 Stunde abgeben. Wenn dieser Task dann in weniger als einer Stunde fertiggestellt wird, wird das die Tasks ausgleichen, die zu spät fertig werden.
Ich schlage eine Obergrenze von 2 Tagen vor, nicht weil man viele 2-Tage-Tasks haben sollte, sondern weil es gelegentlich Tasks geben kann, die nicht innerhalb von einem Tag erledigt werden können.
Es ist wichtig, sich dessen bewusst zu sein und größere Tasks in das Iteration bzw. Sprint Backlog zu lassen. Man möchte aber keine Tasks im Backlog, die so groß sind, dass die Teammitglieder von der harten Arbeit, ein Problem gründlich zu durchdenken, entbunden sind.
Größe von Backlog Items
Diesen einen optimalen Punkt zwischen Tasks, die zu groß sind, und solchen, die zu klein sind, gibt es wirklich. Wenn Sie sich an die beiden hier genannten Richtlinien halten, werden Sie Ihrem Team helfen, genau diesen Punkt zu finden und mit Agile bzw. Scrum Erfolg zu haben.
Dieser Beitrag stammt von Mike Cohn und wurde von uns ins Deutsche übersetzt.
Der Unterschied zwischen Story und Task
Finde heraus, wie du Tasks von User Stories und noch größeren Items unterscheidest im Backlog.
=> Der Unterschied zwischen Stories und Tasks
User Stories schreiben
Hier erfährst du, wie ich am liebsten eine User Story formuliere, damit sie möglichst einfach zu verstehen ist.
=> Struktur für User Stories
Nich alle Tasks im Planning identifizieren
Damit kein Mehraufwand stattfindet, sollten Scrum Teams niemals alle kommenden Tasks festlegen wollen.
=> Keine Tasks im Planning definieren