Zeitliches Budget statt Einschätzungen in Scrum
Ich habe bereits darüber geschrieben, dass wir in Scrum nur Einschätzungen vornehmen sollten, wenn das Resultat auch tatsächlich Auswirkungen auf unsere Handlungen hat. Normalerweise bedeutet das, dass ein Team nur Arbeit einschätzen sollte, wenn diese Einschätzung entweder:
- dem Product Owner erlaubt, eine bessere Priorisierung des Product Backlogs vorzunehmen, oder
- den Product Owner einfacher eine Antwort darauf finden lässt, wann eine gewisse Menge an Funktionalität geliefert werden kann.
Aber auch wenn wir eigentlich nur in diesen Situationen Einschätzungen brauchen, wird es immer Arbeiten geben, die für ein Team sehr schwer oder fast unmöglich einzuschätzen sind. Lassen Sie uns einmal schauen, was die beste Lösung ist, wenn ein Scrum Team eine schwierige Einschätzung vornehmen soll. Beginnen wir aber zuerst mit einigen Gründen, warum ein agiles Team vielleicht nicht so gut darin ist, Einschätzungen vorzunehmen.
Warum ein Scrum Team manche Arbeiten vielleicht nicht gut einschätzen kann
Dafür kann es mehrere Gründe geben. Häufig kommt es vor, wenn ein Team in einer neuen Domäne oder mit einer neuen Technologie arbeitet.
Nehmen wir einige sehr erfahrene Teammitglieder, die bereits seit Jahren beispielsweise an Web-Applikationen für das Gesundheitswesen arbeiten. Dann sollen sie allerdings Online-Banking-Applikationen für Mobilgeräte entwickeln. Sie können einige wilde Vermutungen zu diesen neuen Apps anstellen. Das ist aber auch schon alles, was eine solche Einschätzung wäre – eine wilde Vermutung.
Ebenso können sich die Teammitglieder mit Einschätzungen schwertun, wenn sie noch kein richtiges Team geworden sind. Wenn man heute sieben Leute zum ersten Mal zusammenbringt und sie umgehend bittet, einen Product Backlog zu bewerten, werden ihre Einschätzungen grauenhaft sein. Niemand weiß so genau, wer was kann (auch wenn die Leute behaupten, gewisse Fähigkeiten zu haben). Sie wissen auch noch nicht, wie gut sie zusammenarbeiten können usw. Nachdem ein solches Scrum Team einige Monate oder vielleicht sogar nur einige Wochen zusammengearbeitet hat, wird sich die Qualität ihrer Einschätzungen schon drastisch verbessert haben.
Es gibt auch viel grundlegendere Gründe dafür, dass eine Einschätzung so schwierig ist. Manche Arbeiten sind einfach schwer einzuschätzen. Wie lange dauert es zum Beispiel, bis Krebs geheilt wird? Oder wie lange wird es dauern, dieses neue System zu designen? Scrum Teams hassen es, solche Arbeiten einschätzen zu müssen. In manchen Fällen ist es eben einfach soweit, wenn es soweit ist – wie in dem Beispiel mit dem Krebs. In anderen Fällen ist es soweit, wenn die Zeit um ist – wie in dem Beispiel mit dem Design des Systems.
Planen statt Einschätzen
In solchen Fällen sollte man das alles aus einer anderen Richtung angehen. Anstatt das Scrum Team zu fragen „Wie lange wird das dauern?”, überlegt das Unternehmen „Wie viel Zeit ist uns das wert?” und in der Tat erhält man so eher ein zeitliches Budget für ein Feature als eine Einschätzung. Erstellt man ein Budget für ein Feature, nutzt man im Grunde genommen das agile Prinzip des „Timeboxings” (Vorgeben eines Zeitrahmens). Das Unternehmen sagt: „Dieses Feature ist uns vier Iterationen wert.”
In einer gesunden und vernünftigen Organisation sollte das Team eine Chance bekommen, zu sagen, ob sie in der vorgegebenen Zeit wohl gute Arbeit leisten können. Wenn das Team nicht glaubt, etwas entwickeln zu können, wofür das Unternehmen nur eine gewisse Zeit opfern möchte, sollte ein Gespräch folgen.
Was wäre, wenn das Budget um ein oder zwei Sprints verlängert werden könnte? Können bestimmte Teile des Features als optional angesehen werden, so dass die wichtigen Features innerhalb des Zeitrahmens geliefert werden können?
Ein zeitliches Budget zu haben, gibt einer solchen Diskussion einen Rahmen.