Warum User Stories abwägen?

27 Februar 2020

Dieser Artikel zeigt, warum es notwendig ist, User Stories abzuwägen und welche Arten von Abwägungen verwendet werden.

Warum User Stories abwägen

Stellen Sie sich vor, Sie haben einen neuen Kunden, der möchte, dass Sie ein neues Produkt schnell, in bester Qualität und zu niedrigen Kosten implementieren. Man könnte versuchen, die Aufgabe sofort zu kalkulieren, das Produkt aus dem Stegreif zu bewerten um zeitliche und finanzielle Bewertungen des Projekts auszuarbeiten, wobei man geneigt ist, zu versprechen, alle Wünsche zu berücksichtigen. Ein solcher Ansatz birgt jedoch ein hohes Risiko, dass das Produkt nicht innerhalb des vorgegebenen Zeitrahmens umgesetzt und das Budget überschritten wird, sowie die Erwartungen des Kunden nicht erfüllt werden.

Um Fehler zu vermeiden, muss zunächst sichergestellt werden, dass Sie und der Kunde über die gleichen Merkmale sprechen. Zu diesem Zweck wird eine Projekt-Charta gebildet, die das gegenseitige Verständnis der Funktionalität bei allen Projektbeteiligten sicherstellt. Die Projektfunktionalität wird dabei in kleinere Teile aufgeteilt. In dieser Phase schauen sich das Entwicklungsteam und der Kunde gemeinsam die Projektdetails an und einigen sich auf den Projektinhalt.

Der nächste Schritt ist die Erstellung von User Stories für das Produkt-Backlog.

Das Entwicklungsteam kann dann letztlich jede Story einzeln einschätzen. Die Summe dieser Schätzungen ergibt eine ungefähre Realisierungszeit für das gesamte Projekt. Dies ist ein präziserer Ansatz, da er die Detailierung einschließt und zeigt, welche Merkmale auszuschließen sind, um mögliche Fristen und das Budget einzuhalten.

Später, wenn die Zeitschätzung abgeschlossen ist und eine Vereinbarung über die Projektfunktionalität getroffen wurde, können die User Stories zusammengefasst werden, so dass eine Roadmap entworfen werden kann. Der Kunde kann dann über die Kosten- und Zeitabschätzungen informiert werden.

Der Erfolg des Projekts wird davon abhängen, wie genau die User Stories geschätzt werden

Wie misst man eine User Story?

ABSOLUTE ZEITSCHÄTZUNG

(Einige Leute neigen dazu, hier ideale Tage, ideale Stunden oder nur Manntage oder Mannstunden zu verwenden).

Vorteile dieser Schätzmethode:

Sie ist einfach und klar in Bezug auf die Zeit und für den Kunden leicht verständlich. Zum Beispiel kann Merkmal 1 in drei Tagen implementiert werden, Merkmal 2 benötigt vierzehn weitere Tage, usw.
Die Zeitabschätzung lässt sich leicht monetär kalkulieren: eine Entwickler-Stunde kostet 200 Dollar. Die Funktionalität, deren Implementierung drei Stunden dauert, kostet $600 usw.
Geschwindigkeit: Wenn das Team aus 6 Vollzeit-Entwicklern besteht, die 5 Tage pro Woche und 8 Stunden pro Tag arbeiten, dann wissen wir, dass ihre Geschwindigkeit für einen 2-Wochen-Sprint 6*5*8*2=480 Stunden beträgt. Vorausgesetzt, das Entwicklungsteam schätzt alle User Stories auf insgesamt 5500 Stunden, ist es vernünftig, das Projekt innerhalb von 6 Monaten abzuschließen.

Nachteile dieser Schätzmethode:

Die ursprünglichen User Stories können möglicherweise nicht genau geschätzt werden. Zum Beispiel wurde die erste Story auf 20 Stunden geschätzt, aber tatsächlich dauerte es 40 Stunden, bis sie implementiert war. Wenn das Team weitere Storys in Bezug zur ersten schätzt, dann sind alle Schätzungen falsch. Bei Projekten, bei denen Gantt-Diagramme zur Visualisierung verwendet werden, müssen die Manager alles von Anfang an neu berechnen.
Es ist kaum möglich absolute Maßeinheiten genau zuzuordnen. Zu diesem Thema wurden bereits viele Studien durchgeführt.

STORY POINTS (SP) ALS RELATIVE WERTE

T-Shirt-Größen (XS, S, M, L, XL) und andere abstrakte Größen können hier als gute Beispiele genannt werden.

Vorteile der Schätzung in SP:

SP sind relativ, und diese Tatsache mildert die Auswirkungen einer Fehleinschätzung. Zum Beispiel wurde der gesamte Rückstand auf 5500 SP geschätzt. Bei der Umsetzung einer der ersten Storys, die auf 8 SP geschätzt wurde, erkannte das Team, dass es nicht 8, sondern 12 Stunden dauerte. Sollten sie also alles neu schätzen? Nein, denn es ist nichts Ernstes passiert. Trotz des Geschwindigkeitsrückgangs und der Tatsache, dass der nächste Sprint weniger User Storys enthalten wird, bleibt die Komplexitätseinschätzung der Story im Vergleich zu den anderen Storys gleich.
Zum Beispiel wird eine Story auf 2 SP geschätzt. Ein leitender Entwickler kann sie in 2 Stunden implementieren. Für einen Junior-Entwickler kann es dagegen 4 Stunden dauern. Im Vergleich zur einfachsten User Story, die auf 1 SP geschätzt wird, wird die gegebene Story jedoch von beiden Entwicklern doppelt so komplex wie die einfachste gefunden. In diesem Fall werden sich beide Entwickler gegenseitig auf die Schätzung von 2 SP einigen.

Nachteile der Schätzung in SP:

SPs scheinen für den Kunden unverständlich zu sein. Wenn man zu erklären versucht, dass ein bestimmtes Merkmal 8 SP kostet, wird der Kunde es nicht verstehen.

Der reale Proportionalitätskoeffizient zwischen einem SP und der Zeit, die er benötigt, einschließlich des Geschwindigkeitswertes in SPs, wird erst nach 3 oder 4 Sprints verlässlich.

Die SP-Werte variieren von Team zu Team. Deshalb ist es schwierig, SPs von mehreren Teams zu vergleichen.

Was soll für das Projekt ausgewählt werden?

Bei kurzfristigen Projekten ist es ratsam, die herkömmlichen zeitbasierten Schätzungen zu verwenden. Sie sind für den Kunden transparent und können leicht in Bezug auf Geld bewertet werden.
Bei langfristigen Projekten ist es besser, Story Points zu verwenden. Zu Beginn des Projekts ist es einfacher, ein Komplexitätsverhältnis zwischen der einfachsten Story und Storys, die erst ein halbes Jahr später umgesetzt werden, zu finden, als zu versuchen, alle Storys in Stunden zu schätzen.
In der Anfangsphase ist es auch möglich, die Umwandlung der Story Points in Geld zu testen. Man schätzt einfach die einfachste Story in Story Points, schätzt sie dann in Zeiteinheiten und rechnet die resultierende Schätzung in Geldeinheiten um. Aber bitte beachten Sie, dass die genauen Kosten für einen Story Point erst am Ende des 3. oder 4. Sprints ermittelt werden können. Deshalb sollte eine solche Schätzmethode nicht zur gängigen Praxis werden

Im nächsten Artikel werden wir erklären, warum es notwendig ist, die Teilaufgaben von User Storys zu schätzen, und wie dies geschieht.