Die Aufgaben-Burn-Down-Falle: alles erledigt, nichts getan

In den letzten drei Projekten, an denen ich beteiligt war (in einem als Teammitglied, in zwei als agiler Coach), habe ich gesehen, dass der übliche Sprint-Burndown auf der Grundlage von Aufgaben in eine gefährliche Falle führt: Es kann sein, dass Sie am Ende nichts geschafft haben. In zwei Fällen hatten wir für einen Sprint fast null Geschwindigkeit, während die Aufgaben zu 90% erledigt waren... Glücklicherweise gibt es eine Lösung: Burn Down User Stories und Toploading.

Arbeit != Ergebnisse Das erste Problem mit einem auf Aufgaben basierenden Burndown ist, dass er auf Aktivitäten und nicht auf Endergebnissen basiert. Die zugrunde liegende Annahme ist, dass das Endergebnis erreicht ist, wenn Sie alle Aktivitäten erledigt haben. Diese Annahme ist falsch. Schauen wir uns ein Burn-Down-Diagramm an. Sieht ziemlich nah an der Ideallinie aus, nicht wahr? Wenn Sie Ihren Fortschrittsbericht auf diese Linie stützen würden, würden Sie Ihrem Umfeld damit sagen, dass alles gut läuft.

Lassen Sie uns nun einen Blick auf die Aufgabentafel werfen. Fällt Ihnen auf, dass vieles erledigt ist, aber nichts fertig ist? In allen Storys sind Arbeiten in Arbeit oder noch zu erledigen, aber in keiner der Storys sind alle Aufgaben erledigt. Beachten Sie, dass selbst die Erledigung aller Aufgaben keine Garantie dafür ist, dass die gesamte Arbeit zu einem echten "Erledigt" führt.

Wenn dies Ihre Aufgabentafel am Ende eines Sprints ist, haben Sie einiges zu erklären. Wie können wir also verhindern, dass wir in diese Falle tappen? Der Fix Inspizieren Sie: User Story Burndown Zunächst müssen wir eine Burndown-Linie hinzufügen, die den Fortschritt der Ergebnisse anzeigt. Da User Stories ein Endergebnis beschreiben, sind sie die logische Wahl. Hätten wir den Fortschritt bei der Fertigstellung der User Story verfolgt, wäre das Diagramm für die obige Situation völlig flach gewesen. Diese Linie auf der Tafel hätte das Team vor der Falle gewarnt: Es wurde wirklich nichts getan!

Die Hauptursache für dieses Problem ist, dass zu viel Arbeit auf einmal in Arbeit ist. Anpassen: Toploading Jeff Sutherland sagte mir einmal, dass eines der Merkmale hyperproduktiver Teams darin besteht, dass sie ihre Arbeit innerhalb des Sprints nach Prioritäten ordnen, um eine höhere Geschwindigkeit zu erreichen. Das hat mich dazu inspiriert, etwas einzuführen, das ich Toploading genannt habe. Toploading kann wie folgt definiert werden: Bei einer geordneten Liste von User Stories arbeiten Sie entweder an der obersten Story oder Sie haben besser einen guten Grund, es nicht zu tun. Sie fahren erst dann mit einer anderen Story fort, wenn Ihre aktuelle Story fertig ist. Der Idealfall ist, dass das ganze Team am obersten Punkt arbeitet (es heißt nicht umsonst Scrum :-) ), aber das ist natürlich in vielen Fällen nicht praktikabel. Es gibt also einige triftige Gründe, nicht an dem Top-Thema zu arbeiten:

• Der oberste Punkt ist maximal ausgelastet: das Hinzufügen weiterer Personen hilft nicht oder schadet sogar dem Fortschritt
• Ihr Fachwissen und Ihre Kenntnisse sind für diese Geschichte völlig nutzlos. Beachten Sie, dass Sie trotzdem teilnehmen könnten, um zu lernen, oder dass Ihre Hilfe etwas später benötigt wird.

Wenn Sie nicht am obersten Punkt arbeiten können, sollten Sie am nächsthöheren Punkt arbeiten, und es gelten die gleichen Regeln. Auch wenn es triftige Gründe gibt, nicht an der Spitze zu stehen, gibt es für jedes einzelne Teammitglied eine absolute Regel: Jedes Teammitglied sollte so weit oben auf der Liste arbeiten, wie es kann. Mit Toploading und dem User Story Burn Down haben Sie einige gute Werkzeuge, um die Aufgaben-Burn-Down-Falle zu vermeiden! Überprüfen Sie nochmals Wenn Sie Toploading verwenden, sollte Ihr User Story Burn Down Folgendes tun:

Der User Story Burn Down zeigt in zweierlei Hinsicht einen anderen Trend als ein Task Burn Down:

• User Stories sind per Definition gröber als Tasks, so dass die Linie "blockiger" ist als bei den feineren Tasks.
• Ein User Story Burn Down ist anfangs eher flacher. Auch dies hat mit der gröberen Granularität zu tun. Obwohl es gut ist, die User Stories feiner zu strukturieren, sollten Sie sich nicht darauf versteifen, genau der Ideallinie zu folgen.

Ein Task Board mit einem Team, das Toploading betreibt, hat auch einen charakteristischen Fluss. Stellen Sie sich einen Schneepflug vor, der von oben kommt und die Aufgaben von links nach rechts bewegt, während er nach unten fährt:

Dies ist eine weitere Möglichkeit, um zu sehen, ob Sie wirklich effektiv arbeiten, anstatt einfach irgendeine Aufgabe zu verschieben. Sollte ich also die Aufgabe Burn Down wegwerfen? Nein! Werfen Sie die Aufgabe Burn Down nicht weg! Sie sollten beide verwenden. Der Aufgaben-Burn-Down liefert Ihnen Informationen, die der User Story Burn-Down nicht liefert. Eine Verflachung des Aufgaben-Burn-Downs kann zeigen, dass viele Teamkapazitäten nicht mehr zur Verfügung stehen, weil alle die ganze Zeit mit der Behebung von Produktionsfehlern beschäftigt sind, oder weil jemand krank ist. Die Kombination der beiden Burn Down Diagramme liefert Ihnen die meisten Informationen. Fazit Der User Story Burn Down und das Toploading sollten Ihnen helfen, ein Maximum an Effektivität zu erreichen und die Task Burn Down-Falle zu vermeiden. Mögen Ihre Sprints hyperproduktiv sein!