Artikel Agiles Schätzen!

In diesem Blogpost dreht sich, wie der Titel schon verrät, alles um Schätzungen. Ich zeige euch, wie ihr eure Anforderungen auf eine agile Art und Weise abschätzen könnt und gebe euch ein grundlegendes Werkzeug für die Erstellung eures ersten agilen Plans mit auf den Weg.

Eine Sache, die ich am agilen Ansatz wirklich schätze ist, wie dieser auf die Freundlichkeiten verzichtet und uns daran erinnert, wie unsere Schätzungen eigentlich sind – nämlich wirklich, wirklich schlecht! Aber Schätzungen müssen wir abgeben um daraus Pläne für die Umsetzung zu erstellen.

Seien wir mal ehrlich – unsere Branche hat nicht gerade einen guten Ruf, wenn es darum geht, Erwartungen, die an Projekte gestellt werden, zu erfüllen. Es ist, als hätten wir irgendwann einfach vergessen, dass unsere Schätzungen wirklich nur schlechte Vermutungen sind, und zwar meisten übertrieben optimistische Vermutungen, um genau zu sein.

Steve McConnell nennt dies den “Cone of Uncertainty”, also den Kegel der Ungewissheit, der uns im Grunde daran erinnert, dass wir zu Beginn eines Projekts einfach viel zu viele Unbekannte haben, um ein gewisses Maß an Genauigkeit in Bezug auf den Zeitpunkt zu haben, an dem wir denken, dass ein Projekt fertig sein wird.

Erst nachdem wir etwas gebaut haben, können wir messen, wie lange die Erstellung gedauert hat, um danach diese Erkenntnis wieder in den Plan einfließen zu lassen.

Die einzige Frage, die wir zu Beginn eines Projekts beantworten sollten ist, ob dieses Projekt mit der zur Verfügung stehenden Zeit und den vorhandenen Ressourcen überhaupt möglich ist. Im Grunde können wir am Anfang des Projekts nur maximal eine grobe Schätzung oder den oft verwendeten Begriff „ballpark figure“ abgeben.

Wenn es also um Schätzungen geht, brauchen wir eine Methode, die es uns erlaubt, Budgets zu erstellen, für die Zukunft zu planen, uns daran erinnert, dass unsere Schätzungen wirklich schlechte Vermutungen sind, aber auch die inhärente Komplexität und Ungewissheit anerkennt, die mit dem Schreiben von Software einhergeht.

Nun gibt es zwei Dinge, die uns helfen werden, auf eine agile Art und Weise zu schätzen.

1. wir halten die User Stories einfach
2. wir schätzen die User Stories relativ

Es gibt keine separaten Schätzungen für die Analyse, die Entwicklung oder das Testen. Es ist eine einzige Zahl, die alles liefert, was notwendig ist, um diese User Story zum Funktionieren zu bringen. Außerdem ist wenig Aufwand bei der Schätzung sehr hilfreich. Wir werden nicht Stunden damit verbringen, zu versuchen, die Schätzungen genau richtig hinzubekommen. Wir werden eine Analyse durchführen, unsere beste Schätzung abgeben und dann schnell mit der nächsten User Story weitermachen. Tagelang auf das Zeug zu starren, wird nicht helfen, aber was die agile Schätzung wirklich zum Laufen bringt, ist die relative Dimensionierung von Stories.

Machen wir ein kurzes Beispiel dazu. Versuche die Fläche dieser beiden Quadrate als exakte Zahl zu schätzen. Nimm dir ein paar Sekunden Zeit und sag mir genau, wie groß jedes dieser Quadrate ist.

Okay, jetzt versuchen wir einen anderen Ansatz. Sag mir diesmal, um wieviel größer das blaue Quadrat im Vergleich zum oliven Quadrat ist?

Wenn du viermal zu groß geraten hast, herzlichen Glückwunsch, du bist ein geborener Schätzer. Die Millionen-Euro-Frage ist nun: „Was war einfacher? Die Schätzung auf die erste Art oder die Schätzung auf die zweite Art?“

Man nennt dies relative Schätzung, welche den Eckpfeiler von agilem Schätzen und agiler Planung darstellt. Denn sobald wir wissen, wie schnell das Team arbeiten kann und ihre User Stories relativ dimensioniert sind, können wir damit beginnen, wirklich gute Erwartungen in Bezug auf die Termine zu setzen.

Es gibt noch einen Punkt, den wir im Bezug auf agiles Schätzen noch verstehen müssen und zwar – die Schätzung ist ohne Einheiten. Wenn wir User Stories relativ zueinander einschätzen, messen wir die Größe, nicht die Zeit, die benötigt wird, um diese User Story zu entwicklen. Ein Kalendertag entspricht also nicht einer Einheit der Größe. Wir können auf diese Weise schätzen, weil verschiedene Leute unterschiedlich schnell arbeiten und manchmal Dinge, von denen wir denken, dass sie einen Tag dauern, am Ende vielleicht zwei Tage oder sogar eventuell nur einen halben Tag dauern.

Einheiten sind also nicht wirklich wichtig, es sind keine Zeitmaße, sondern ein Größenmaß, also nennen wir sie einfach Punkte und nehmen an, dass ein Punkt etwas ziemlich Einfaches ist. Etwas, das in der Umsetzung einen Tag dauern würde, drei Punkte für etwas Größeres, vielleicht ein paar Tage, fünf Punkte pro Woche und zehn Punkte für eine wirklich große Sache, die in der Größenordnung von zwei Wochen dauern würde.

Okay, genug der Theorie, sehen wir uns das mal in der Praxis an. Nehmen wir an, wir müssen abschätzen, wie lange es dauern würde, eine Anmeldeseite zu erstellen. Nehmen wir an, wir haben bereits unseren Projektumfang, wir haben ihn definiert, wir verstehen, was wir bauen und warum. Wir haben unsere Workshops zum Sammeln von User Stories durchgeführt und jetzt sind wir bereit, unsere erste User Story aus unserem Backlog zu schätzen.

Wie sollen wir das angehen? Nun, es gibt nichts magisches, um unsere User Stories zu schätzen. Im Grunde setzt man sich einfach mit dem Kunden zusammen und stellt eine Menge an Fragen, bis man sich damit wohlfühlt, eine Art Schätzung abzugeben, wie groß man denkt, dass diese User Story ist.

In diesem Fall könnten wir uns einige Mock-Ups ansehen, gehen die User Story mit dem Kunden durch, gehen sozusagen die Funktionalität Schritt für Schritt durch. Erfragen von unserem Kunden, was alles vorhanden sein muss, damit der Kunde zufrieden ist, also die Akzeptanzkriterien. Diese Akzeptanzkriterien sollten hinten auf die User Story geschrieben werden. Ich gehe jetzt davon aus, dass du natürlich Unit-Tests und Refactoring und all die anderen guten Sachen machen wirst und das nicht explizit auf. Dann kannst du im Grunde schon eine Schätzung abgeben.

Du schätzt und sagst, die User Story sieht aus, als wäre sie ungefähr drei Punkte Aufwand – das wird mich vielleicht ein paar Tage kosten. Jetzt machen wir es noch einmal, aber diesmal mit einer etwas komplizierteren User Story, mit einem etwas komplizierteren Screen, etwas mehr Arbeit auf der Datenbankseite und etwas mehr Fehlerbehandlung und Validierung. Wir können unsere Mock-Ups mit dem Kunden durchgehen, die Akzeptanzkriterien durchgehen, es in Aufgaben unterteilen und dann abschätzen. Bei dieser Schätzung könnten wir sagen, dass wir fünf Punkte brauchen und dann machen wir es noch einmal. Vielleicht ist diese nächste User Story eine ganz kleine, einfache, alles, was wir tun, ist die Auflistung der Einträge auf dem Bildschirm. Nehmen wir an, dass es sich um eine User Story mit einen Punkt handelt . Was jetzt letztendlich passieren wird, ist, dass wir eine wirklich schöne Basis von kleinen, mittleren und großen User Stories für das Projekt entwickeln werden, und wenn wir das haben, ist es einfach eine Sache, den Rest unserer User Stories durchzugehen und sie an die entsprechenden Stellen zu schieben.

Das ist schon sehr gut, aber die Schätzung wird noch besser, wenn man sie im Team durchführt, und der Planungspoker ist eine lustige Art, User Stories in der Gruppe abzuschätzen. Das funktioniert im Grunde so: ein Kunde oder auch ein Storyteller liest dem Team eine Story vor, und die Entwickler stellen alle möglichen Fragen, um sicherzustellen, dass sie verstehen, was wirklich von der User Story verlangt wird. Das Team schätzt dann ab und manchmal sind die Schätzungen vielleicht hoch und manchmal niedrig, und es kommt zu einer großartigen Unterhaltung: „Warum denkst du, dass es so groß ist?“, „Warum denkst du, dass es so klein ist?“ „Nun, es ist, weil du dieses ganze…“ „hast du daran gedacht?“

Ob sie groß oder klein ist, ist eigentlich egal, wichtig ist, dass das Team darüber diskutiert und jemand etwas Wertvolles über die Geschichte lernt. Dann wird wieder geschätzt und hoffentlich kommt das Team nach ein paar Runden zu einer Art Konsens darüber, wie groß die User Story ist und die Teamschätzung ist besser, als wenn sie nur von einer Person gemacht worden wäre.

Das sind die Grundlagen der agilen Schätzung. Es ist keine Raketenwissenschaft! Was aber wirklich wichtig ist, ist die Größe von User Stories relativ zu bestimmen, denn wenn man das schafft, erledigt sich der Rest der Planung von selbst.