Das Problem: ein Product Backlog enthält gerade zu Beginn eines Projektes nur sehr grobe Beschreibungen der umzusetzenden Features. Trotzdem soll das Team schon frühzeitig eine Schätzung abgeben, damit eine sinnvolle Releaseplanung aufgesetzt werden kann. Wie soll das gehen? Diese beiden Anforderungen stehen doch offensichtlich im Widerspruch zueinander!

Granularität des Backlogs

In agilen Projekten werden Anforderungen nach und nach in Feature-Beschreibungen heruntergebrochen. Diese landen in Form von User Stories priorisiert im Product Backlog und werden Sprint für Sprint umgesetzt und damit abgearbeitet.

In der nebenstehenden Abbildung sieht man einen Eisberg, der ein wenig die Granularität von Backlog Items beschreibt. Der Teil, der über Wasser liegt, ist der sichtbare Teil, der im aktuellen Sprint bearbeitet wird. Die User Stories in diesem Teil des Backlogs sind „fertig“ im Sinne der „Definition of Ready“, d.h. alle Informationen sind in den Stories enthalten, die das Entwicklungsteam zur Umsetzung benötigt.

Im nächsten Teil, der direkt unter der Oberfläche liegt, sind die Stories für die nächsten 2-3 Sprints. Diese haben neben einer Story-Beschreibung vielleicht schon einige Details, aber die Akzeptanzkriterien fehlen möglicherweise noch. Einige werden schon vom Team geschätzt sein, andere noch nicht. Dies sind die Stories, an denen der Product Owner gerade intensiv arbeitet, um sie „ready“ zu bekommen.

Noch weiter unten, sozusagen in der Tiefsee, liegen sehr grobe Stories oder sogar nur Epics, bei denen vielleicht nichts außer einem groben Titel steht. Benutzerverwaltung oder SAP-Anbindung mögen solche Schlagworte sein.

Diese unterschiedlichen Granularitäten haben ihren Sinn: agil zu arbeiten bedeutet, immer auf Änderungen vorbereitet zu sein, die innerhalb eines Projektes unweigerlich geschehen werden. Schließlich lernen wir im Laufe eines Projektes viel über die verwendete Technik und Fachlichkeit, da wäre es doch merkwürdig, wenn Details zu Implementierungen oder fachliche neue Erkenntnisse sich nicht in Änderungen im Backlog niederschlagen würden.

Hätten wir alle Stories schon zu Beginn fertig geschrieben, müssten wir nun große Teile überarbeiten. Sind die Stories nur grob beschrieben, wird man die Details zwar anders formulieren als ursprünglich gedacht, da diese aber noch gar nicht formuliert waren, ist dies keine Verschwendung im agilen Sinn.

Wann ist ein guter Zeitpunkt für eine Schätzung?

User Stories müssen vom Team geschätzt werden, schließlich sollen die Teammitglieder auch die Arbeit leisten. Zur Schätzung braucht man aber das richtige Maß an Information. Die Scrum-Theorie gibt vor, dass die Beschreibung rein fachlich sein soll und die Schätzung der Komplexität relativ zu anderen Features vorgenommen werden soll. Viele Entwickler allerdings denken schnell in Lösungen und bewerten eher den Implementierungsaufwand, den sie im Hinterkopf haben.

Daraus folgt, dass Stories eigentlich „ready“ sein müssen, um eine gute Abschätzung vom Entwicklungsteam zu bekommen.

Wir hatten in einem realen Projekt neulich den Fall, dass das Backlog schon vollständig war, allerdings viele der Stories nur als sehr grobe Blöcke formuliert waren, eher Epics als Stories. Trotzdem mussten wir für eine Releaseplanung, die für ca. 9 Monate im Voraus zu erledigen war, eine Schätzung vornehmen.

Obwohl die Entwickler natürlich gemeckert haben, dass sie nicht genügend Informationen haben, um eine belastbare Schätzung vornehmen zu können, haben wir sie „gezwungen“, genau das zu tun. Wörter wie „unverbindlich“, „Bauchschätzung“ und „keine Garantie“ begleiteten die Schätzung. Das ganze Backlog war in vielleicht zwei Dutzend Teile geschnitten, und die einzelnen Zahlen, die dabei herauskamen, waren im höheren zweistelligen Bereich. In Summe kamen wir auf 1198 Story Points (Stories, die schon fertig beschrieben waren, führten natürlich auch zu kleineren Zahlen, deshalb die krumme Zahl).

Jetzt, drei Monate später, sind die Stories schon ziemlich gut beschrieben, sind also nahezu „ready“ im Sinne der Entwickler. Aufgrund einer Vorstandssitzung mussten wieder einmal Zahlen geliefert werden. Diesmal machten wir „reguläre“ Schätzmeetings mit fertigen Stories und der üblichen Story-Point-Skala mit Zahlen von 1 bis max. 20 (größere wurden geschnitten, bis sie klein genug waren).

In Summe kamen wir auf 1204 Story Points, also genau 6 Punkte von der unverbindlichen Bauchschätzung von vor drei Monaten entfernt! Zwar sind im direkten Vergleich einige Themen größer geworden als gedacht, dafür sind andere weggefallen. Es mittelt sich also alles zurecht, wie man das auch erwarten würde, wenn man unsichere Schätzungen über mehrere Themen in einen Topf wirft.

Und die Moral von der Geschicht’

Die verblüffende Erkenntnis aus dieser Geschichte ist die, dass Schätzungen von Entwicklungsteams nicht wesentlich vom Granularitätsgrad der Stories abhängen, sondern eher vom Verständnis der Entwickler von der Fachlichkeit. Am Anfang des Projektes würde die Schätzung sicher anders aussehen, aber wenn man ein paar Sprints hinter sich hat und sich mit der Fachlichkeit gut angefreundet hat, sind valide Schätzungen auch ohne tiefe Details möglich.

Wir Scrum-Coaches wissen das natürlich schon lange, aber für das Entwicklungsteam war dies schon eine neue Erkenntnis, schließlich MUSS doch (so die häufige Argumentation) entsprechende Detailtiefe einen Einfluss auf die Schätzung haben.

Nein, liebe Teams, muss sie nicht! Vertraut eurem Bauch!