Lean Agile Budgeting – ohne Kostenstellen und dennoch transparent und flexibel

Lean Agile Budgeting – ohne Kostenstellen und dennoch transparent und flexibel

Der Aufbau einer agilen Organisation mit mehreren agilen Teams ist eine große Herausforderung für Führungskräfte, Teammitglieder und agile Coaches. Denn es verändern sich nicht nur das Vorgehen und die Rollen grundlegend, sondern auch das neue agile Mindset erfordert eine erhebliche Umstellung für alle Beteiligten. Bei all den notwendigen Veränderungen wird anfangs eine Frage meist übersehen: Wie erfolgt die Budgetierung meiner Teams innerhalb meiner agilen Organisation?

In der „klassischen“ Welt wird einem Projekt im Vorhinein ein festes Budget zugewiesen. Die Teammitglieder buchen ihre Aufwände auf einzelne Phasen oder Tätigkeiten in diesem Projekt, parallel wird die Einhaltung des vorgegebenen Budgets überwacht. In einer agilen Organisation denken wir aber nicht mehr in Projekten, sondern in kontinuierlich arbeitenden Teams. Da es keine ausgewiesenen Analysephasen gibt, kennen wir im Vorhinein nicht den gesamten Umfang aller Tätigkeiten, wodurch kein Gesamtbudget festgelegt werden kann. Dennoch will der Auftraggeber auch im agilen Umfeld wissen, was die Umsetzung seiner Anforderungen kostet. Woher kommt das Budget? Buchen die Teams auf User Stories (US)? Erfolgt die Abrechnung nach Story Points (SP)? Um diese Fragen zu beantworten, betrachten wir zuerst die Budgetierung eines einzelnen agilen Teams und übertragen diese dann auf die gesamte Organisation.

Budgetierung eines einzelnen agilen Teams

Die Grundvorrausetzung für die Budgetierung eines einzelnen agilen Teams, ist ein stabiles Team, dessen Mitglieder 80-100 % ihrer Zeit dem Team widmen. Jedes Teammitglied muss daher von weiteren Aufgaben „freigestellt“ werden, damit es sich voll und ganz auf die Tätigkeiten in seinem Team konzentrieren kann. Wie es im agilen Umfeld üblich ist, werden alle Anforderungen in User Stories erfasst und im Backlog priorisiert. Ebenfalls üblich ist deren Aufwandschätzung in Form von Story Points. Nach circa drei Sprints kann man die sogenannte „Team Velocity“ berechnen. Diese entspricht den durchschnittlich erledigten Story Points je Sprint. Schauen wir uns hierzu ein Beispiel an:
Im 1. Sprint wurden User Stories mit einem Aufwand von insgesamt 40 Story Points abgeschlossen,
im 2. Sprint waren es 50, im dritten Sprint 60 Story Points. In Summe sind das 150 Story Points in drei Sprints, was eine „Velocity“ (Durchschnittsgeschwindigkeit) von 50 Story Points je Sprint ergibt. Jeder weitere Sprint beeinflusst damit auch unsere Velocity, welche eine Momentaufnahme der aktuellen Team Performance ist.

Die Velocity ist eine wichtige Komponente unserer Budgetierung. Der andere Baustein sind die tatsächlichen Kosten, welche durch unser Team anfallen. Hier sei noch einmal daran erinnert, dass ein Teammitglied möglichst seine komplette Arbeitszeit im agilen Team verbringt und andere Aufgaben abgeben muss. Unter dieser Voraussetzung sehen wir uns folgendes Beispiel an:
In unserem agilen Team arbeiten fünf Personen, jede Person kostet 1.000 €/ Tag. Das gesamte Team kostet dementsprechend 5.000 €/ Tag. Ein Sprint dauert zwei Wochen, also zehn Arbeitstage. Damit kostet unser Team 50.000 €/ Sprint. Wie im vorherigen Abschnitt berechnet, liegt die Velocity des Teams aktuell bei 50 Story Points/ Sprint. Teilt man nun die Kosten durch die Velocity, erhält man 1.000 €/ Story Point. Das bedeutet, jeder Story Point, der in diesem Team umgesetzt wird, verursacht Kosten von 1.000 €. Mit diesem Wert können wir nun die Kosten jeder User Story berechnen, indem wir die Aufwandschätzung – also die Story Points – mit 1.000 € multiplizieren.

In der Praxis läuft der Prozess folgendermaßen ab:
Je nach Budget entscheidet der Sponsor, wie lange er das agile Team finanzieren kann. In unserem Beispiel könnte er das agile Team mit 500.000 € Budget für zehn Sprints beauftragen – völlig unabhängig von den Inhalten, die im Team umgesetzt werden. Wir denken im Agilen ja nicht in Projekten. Der Auftraggeber beschreibt dem Product Owner seine Anforderungen und Wünsche. Daraus erstellt der Product Owner mit seinem Team ein Backlog mit User Stories und einer Aufwandschätzung in Story Points. Die wichtigsten Anforderungen stehen dabei ganz oben.
Sind die ersten Sprints geschätzt, bekommt der Auftraggeber vom Team eine Rückmeldung zur benötigten Umsetzungsdauer seiner Anforderungen (basierend auf der Team Velocity) und damit eine erste Kostenindikation.

Jetzt beginnt das Team mit der Umsetzung der am höchsten priorisierten User Stories. Nach jedem Sprint gibt der Auftraggeber dem Team Feedback und kann bei Bedarf die Priorisierung anpassen, neue Inhalte zum Backlog hinzufügen oder bestehende abändern. Dieser Zyklus wiederholt sich, bis eines von zwei Ereignissen eintrifft:

  • Der Auftraggeber ist mit dem Ergebnis innerhalb der zehn Sprints zufrieden, es erfolgt die Abrechnung basierend auf den umgesetzten Story Points und die Teams kümmern sich um neue Themen.

  • Der Auftraggeber ist mit dem Ergebnis nach Abschluss des zehnten Sprints nicht zufrieden. Jetzt müssen Sponsor und Auftraggeber entscheiden, ob sie weiteres Budget beschaffen, um weitere Sprints zu finanzieren, oder ob sie den aktuellen Stand ausliefern möchten.

Budgetierung einer agilen Organisation

Grundsätzlich verhält sich die Budgetierung in einer agilen Organisation sehr ähnlich zu der eines einzelnen agilen Teams. Allerdings haben wir in einer Organisation mehrere Teams und auch die Anforderungen sind umfangreicher. Daher wird eine weitere Ebene über den User Stories benötigt, die sogenannten Epics. Diese bilden eine inhaltliche Klammer um mehrere User Stories und repräsentieren damit größere Anforderungen. Epics können auch durch mehrere Teams gleichzeitig bearbeitet werden. Anstatt die Velocity eines einzelnen Teams und die Aufwände einzelner User Stories zu bestimmen, muss in einer agilen Organisation die Velocity aller Teams und die Aufwände der Epics ermittelt werden. Hierbei ist zu beachten, dass die vom Team vergebenen Story Points und die daraus entstehende Velocity komplett team-spezifisch sind und nicht mit anderen Teams verglichen werden können. Das heißt, die Aufwandschätzung der Epics muss von den Einzelaufwänden der User Stories entkoppelt werden.

Hierfür wird ein einzelnes Referenz-Epic bestimmt, dessen Aufwand mit allen Product Ownern der einzelnen Teams in Story Points festgelegt wird. Alle weiteren Epics werden jetzt referenziell zu diesem Epic geschätzt. Analog der Schätzung von User Stories, nur mit entsprechend höheren Werten. Epics sollten ebenfalls in einem Sprint umgesetzt werden, bei Bedarf auch durch mehrere Teams. Dadurch ergibt sich für die Budgetierung unserer agilen Organisation ein ähnliches Vorgehen wie für ein einzelnes Team. Wir legen die Velocity anhand der erledigten Epics in einem Sprint fest. Dieser Wert umfasst die Leistung aller Teams, da alle Teams an den Epics arbeiten. Als Beispiel nehmen wir 800 Story Points/ Sprint. Nehmen wir an, wir haben fünf Teams, bestehend aus jeweils acht Personen. Jede Person kostet 1.000 €/ Tag. Damit kostet unsere agile Organisation in einem Sprint: 5 Teams x 8 Personen x 10 Tage x 1.000 € = 400.000 €/ Sprint. Analog zur Budgetierung einzelner Teams wird dieser Wert jetzt durch die aktuelle Velocity geteilt. In unserer agilen Organisation kostet damit die Umsetzung eines einzelnen Story Points 500 €. Basierend auf dieser Kennzahl können den Sponsoren und Auftraggebern der Organisation die Kosten und Umsetzungsdauer für geschätzte Epics genannt werden.

Abschließend noch zwei Hinweise:

  • Es empfiehlt sich bei großen Epics, zuerst ein sogenanntes MVP (Minimum Viable Product) festzulegen, dieses zu schätzen und zu implementieren. Erst danach werden weitere Ausbaustufen umgesetzt. Dadurch bleibt man flexibel und muss sich nicht zu Beginn mit dem Gesamtergebnis beschäftigen, welches sich im Laufe des Entwicklungsprozesses höchstwahrscheinlich noch ändern wird.

  • Das gesamte Budget der Organisation läuft auf nur eine Kostenstelle, auf welche auch die Teams buchen. Die Verteilung der Aufwände lässt sich direkt an den Story Points der Epics ablesen. Als Beispiel: Die Teams haben ein Gesamtbudget von 100.000 € und setzen damit 1.000 Story Points um, welche sich auf vier Epics verteilen.
    Epic 1: 300 SP = 30 % = 30.000 €
    Epic 2: 200 SP = 20 % = 20.000 €
    Epic 3: 400 SP = 40 % = 40.000 €
    Epic 4: 100 SP = 10 % = 10.000 €

Jede neue Anforderung wird nun in Epics aufgeteilt und in Story Points geschätzt. Dadurch können die Kosten direkt ausgewiesen und zugeordnet werden. Einfach, flexibel und transparent.

Langfristige Planung und Controlling trotz agilem Umfeld

Wir hören oft, dass im agilen Umfeld keine langfristige Planung möglich sei und dass das Controlling sowie Aussagen über Aufwände und Kosten sehr schwierig sind.

Der beschriebene Q_PERIOR-Ansatz soll verdeutlichen, wie wir mit Hilfe von Story Points, der Velocity und dem Tagessatz auch im agilen Umfeld Aussagen zur Dauer, den Kosten und den geplanten Inhalten treffen können. Gleichzeitig sind wir damit schneller, transparenter und auch ehrlicher als viele Schätzungen im klassischen Umfeld. Und das Beste daran ist, unser agiles Arbeiten wird dadurch in keiner Weise eingeschränkt.

Agile Transformation

Für den Aufbau einer erfolgreichen agilen Organisation reicht der Entschluss, agil arbeiten zu wollen, allein nicht aus. Die verschiedenen Frameworks und Methoden bieten einen guten Leitfaden für agiles Arbeiten, die Anpassung auf Ihr jeweiliges Vorhaben darf aber nicht fehlen. Erfahren Sie, wie die agile Transformation gelingen kann.

Mehr erfahren

Mehr zum Thema

WIR SIND FÜR SIE DA!

Mit Q_PERIOR steht Ihnen ein starker Partner zur Seite.
Wir freuen uns auf Ihre Herausforderung!