Anruf buchen

Teilaufgaben von User Stories: wie und warum wir sie bewerten

Da sowohl Mitarbeiter als auch Kunden angesichts der COVID-19-Pandemie weiterhin von zu Hause aus arbeiten, halten wir es für wichtiger denn je, dass wir unsere Erfahrungen in Bezug auf Remote-Arbeit und effiziente Zusammenarbeit in verteilten Teams weitergeben. Zwar gibt es verschiedene Infrastrukturlösungen (Microsoft Teams, Slack, WebEx, Google Meet usw.), die sich für verteilte Arbeitsabläufe eignen, doch ist es mindestens ebenso wichtig, über gut etablierte Prozesse zu verfügen. In diesem Artikel möchten wir erläutern, wie wir an Methoden zur Abschätzung arbeiten, um jeden Sprint genau zu planen.
Wir beginnen mit der Planung eines neuen Sprints. Die Softwareentwickler fügen dem Sprint Backlog mehrere User Stories hinzu.. Jede User Story hat ihre veranschlagte Bearbeitungszeit. Die zusammengetragenen Abschätzungen überschreiten nicht die Kapazität, d.h. den Total Workload, welcher während des Sprints bewältigt werden kann. Die Softwareentwickler bestätigen, dass sie in der Lage sind, die gesamte Funktionalität zu implementieren und das Sprint-Ziel bis zum Ende des Sprints zu erreichen.

Wie können wir sicherstellen, dass die Funktionalität wirklich rechtzeitig fertig wird? Und wie können wir mögliche Abweichungen im Voraus erkennen?

Bei der Planung eines Sprints teilen wir jede User Story im Sprint Backlog in Teilaufgaben auf. Unteraufgaben helfen uns nicht nur dabei, große User Stories in kleinere Elemente zu zerlegen, sondern sie helfen uns auch dabei, die entsprechende Arbeit auf die Teammitglieder zu verteilen. Subtasks können auch Gegenstand von Abschätzungen sein. Dann kann die Abschätzung für die Bildung sogenannter Information Radiators, z.B. ein Sprint Burndown Chart, verwendet werden. Durch die Analyse des Sprint Burndown Chart kann das Team eine Inspektion in Bezug auf die Erreichung des Sprint-Ziels durchführen. Werfen wir einen Blick auf einige Beispiele, wie Teilaufgaben abgeschätzt werden können.

Berechnung der für Teilaufgaben benötigten Zeit und Verwendung eines Burndown-Charts

Bei der Planungssitzung zerlegt das Team die User Stories in Teilaufgaben und erstellt Zeitabschätzungen für jede der Teilaufgaben. Die Aufgabenliste für jede User Story kann zum Beispiel wie folgt aussehen:

  • Refactoring (6 Stunden).
  • Implementierung des Kernmoduls (4 Stunden).
  • Finden einer Methode für die Interaktion mit der Datenbank (7 Stunden).
  • Anwenden von UI-Fixes (2 Stunden).
  • Erstellen eines Autotests (3 Stunden).

Die Summe der Zeitabschätzungen wird im Burndown-Chart angezeigt. Wenn die Teilaufgaben abgeschlossen sind, konvergiert der Zeitwert im Burndown-Chart auf Null.

Vorteile dieses Ansatzes

  • Es ist möglich, den Unterschied zwischen der anfänglichen Abschätzung und dem tatsächlichen Wert nicht nur für User Stories, sondern auch für Teilaufgaben zu sehen.
  • Kleinere Komponenten lassen sich leichter und präziser schätzen als alles Große und Verallgemeinerte.
  • Wenn Sie Ihre User Stories zerlegen, können Sie ihre anfänglichen Zeitabschätzungen noch einmal überprüfen.
  • Bei der Schätzung von User Stories können Sie sowohl Zeiteinheiten als auch Story Points verwenden.

Nachteile

  • Alle konstituierenden Teilaufgaben sind zusätzlich zur eigentlichen User Story zu bewerten, was mehr Diskussionen während der Planung erfordert und mehr Zeit in Anspruch nimmt.
  • Unvollständige Teilaufgaben sollten bei den Daily-Scrum-Sitzungen neu geschätzt werden. Auch das braucht Zeit.
  • Kunden sind nicht an Abschätzungen von Teilaufgaben interessiert. Sie wollen die ursprünglichen Abschätzungen für User Stories oder die Zeit, die bereits für die Implementierung von Teilaufgaben aufgewendet wurde, wissen.
  • Selten werden genaue Abschätzungen in absoluten Einheiten vorgenommen.

Quantitative Abschätzung von Teilaufgaben und Verwendung eines Burndown-Diagramms

In einem unserer Projekte verwendeten wir folgenden Ansatz: Wir schätzten die User Stories nur in Story-Punkten oder in Zeiteinheiten, während wir ein Burndown-Chart auf der Grundlage der Anzahl der derzeit offenen Teilaufgaben zeichneten.

Beispiel:

Bei der Zerlegung unserer User Stories auf dem Planungsmeeting kamen wir überein, dass die Teilaufgaben folgende Kriterien erfüllen sollten:

  • Sie sind in etwa gleich groß.
  • Die Umsetzung einer Teilaufgabe sollte nicht länger als einen Tag dauern.

Sobald die Teilaufgaben abgeschlossen sind, konvergiert das Burndown Chart auf Null.

Vorteile dieses Ansatzes

  • Zeitersparnis. Die Softwareentwickler bewerten bei der Planung nicht jede Teilaufgabe. Bei den Daily-Scrum-Sitzungen müssen die Teilaufgaben nicht neu eingeschätzt werden.
  • User Stories können in Story-Points oder Zeiteinheiten kalkuliert werden.
  • Die für die Implementierung von Teilaufgaben aufgewendete Zeit kann wie bisher protokolliert werden.

Nachteile

  • Die Teilaufgaben des Teams werden nicht sofort den ursprünglichen Kriterien entsprechen. Für die ersten zwei oder drei Planungssitzungen werden die Softwareentwickler lernen, wie Unteraufgaben von ungefähr gleicher Größe erstellt werden können.
  • Die Kunden sind nicht an Kostenvoranschlägen für Unteraufgaben interessiert. Sie möchten die ursprünglichen Kostenvoranschläge für User Stories oder die Zeit wissen, die bereits für die Implementierung von Teilaufgaben aufgewendet wurde.

Subtasks zählen nicht, Burndown Chart ist in Story Points

Stellen Sie sich vor, es gibt eine User Story, die auf bis zu 40 Story-Punkte im Sprint-Backlog geschätzt wird. Während der Planung erstellt das Team auch Teilaufgaben. Unteraufgaben werden nicht geschätzt. Später, bei den Daily Scrum-Sitzungen, werden die Softwareentwickler überprüfen, welche Teilaufgaben bereits abgeschlossen sind, und dann wird das Team die User Story in Story-Punkten neu abschätzen.

Das Burndown-Chart ist in Story-Punkten basierend auf dem Status der User Story.

Schlussfolgerung

Welchen Ansatz Sie auch wählen, bedenken Sie bitte, dass für uns nur eine geschlossene User Story von Bedeutung ist, denn nur geschlossene User Stories machen das Inkrement für das Produkt aus und werden vom Kunden geschätzt. Teilweise geschlossene Unteraufgaben in jeder User Story sind verschrottete Informationen, da sie nicht freigegeben werden können.