Schätzereien

Auf der Agile World hatte ich in diesem Jahr eine extrem spannende Diskussion zum Thema Schätzen.
Es ging im Wesentlichen um drei Fragen:
1. Ist Schätzen sinnvoll?
2. Wie praktikabel sind absolute Aussagen?
3. Sind Schätzgrößen einheitenlos?

Meine Gedanken zu diesen drei Fragen möchte ich hier noch einmal zusammenfassen – vielleicht sind sie ja für andere nützlich, die in ähnliche Diskussionen verwickelt werden.

Vorab muss ich sagen, dass ich zum Thema Schätzen keine absolute Meinung vertrete. Ich habe in Projekten gearbeitet, in denen Schätzungen hervorragend funktionierten, ebenso wie ich bereits in Projekten unterwegs war, die ohne Schätzungen sehr gut zurecht gekommen sind.
Gut gefahren bin ich bisher mit der Daumenregel, dass im Product Backlog geschätzte Elemente enthalten sein sollten, im Sprint Backlog nicht. Möchte ein Team das Sprint Backlog schätzen, finde ich das aber auch ok. Das Team muss sich gut damit fühlen und solange die Schätzung die Koordinationskosten nicht extrem in die Höhe treibt, kann ich damit leben.

Ist Schätzen sinnvoll?

Wenn ich als Product Owner unterwegs bin, brauche ich Schätzungen. Wozu, hat Henrik Kniberg in seinem Video Product Owner in a Nutshell hervorragend erklärt. Ohne Schätzungen kann ein Product Owner keinen Forecast machen. Der Forecast ist aber wichtig, um Investoren ein gutes Gefühl zu geben.
Wenn ich Investor bin und mein Geld in ein Softwareprojekt stecke, möchte ich wissen, wann – nach welcher Menge investierten Geldes – ich mit einem Ergebnis rechnen kann. Das muss nicht beim ersten Sprint klappen, auch nicht beim zweiten. Aber wenn die ersten fünf Sprints ergebnislos bleiben, werde ich mich einmischen. Das ist mein gutes Recht, es ist schließlich mein Geld.
Natürlich interessiert es mich als Investor nicht, wie viele Stunden für welches Feature investiert werden. Aber nach fünf Sprints möchte ich vom Product Owner wissen, wie die Velocity des Teams ist und wie die Items im Backlog geschätzt sind. Nur so kann ich entscheiden, ob das Projekt die Investition wert ist oder nicht.
Das vergessen viele vermeintliche Agilisten leider viel zu häufig. Dabei steht genau das im ersten der zwölf Prinzipien des Agilen Manifest:

Unsere höchste Priorität ist es,
den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.

Das wichtige Wort dabei ist wertvoll. Die Frage, wann eine Software wertvoll ist, hängt für einen Investor – neben vielen anderen Dingen – eben auch vom Aufwand ab, der bezahlt werden muss.

Für Investoren – und damit auch den Product Owner – ist Schätzen also durchaus sinnvoll. Das Team zieht keinen unmittelbaren Nutzen aus einer Schätzung. Deshalb sollte auch nicht das Team entscheiden, ob geschätzt wird oder nicht. Es darf aber darauf bestehen, dass die Schätzung auch als solche betrachtet wird und keine Garantie ist.

Im nächsten Eintrag werde ich auf User Stories der Größe 1 eingehen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.