Agiles Schätzen: Was bringen T-Shirt-Größen, wenn man Hemden trägt?

Voiced by Amazon Polly

Agiles Schätzen bietet vielerlei Vorteile, indem nicht der gesamte Inhalt eines Lastenheftes betrachtet werden muss, sondern nur beliebig viele, meist kleinere Inkremente. Dies erlaubt jedem Team den Umfang der nächsten Implementierungsphase (Sprint) besser einordnen zu können. Darüber hinaus gibt die Bewertung einer Anforderung (in der Regel: abstrakte Schätzmaße, wie z. B. T-Shirt-Größen) Aufschluss darüber, ob die gewünschte Ergänzung möglicherweise zu umfangreich ist und besser in mehrere weniger komplexe Schritte aufgeteilt werden sollte (Story Points). Ebenso der Austausch innerhalb des Teams, der durch die gemeinsame Diskussion über Wertigkeit des vorliegenden Sachverhalts entsteht, ist wertvoll für den bevorstehenden Umsetzungszeitraum.

Agiles Schätzens mit abstrakten Größen: Die Vorteile.

Bei agilen Schätzmethoden werden Anforderungen – anstatt in Zeit – anhand einer vorher definierten Referenzgröße zueinander in Relation gesetzt, um den Komplexitätsgrad näher bestimmen zu können. Angaben in Tagen, Wochen oder Monaten verlieren häufig im Projektverlauf, und spätestens bei Eintritt der Terminuntreue ihre Gültigkeit. Eine Komplexitätsschätzung hingegen bleibt weitestgehend stabil und kann (fast) immer mit historisch erreichten Komplexitätswerten (Velocity) verglichen werden, um die ungefähre Implementierungsdauer bis zur Fertigstellung ermitteln zu können.

Agiles Schätzen

Häufig verwendete Skalen, mit denen der Komplexitätsgrad geschätzt wird, sind u. a. die Fibonacci-Folge, bei der die Summe zweier aufeinanderfolgender Zahlen die unmittelbar danach folgende Zahl ergibt oder eben T-Shirt-Größen von XS für einfach bis XXL für überaus komplex. Wichtig bei jeder Art von Schätzung ist das gemeinsame Verständnis zur Referenzgröße und natürlich die damit einhergehende Vergleichbarkeit zu anderen Punkten.

Agile meets UX – aber zu welchem Zeitpunkt?

Während der wechselnden Umsetzungsphasen sich iterativ einem großen Ganzen zu nähern, gilt als absolut empfehlenswert und ausdrücklich richtig. Es scheint sogar mit wachsender (Agile-)Erfahrung und zuverlässiger Teamzusammensetzung eine beachtenswerte Unternehmensstärke nach Innen sowie in der Außenwahrnehmung darzustellen.

Die Frage die wir uns trotz aller positiven Effekte agiler Arbeitsweisen, wie z. B. Scrum oder Kanban stellen sollten, lautet:

„Inwiefern betrachten wir bei aller Spontanität und Beweglichkeit die tatsächlichen Erfordernisse unserer Nutzer und wann wird es überhaupt erforderlich?“

Die bisherigen Schätzmethoden geben zwar gewissermaßen Aufschluss darüber, wie umfassend die Umsetzung einer bestimmten Anforderung sein kann. Indizien, ab wann die Beteiligung von Nutzern erforderlich wird, liefern die Schätzungen entlang der o.g. Ordinalskalen leider nicht. Das bisherige System muss demnach angepasst werden, um mithilfe einer weiteren Dimension die Angelegenheit präziser bewerten zu können.

Die Bet-Cost-Matrix verrät die Antwort

Während der diesjährigen Mensch und Computer-Konferenz in Hamburg, wurde eine leicht angepasste Schätzmethode vorgestellt, welche die eben aufgeführten Fragestellungen beantworten kann – ohne die Schätzungsrunden (Estimation) nachteilig zu überfrachten.

Die Bet-Cost-Matrix (entwickelt von Mathias Wrba) ist eine kleine 5 x 5-Matrix, die bei der Beurteilung von Ideen, Epics und User Stories hilft zu verdeutlichen, ab wann der agile Umsetzungsprozess UX-Anteile, wie z. B. Research, Prototyping oder im Allgemeinen die Beteiligung reeller Nutzer, erfordert.

Bet-Cost-Matrix

Im Wesentlichen wird in zwei Dimensionen bewertet.

  • Wie viel würde es die Organisation ungefähr kosten, die Idee umzusetzen?
  • Wie viel würde der Teilnehmer persönlich darauf setzen, dass die Idee einen echten Wert für die Nutzer hat?

So funktioniert die Bet-Cost-Matrix

Jede Idee wird von jedem Teilnehmer zunächst verdeckt bewertet. Die Ratings werden dann offengelegt und diskutiert. Dies trägt dazu bei, ein gemeinsames Verständnis zu fördern und offenbart darüber hinaus schnell versteckte Annahmen über Wert oder Kosten. Wenn das jeweilige Team eine Einigung über die beiden Dimensionen gefunden hat, wird die Idee auf die Matrix im entsprechenden Feld platziert.

Der Cluster der Matrix und die damit verbundenen Aktionen können und sollten auf die Bedürfnisse jedes Teams individuell angepasst werden. Die Skala für beide Dimensionen sind greifbare, reale Kategorien wie z. B. Bier → Fahrrad → Familienurlaub → Auto → Haus.

Resultate in Verbindung mit der Bet-Cost-Matrix könnten wie folgt interpretiert werden:

 

Niedriger Wert für die Nutzer/geringe Kosten

–>Es ist ratsam einen Prototyp oder eine erste schnellen Implementierung im Vorfeld testen zu lassen.

Niedriger Wert für die Nutzer/hohe Kosten

–> Erfordert grundlegende Benutzerforschung/Research, um die tatsächlichen Bedürfnisse und den Nutzungskontext besser zu verstehen.

Hoher Wert für die Nutzer/geringe Kosten

–>Umsetzen!

Hoher Wert für die Nutzer/hohe Kosten

–>Die Idee in kleinere unabhängige Teile zerlegen. Bei gleichbleibenden/vergleichbaren Wert für die Nutzer, können damit die Kosten eventuell verringert werden.

 

Mit T-Shirt unter dem Hemd zur richtigen Einschätzung

Die Bet-Cost-Matrix kompromittiert in keinerlei Hinsicht die bewährten Schätzmethoden oder deren Metriken. Vielmehr dient es als eine hilfreiche Ergänzung und wirksames Werkzeug für den agilen Coach bei der Validierung von Hypothesen. Die Methode fördert das gemeinsame Verständnis im Team über Umfang und Wert einer Anforderung und verschafft ein hohes Maß an Sicherheit, in der Beantwortung der Frage ob und wann frühzeitige Meinungen von Nutzern erforderlich werden.

Es empfiehlt sich diese leicht abgewandelte Form der üblichen Schätzung mal anhand konkreter Punkte aus dem eigenen Backlog auszuprobieren.

Haben Sie Fragen, Ergänzungen, Erfahrungen oder Feedback zur Vorgehensweise? Gerne diskutieren wir diese mit Ihnen in den Kommentaren. 👇

Sie nutzen die Software von d.velop? Dann werden Sie doch einfach Usability-Tester und unterstützen Sie dabei die d.velop-Software noch effektiver, effizienter und zufriedenstellender zu gestalten.

>>JETZT USABILITY-TESTER WERDEN<<

 


Mehr zur Bet-Cost-Matrix im Methodenfinder: https://www.designmethodsfinder.com/methods/bet-cost-matrix