Wie man eine Benutzerstory mit einer automatisierten Affinitäts-Tabelle schätzt

Story Points oder Tage, oder beides?

Menschen streiten sich oft darüber, ob man Story Points oder Story-Stunden (oder Tage) bei der Story-Schätzung verwenden soll. Einige Menschen glauben, dass wir Story Points und Team-Velocity gar nicht berechnen müssen. Nun, verschiedene Teams können unterschiedliche Meinungen haben, aber dennoch führen die meisten Agile-Projekte eine Story-Schätzung durch und betrachten sie als ein äußerst nützliches Werkzeug, um Projekte termingerecht und innerhalb des Budgets abzuschließen.

Affinitäts-Tabelle für die Story-Schätzung

In Visual Paradigm, betrachten wir die Story-Schätzung nicht als konflikthafte oder verhandlungsbedürftige Prozess, sondern als einen Team-Building-Prozess, der die Aufgabenzusammenarbeit und die Arbeitsbelastung für alle Teammitglieder klar und transparent macht. Das Benutzerstory-Tool ermöglicht dem Team die Nutzung der Affinitäts-Tabelle zur Automatisierung des Story-Schätzprozesses zusammen mit der Eliminierung von Spikes. Darüber hinaus unterstützt die visuelle Affinitäts-Tabelle die Echtzeit-Schätzung sowohl mit Story Points als auch mit Story-Stunden gleichzeitig. Wenn Sie eine Story entlang der Tabelle ziehen, werden sowohl die Story-Points als auch die Stunden gleichzeitig angezeigt, während die Story noch bewegt wird. Legen Sie die Story einfach in das Raster, wo Ihr Team die Schätzung angemessen findet.

Wie berechnet die Affinitäts-Tabelle?

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 die Arbeitsaufwendungen darstellen, die sich von links nach rechts erhöhen, 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 länger als die Dauer des Sprints sein sollte (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 rechten unteren Raster ebenfalls der Länge des Sprints entsprechen. Auf dieser Annahme basierend kann die Story-Schätzung automatisch berechnet werden.

Affinität von Benutzerstories zur 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 Benutzerstories, bei denen wir uns am sichersten fühlen (z. B. 5 Tage und mittlere Sicherheit). In diesem Fall legen Sie die Story vertikal in die Mitte (Sicherheits- oder Risikostufe) und horizontal (Arbeitsaufwand entspricht 5 Tagen oder der Hälfte der Sprintlänge, also 10 Tagen). Sie können dies dann als Bezugspunkt für die Schätzung der anderen Benutzerstories verwenden. Fragen Sie sich, ob diese Benutzerstory mehr Aufwand erfordert als die Referenzstory oder weniger und ob sie mehr oder weniger Unsicherheit aufweist. Sobald Sie einige weitere Benutzerstories auf die Affinitäts-Tabelle legen, können Sie mehrere Benutzerstories miteinander vergleichen, um zu prüfen, ob die Abstufung logisch ist, und sie dann entsprechend anpassen, damit sie gerecht erscheinen. Der Prozess ist eher eine Kunst als eine Ingenieurwissenschaft. Machen Sie es und besprechen Sie es in der Team-Sitzung, anstatt Konfrontationen zu suchen. Die Genauigkeit wird sich in der Regel verbessern, je reifer das Team wird.

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 lieferbares Produkt zu erstellen. Manchmal entsteht eine Benutzerstory, die nicht gut geschätzt werden kann, bis das Entwicklungsteam tatsächlich Arbeit leistet, um eine technische Frage oder ein Designproblem zu lösen. Die Lösung besteht darin, einen „Spike“ zu erstellen, also eine Aufgabe, deren Ziel darin besteht, die Antwort oder Lösung zu liefern.“

Bei der Schätzung einer Benutzerstory berücksichtigen wir nicht nur die Entwicklungsaufwendungen, sondern auch die damit verbundenen Risiken und Unsicherheiten. Oftmals wird ein Spike erstellt, bevor der formelle Beginn eines Sprints erfolgt, um die erforderlichen Arbeiten zu managen, damit andere Benutzerstories gerecht geschätzt werden können.