Dieser Artikel setzt die hier begonnene Serie fort.
Wenn es um Scrum-Vorhersagen geht, liegt der Fokus von Scrum-Teams, dem PO und Agile Coaches meiner Erfahrung nach meist vor allem auf dem jeweils nächsten Scrum-Sprint. Dabei spielen unterschiedliche Interessen und Ziele eine Rolle:
- Der Scrum Master legt großen Wert darauf, dass die Teams sich nicht ständig überschätzen, um sich nicht zu überlasten. Sondern nicht mehr Aufgaben für den nächsten Sprint annehmen, als was sie glauben, tatsächlich schaffen zu können.
- Der PO möchte möglichst viel von seinen hoch prioren Zielen im Sprint umgesetzt sehen.
- Das restliche Team möchte sich fordern, aber nicht überfordern. Ferner möchten alle im Team ausgelastet sein, vor allem, wenn sie nach Arbeitsstunden bezahlt werden (=selbstorganisiertes Team-Ressourcen-Management). Außerdem möchten sie PO und Stakeholder zufrieden stellen.
Meist beobachte ich, dass Teams einen Sprint regelmäßig viel zu optimistisch planen. Insbesondere dann, wenn viele Aufgaben „doch fast fertig“ sind, und der äußere Druck zur Fertigstellung steigt. Wenn es zudem keine negativen Folgen für das Team hat, die eigene Leistung bei der Scrum-Sprint-Planung ständig zu überschätzen, sind „Überplanungen“ von 50-100% keine Seltenheit.
Allerdings muss das nicht notwendigerweise schlecht sein. Denn auch ein derart zu groß geratenes WIP-Limit gibt noch mehr Fokus, als wenn es gar keinen umfangsbegrenzten Sprint gäbe. Ferner ist – was manchmal auch vergessen wird – vor allem das Sprint-Ziel wichtig, das erreicht werden sollte. Dieses gibt dem Team den stärksten gemeinsamen Fokus. Solange das Sprintziel – alternativ die kurzfristig wichtigsten Aufgaben – in der Regel zuverlässig erreicht werden, ist es OK, wenn einige davon nicht betroffene Aufgaben nicht fertig werden. Übrigens: es ist sogar gut für die Motivation des Teams, wenn es sich bei der Sprint-Vorhersage eigenverantwortlich regelmäßig an oder sogar deutlich über die eigenen Grenzen bringt, was es schaffen kann.
Interessant: einzelne Sprints sind den Stakeholdern oft gar nicht so wichtig, sondern eher ein taktisches oder strategisches Vorankommen. Daher kommt auch bei laufender Überschätzung nicht unbedingt negativer Druck oder Stress auf das Team. Sehr wohl aber dann, wenn auch nach mehreren Sprints keine signifikanten Fortschritte in Richtung der Vorstellungen der Stakeholder von diesen erkannt werden.
Back to the log: Backlog-Items als Kapazitätsmaß
Ausgangspunkt meiner Überlegungen zur geeigneten Maßeinheit waren Infoveranstaltungen und Beiträge zur „Monte-Carlo-Simulation„, die zumindest theoretisch auch zur Kapazitätsberechnung dienen kann. Manchmal (wie im Beispiel auf Scrum.org) werden als Grundlage für diese Berechnungen keine „Story Points“ oder ähnliche „Schätzmaße“ des Teams benutzt. Sondern die reine Anzahl an Backlog-Items, die in den vorherigen Sprints geschafft wurde.
Der Hauptgrundgrund dafür ist wiederum das oben schon erwähnte agile Prinzip, die Menge nicht getaner Arbeit zu minimieren: Denn würden wir Team-Schätzungen als Berechnungsbasis verwenden, hätten wir ein Problem mit der in die Zukunft gerichteten Planung. Denn dann müssten die zukünftigen Backlog-Items ja schon im Detail vom Team geschätzt sein, um beurteilen zu können, wann sie voraussichtlich fertig sind. Und wir hätten, falls diese Aufgaben dann doch nie oder erst sehr viel später umgesetzt werden, unnötige Arbeit geleistet.
Statt einer Detailschätzung ist nur wichtig, dass der Ersteller der Items erfahren genug ist (eventuell zieht er einen Experten mit hinzu), um sie in der Regel kleiner zu schneiden als einen Sprint. Konkret kann dann eine empirische Herleitung unserer Sprint-Kapazität wie folgt aussehen:
Vorteile – Backlog-Items als Kapazitätsmaß
Die Anzahl an Backlog-Items als Kapazitätsmaß zu verwenden, hat einige entscheidende Vorteile:
Die Aufgaben müssen nicht vom Team geschätzt werden. Wäre eine Team-Schätzung notwendig, so wären der PO und andere Anwenderexperten im Team meist nicht in der Lage, genug Items für eine signifikante Vorschau über den aktuellen Sprint hinaus „bereit“ zu machen.
Nachteile
Der Nachteil ist natürlich, dass die Aufgaben möglicherweise doch zu groß sind für nur einen Sprint. Und das eventuell Aufgaben fehlen,