TTM matrix

Komplexität in den Griff kriegen – Die TTM-Matrix

Während der Estimation- oder Planning-Meetings mit meinen Teams fällt mir häufig auf, dass das Team Backlog Items zum Vergleich heranzieht, über die wir gerade vor ein paar Minuten gesprochen haben. Das ist großartig, da ich sie immer wieder ermutige, Items zueinander im Beziehung zu setzen, anstatt sie absolut auf einer fixen Skala nach Stunden oder Tagen zu bewerten. Allerdings müssen wir diese bereits besprochenen Items sehr oft nochmal öffnen und zeigen, weil die Teammitglieder in der Zwischenzeit Details vergessen haben.

Beispiel Sprint Planning: Das Team bespricht ein Item, das wir in Jira (Link) verwalten und für das Meeting an die Wand projiziert haben. Dann folgt das nächste, das nächste, das nächste, usw. Am Ende frage ich, auf welche Items sich das Team committen will und dann geht’s los: “Kannst Du das Item XY nochmal kurz zeigen?”, “Gehörten da die Designs dazu?”, “Für YZ war nur ein Smoketest notwendig, richtig?”.
Dies veranlasste mich, nach Möglichkeiten zu suchen, die Items länger sichtbar und die Erinnerung länger frisch zu halten. Vor ein paar Wochen nun bin ich über einen Artikel von James King gestolpert, der die “Things-that-matter-Matrix” beschreibt. Ich habe sie mit meinem aktuellen Team mal ausprobiert und frage mich nun, warum ich nicht früher auf so etwas Einfaches und Effektives gekommen bin. Im Folgenden beschreibe ich, wie es funktioniert.

Man benötigt lediglich eine Tabelle (z.B. auf einer oder mehreren Flipchart-Seiten). In diese trägt man in der ersten Spalte die zu besprechenden Backlog Items ein (in unserem Fall die Ticket-Nummern aus Jira). Außerdem benötigt man ein paar Spalten mit noch leeren Überschriften. Wenn man dies zum ersten Mal macht, sollte man das Team fragen, welche Spalten sie für einen Überblick benötigen, denn schließlich soll die Matrix eine Unterstützung für das Team darstellen, nicht für den Scrum Master. Die Spalten könnten zum Beispiel Programmiersprachen, andere Teams, technische Abstraktionsebenen oder irgendetwas anderes enthalten, das dem Team hilft, die Komplexität der Items in den Griff zu bekommen. Mein aktuelles Team hat sich für die folgenden Spalten entschieden:

  • Backend
  • CSS
  • JavaScript
  • Testvorbereitung
  • Testdurchführung
  • UX Design
  • UX QA
  • Business Intelligence

Die daraus resultierende Matrix zeigt die Abbildung TTM 1.

Während wir die einzelnen Items besprochen haben, haben wir die entsprechenden Felder angekreuzt. Wenn also UX Designs für ein Item benötigt wurden, haben wir ein Kreuz in der jeweiligen Spalte gemacht. Gegen Ende des Meetings sah die Matrix aus wie in Abbildung TTM 2.

Während unserer Schätzrunden hilft die Matrix dem Team sowohl dabei, die Komplexität einzelner Stories herauszuarbeiten als auch Stories im Auge zu behalten und miteinander zu vergleichen und so einfacher zu einer Schätzung zu kommen.

Beim Commit im Sprint Planning ist diese Matrix ebenso eine große Hilfe. Es ist klar ersichtlich, welche Bereiche berührt werden, ob es in einem Bereich zu einer besonders hohen Arbeitsbelastung kommen könnte, ob externe Unterstützung notwendig sein wird, ob es Abhängigkeiten zu anderen Items gibt und eine Menge mehr.

Aber das Beste war, dass wir bereits besprochene Items nicht immer wieder öffnen müssen, um uns an den Inhalt zu erinnern. Wir haben alle relevanten Informationen auf einen Blick parat.

Erweiterungsideen:

Bisher haben wir die Matrix in einer ziemlich einfachen Variante benutzt. Hier noch ein paar Ideen, wie man sie noch erweitern könnte, immer vorausgesetzt, es hilft dem Team:

  • Felder nicht nur ankreuzen, sondern mit Werten von 1 bis 3 (oder einer anderen Skala) versehen, um den erwarteten Aufwand zu zeigen (siehe Abbildung TTM 3)
  • Farbcodierungen nutzen, um bestimmte Sachverhalte zu verdeutlichen (z.B. benötigte Zulieferungen, Abhängigkeiten, …)
  • Erweiterung der Matrix um eine kurze Beschreibung der Items
  • … (beliebig fortsetzbar)

Falls jemand die Matrix aufgrund dieses Artikels mal ausprobiert würde ich mich über Feedback und Erfahrungsaustausch sehr freuen.

Autor: Sven Röpstorff

Sven Röpstorff arbeitet freiberuflich als agiler Projektmanager und Coach mit über 16 Jahren Berufserfahrung. Mit seinen Teams probiert er gern neue Wege und Methoden, um sich und sein Umfeld stets weiter zu verbessern. In seinen Vorträgen und Workshops bringt er den Menschen agile Vorgehensweisen auf interessante und spielerische Weise nahe und macht sie somit sichtbar, fühlbar, erlebbar.

4 Kommentare

  1. Klasse Beitrag, vielen Dank dafür. Konnte ich direkt heute im Rahmen eines Kundenworkshops einsetzten und ist sehr gut angekommen.

  2. Hallo,

    an sich eine gute Idee, nun müssen sich die Leute halt die JIRA Ticketnummer merken :D.
    Als ich das Thema im Einleitungstext las, dachte ich an so etwas wie:

    |Use Case Name| JIRA Nr.| 3-5 Schlagworte zum Thema/Sachverhalt

    :)

    Grüße,
    Damian

  3. @Ralf: Freut mich, dass die Matrix so gut angekommen ist, das ist ein schönes Feedback :-)

  4. @Damian: Du hast recht, ich habe auch schon drüber nachgedacht (siehe auch Punkt 3 der Erweiterungen). Der Artikel beschreibt die Matrix, wie wir sie momentan nutzen und erstaunlicherweise hat das Team mit den Nummern keine Probleme (ganz im Gegensatz zu mir :-) )

    Viele Grüße,
    Sven