Schätzung von Benutzerstories – Affinitäts-Tabelle

Wie man Benutzerstories für agile Entwicklung schätzt

Die Schätzung einer Benutzerstory ist schwierig! Wie können wir die beste Schätzung der Story-Größe erreichen? Einige sagen, die beste Größe sollte in Story Points geschätzt werden, während andere bevorzugen, sie in Stunden oder Tagen zu schätzen.

Nun, die Schätzung ist definitiv schwierig, aber es gibt einige Konzepte, die uns beim Schätzen von Benutzerstories unterstützen können:

1. Schätzen Sie Benutzerstories relativ aus zwei Aspekten
   • Arbeitsaufwand
   • Risiko (z. B. Komplexität und Unsicherheit)
2. Schätzen Sie Benutzerstories mit Story Points
3. Platzieren Sie jene Benutzerstories in der Affinitäts-Tabelle, bei denen Sie eine höhere Sicherheit bei der Schätzung des Arbeitsaufwands und der Komplexität (Risiko) haben
4. Schätzen Sie die anderen weniger vertrauten Benutzerstories schrittweise hinsichtlich Arbeitsaufwand und Komplexität, indem Sie sie mit den bereits in der Affinitäts-Tabelle geschätzten Stories vergleichen.

Affinität von Benutzerstories für die Schätzung

Die Schätzung einer Benutzerstory kann niemals zu 100 Prozent genau sein, und tatsächlich kann kein Verfahren dies erreichen. Um die Genauigkeit der Schätzung zu verbessern, beginnen wir damit, die Sprintlänge festzulegen (z. B. zwei Wochen oder 10 Arbeitstage) und schätzen einige wenigeBenutzerstoriesfür die wir uns am sichersten bei der Schätzung fühlen (z. B. 5 Tage und mittlere Sicherheit). In diesem Fall setzen Sie die Story in der Mitte vertikal (Sicherheit oderRisikoNiveau) und horizontal (Arbeitsaufwandist gleich 5 Tage oder die Hälfte der Sprintlänge, also 10 Tage). Sie können sie dann als Bezugspunkt für die Schätzung der anderen Benutzerstories verwenden. Fragt euch, ob diese Benutzerstory mehr Aufwand erfordert als die Referenzstory oder weniger und mehr Unsicherheit oder weniger. Sobald Sie weitere Benutzerstories auf die Affinitäts-Tabelle setzen, können Sie mehrere Benutzerstories miteinander vergleichen, um zu prüfen, ob die Abstufung logisch ist, und sie dann entsprechend anpassen, damit sie gerecht sind. Der Prozess ist eher eine Kunst als eine Ingenieurwissenschaft. Machen Sie es und besprechen Sie es in der Teambesprechung, anstatt Konfrontation zu suchen. Die Genauigkeit wird sich in der Regel verbessern, je reifer das Team wird.

Wie berechnet die Affinitäts-Tabelle? (Ein Video ansehen) 

Um zu verstehen, wie die Story Points und Tage in der Affinitäts-Tabelle automatisch geschätzt werden, müssen wir verstehen, dass die horizontalen Raster den Arbeitsaufwand darstellen, der von links nach rechts zunimmt, und die Komplexität der Story-Entwicklung (z. B. neue Technologie, neuer Bereich usw.) von oben nach unten zunimmt.

Da die maximale Anzahl an Tagen, die für die Entwicklung einer Benutzerstory benötigt wird, nicht mehr als die Länge desSprints (ansonsten ist die Benutzerstory entweder zu groß und muss aufgeteilt werden, oder der Sprint ist zu kurz und muss verlängert werden), sollte die Anzahl der Tage im unteren rechten Raster ebenfalls der Länge des Sprints entsprechen. Auf dieser Annahme basierend kann die Story-Schätzung automatisch berechnet werden.

Beachten Sie: Im ersten Beispiel oben

Story Point = Aufwand x Risiko (z. B. 3 x 4 = 12)

Story Point Einheit = Gesamtanzahl der Punkte / Sprintlänge (z. B. 100 / 20) = 0,2

Story-Tage (Stunden) = Story Point / Story Point Einheit (z. B. 12 x 0,2) = 2,4

Risiken durch Projekt-Spikes eliminieren

Laut dem Agile-Wörterbuch lautet die Definition von Spike:

„Eine Aufgabe, die darauf abzielt, eine Frage zu beantworten oder Informationen zu sammeln, anstatt ein lieferbaresProdukt. Manchmal wird eine Benutzerstory erstellt, die nicht gut geschätzt werden kann, bis das Entwicklungsteam tatsächlich Arbeit leistet, um eine technische Frage oder ein Gestaltungsproblem zu lösen. Die Lösung besteht darin, einen „Spike“ zu erstellen, der eine Arbeit ist, deren Ziel darin besteht, die Antwort oder Lösung zu liefern.“

Beim Schätzen einer Benutzerstory berücksichtigen wir nicht nur die Entwicklungsarbeit, sondern auch die damit verbundenen Risiken und Unsicherheiten. Oft wird ein Spike erstellt, bevor der formelle Beginn eines Sprints erfolgt, um die Arbeit zu managen, die erforderlich ist, damit andere Benutzerstories angemessen geschätzt werden können.

Herunterladen und jetzt ausprobieren!