Leider wird noch immer häufig „agil“ mit „planlos“ gleichgesetzt. Dies ist aber nicht der Fall. Die Art und Weise der Planung ändert sich erheblich. Durch agile Planung kann entsprechend den Erfordernissen des Planungshorizontes in einer passenden Granularität zeitgerecht eine belastbare („good enough“) Aufwandsschätzung erstellt werden. Voraussetzung ist sicherlich eine vertrauensbasierte Fehlerkultur. Was verbirgt sich hinter der agilen Planung und welche Best Practices gibt es hierzu? Erfolgsfaktoren und Antworten auf diese Frage finden Sie hier.

Kennen Sie diese Situation? Ein Key-User oder Entscheider hat eine Idee für die Optimierung des Geschäfts, wie zum Beispiel bessere Anbindung des Außendienstes über Mobile, und fragt: „Bis wann können Sie dies umsetzen und was kostet das?“ Hier gibt es unterschiedliche Antworten, die allesamt nicht gut ankommen. Auch wenn diese schon zumindest in Teilen ihre Berechtigung haben:

  • „Bremser“: „Dies müssen wir erst einmal in Ruhe analysieren. Dann können wir eine belastbare Abschätzung machen. Hierfür benötigen wir sicherlich mindestens einen Monat.“

  • „Polizist“: „Mobile ist kein Teil unserer IT-Strategie. Daher wird diese Anforderung nicht umgesetzt.“

Woran liegt dies und wie kommt man aus diesem Dilemma heraus?

Mobile kann noch kein Bestandteil der IT-Strategie sein. Wenn dies aber eine wesentliche Kundenanforderung ist, sollte die IT-Strategie nicht in Stein gemeißelt sein. Die Anforderung ist zudem sehr grob. Die damit verfolgten Ziele sind ebenso unklar wie die Randbedingungen und Erfolgsfaktoren. Von daher muss sicherlich eine Analyse erfolgen. Ob ein Monat wirklich erforderlich ist, sei dahingestellt. Die Tonart der Antwort ist weder kunden- noch lösungsorientiert. Wie geht dies besser? Die agile Planung mit dem Lean-Prinzip der Kundenwertorientierung liefert Lösungsmuster.

Durch agile Planung wird gerade so viel geplant, wie nötig, um eine fundierte Antwort schnellstmöglich abzugeben. Kundenwertorientierung stellt den Kunden in den Mittelpunkt. Es geht darum, die Ziele und die tägliche Arbeit des Kunden zu verstehen und für diesen spürbaren persönlichen Nutzen zu generieren.

In unserem Beispiel könnte eine kundenorientierte und lösungsorientierte Antwort so aussehen: „Dies hört sich interessant an. Wollen wir uns mal zusammensetzen, um über die Details zu sprechen, sodass wir eine angemessene Lösung entwickeln können?“. Das „Zusammensetzen“ sollte sicherlich systematisch durch zum Beispiel agile Planungs- und Kreativitätsworkshops erfolgen. Weitere Informationen zu den Techniken finden Sie in einem späteren Abschnitt. Zuerst schauen wir uns das Thema Planung und Agilität einzeln und in Kombination etwas näher an.

Was ist agile Planung überhaupt?

In der Planung werden ausgehend von den Anforderungen des Kunden („O-Ton Kunde“) die fachliche Lösung und deren Umsetzung in Geschäftsprozessen und IT gestaltet. Ergebnis sind zum Beispiel ein Sollkonzept oder Pflichtenheft sowie ein Umsetzungsplan mit allen erforderlichen bewerteten Maßnahmen. In der klassischen Planung (Wasserfall-Planung) erfolgt dies detailliert für alle Anforderungen, da die Stakeholder eine zuverlässige Prognose und Planungssicherheit erwarten. Das Ergebnis muss häufig „festpreisfähig“ sein. Sowohl Inhalte als auch Kosten und Zeit werden im Festpreis festgeschrieben. Die Wasserfall-Planung geht (siehe Abbildung 1) von feststehenden Anforderungen (Ergebnisse einer Analyse-Phase) aus und ermittelt hierzu die Kosten und Zeit der Umsetzung über eine detaillierte Konzeptionsphase.

Abb. 1
figure 1

Quelle: Eigene Darstellung

Wasserfall-Planung und agile Planung im Überblick

Full size image

Bei der agilen Planung wird im Vergleich nur so viel geplant, wie nötig. Was heißt dies konkret?

Ergebnis der agilen Planung ist eine priorisierte Liste aller Anforderungen, Backlog genannt, und eine gedachte Linie im Backlog, bis wohin die Anforderungen mit großer Sicherheit zum Liefertermin und mit dem vorgegebenen Budget (beziehungsweise Team) bereitgestellt werden können. Hierzu müssen die Anforderungen in einheitlicher Granularität strukturiert aufgenommen und dann priorisiert und grob bewertet werden. Die Umsetzung erfolgt dann zum Beispiel in Scrum (siehe [3]) über Sprints von festgelegter Dauer (zum Beispiel drei Wochen), in der entsprechend der Umsetzungsgeschwindigkeit („Velocity“) die jeweils prioren Anforderungen soweit heruntergebrochen werden, dass sie sich in die Iteration einpassen lassen.

In agilen Projekten gibt es zumindest zwei unterschiedliche Arten von Backlogs, das Produkt-Backlog, das alle umzusetzenden Produkt-Features beinhaltet, und das Iterations- oder Sprint-Backlog, das die in der nächsten Iteration umzusetzenden User Stories beinhaltet. Zu jedem Feature gibt es in der Regel mehrere User Stories. Features und User Stories werden in einem späteren Abschnitt weiter ausgeführt.

In Abbildung 2 wird dies schematisch mit der gedachten Linie „ziemlich sicher“ im Produkt-Backlog dargestellt. Ab und zu findet man eine zweite Linie, die „angestrebte“ Linie (siehe Abbildung 2). Darunter finden sich die weiteren Anforderungen mit niedriger Priorität. Die prioren Anforderungen werden in der agilen Planung soweit heruntergebrochen, bis eine Bewertung möglich ist. Die Anforderungen für den nächsten Sprint und gegebenenfalls einige Füllanforderungen (siehe [4]) werden bei Scrum im Rahmen der Sprint-Planung bis zur Granularität User Stories im Sprint-Backlog für die „Abarbeitung“ im nächsten Sprint bereitgestellt.

Abb. 2
figure 2

Quelle: Eigene Darstellung

Produkt-Backlog

Full size image

Eine Wasserfall-Planung erzeugt insbesondere in Auftraggeber-Auftragnehmer-Beziehungen eine scheinbare Sicherheit, dass die erhaltene Leistung genau dem Geplanten entspricht.„Man weiß, was man für sein Geld bekommt.“ Die Illusion des perfekten Plans kommt häufig von einem Wunsch nach Planungssicherheit. Leider gibt es dann ein unsanftes Erwachen, wenn die Erwartungshaltung doch nicht erfüllt wird. Mit jeder Verzögerung oder weiteren inhaltlichen Unzufriedenheit stellt sich dann Misstrauen ein, das die Zusammenarbeit zwischen Auftragnehmer und Auftraggeber zunehmend erschwert.

Dies hängt unter anderem damit zusammen, dass sich Anforderungen über die Zeit ändern. Man muss erst die wirklichen Anforderungen identifizieren und herausfinden, welche Ziele sich dahinter verbergen, um eine passende Lösung liefern zu können. Es reicht in unserem Beispiel nicht aus, die Host-Oberflächen für die Eingabe von Kontaktdaten und Aufträgen auf mobile Endgeräte zu übertragen. Die Anwendungsfälle für den Außendienst unterscheiden sich durchaus von denen des Innendienstes. Zudem ist es umso wahrscheinlicher, je länger die Umsetzungszeit dauert, dass neue Anforderungen hinzukommen. Mit dem Verstehen von Anforderungen und Erkenntnisgewinn über zum Beispiel mögliche Lösungen verändern sich die ursprünglichen Anforderungen.

Änderungen führen zu einer Planänderung. Häufig ist sogar eine Neuplanung erforderlich, da die Auswirkungen der Änderungen gesamthaft berücksichtigt und analysiert werden müssen.

Beim klassischen Wasserfall-Vorgehen müssen Änderungen über Change Requests eingesteuert werden. Dies kann insbesondere bei Festpreisprojekten sehr aufwendig und bürokratisch werden. Bei agilen Projekten werden die neuen Anforderungen entsprechend ihrer Priorität einfach im Backlog einsortiert. Bestehende Anforderungen können dann gegebenenfalls an Priorität verlieren. Die Erwartung von Änderungen ist Kernbestandteil beim agilen Vorgehen.

Die agile Planung unterscheidet sich auch im Detaillierungsgrad von der Wasserfall-Planung. In der Wasserfall-Planung werden alle Anforderungen heruntergebrochen. In der agilen Planung werden nur die Anforderungen detailliert, die absehbar umgesetzt werden. Auch die Anforderungen, die wahrscheinlich umgesetzt werden, werden nur soweit detailliert, dass eine belastbare Aufwandsschätzung durchgeführt werden kann. Dies ist eines der Prinzipien bei der agilen Planung. Schauen wir uns die verschiedenen Techniken der agilen Planung etwas näher an.

Prinzipien und Techniken der agilen Planung

Es gibt eine ganze Reihe Prinzipien und Techniken der agilen Planung. Einige davon führen wir hier weiter aus. Zu den anderen finden Sie Informationen in [2] [4], [5] und [6].

Wesentliche Techniken sind:

  • Business-Analyse-Techniken, um die wesentlichen Anforderungen zu identifizieren und zu dokumentieren. Beispiele:

    • — Kano-Modell und andere Techniken zur Klassifikation von Anforderungen (siehe [2])

    • — 5W-Fragetechnik, Gemba-Walk und Kundenwertanalyse (siehe [1]) neben anderen Ermittlungs- und Dokumentationstechniken (siehe [5])

  • Lean-Demand-Management-Techniken (siehe [4]) wie zum Beispiel:

    • — systematisches Backlog-Management für Transparenz über die Anforderungen und deren Status und Fortschritt der Umsetzung mit zum Beispiel Backlog-Grooming Meetings (siehe [5], [6] und [2]) und Dokumentation in einheitlichen Granularitäten (Investitionsthemen — Epic — Feature) sowie Zerlegen und Verschmelzen von Anforderungen [siehe [5]) entsprechend der Erfordernisse der Planungsebene

  • Lösungskonzeption

    • — High-Level Design (oder auch Up-Front Design genannt): Architekturentwurf auf konzeptioneller und logischer Ebene als fundierte mit angemessenem Aufwand erstellbare Grundlage für die Abschätzung (siehe [4])

    • — Agile Planungs- und Kreativitätsworkshops zum Beispiel auf der Basis von Design Thinking oder Leading Scaled Agile Framework (siehe [6])

  • Agiles Schätzen und Bewerten

    • — Schätz-Techniken, wie Planning Poker, Abschätzung mit Feature Points und Mapping auf Story Points zur eigentlichen Bewertung der Anforderungen und Umgang mit Unsicherheit sowie agiles Verhandeln „Was muss unbedingt geliefert werden?“ „Was kann verschoben werden?“

    • — Abschätzung der Velocity (siehe [2])

    • — High-Value-to-Cost-Ratio und Risk-First-Priorisierung (siehe [2])

  • Planung und Steuerung der Aktivitäten

    • — Roadmap-Planung (siehe [4]), Sprint-Planung sowie Feature- und Zeit-Puffer (siehe [2])

    • — „Gute“ User Stories (siehe [2])

    • — Definition von „Done“, dass nur wirklich Fertiges fertiggemeldet wird (siehe [5])

    • — Agile Prognose mit Burndown-Chart (siehe [5])

    • — Feedback-Instrumente, wie zum Beispiel Retrospektive (siehe [3])

  • Agiler Festpreis zur agilen Vertragsgestaltung (siehe [5])

Es gibt viele Best-Practice-Techniken für die agile Planung. Eine zentrale Voraussetzung ist ein systematisches Backlog-Management mit einheitlichen Granularitäten. Schauen wir uns dieses etwas näher an.

Systematisches Backlog-Management

Wie schon ausgeführt, gibt es unterschiedliche Backlogs mit unterschiedlichen Zielsetzungen. Die Inhalte, Zielsetzungen, verantwortlichen Stakeholder und die Planungsebenen unterscheiden sich erheblich. Beispiele für Backlogs sind:

  • Strategische Planungsebene: Investitionsthemen-Backlog für die Budgetierung oder die Erstellung des Projektport-folios im Rahmen der strategischen IT-Planung

  • Beispiel für einen Backlog-Eintrag: Außendienstanbindung

  • Taktische Planungsebene: Produkt-Backlog mit den Anforderungen für die Weiterentwicklung des Produktes

  • Beispiel für einen Backlog-Eintrag: Auftragsabwicklung im Kontext der Außendienstanbindung sowie Teile davon, wie zum Beispiel Kundenauftrag neu anlegen im Kontext der Außendienstanbindung Auftragsabwicklung

  • Operative Planungsebene: Sprint-Backlog mit den Anforderungen, die im Sprint umgesetzt werden sollen

  • Beispiel für einen Backlog-Eintrag: Kundenauswahl bei Neuanlage Kundenauftrag oder als User Story „Als Außendienstmitarbeiter möchte ich eine Übersicht über alle Kunden erhalten, sodass ich einen auswählen kann, um für diesen einen Auftrag zu erfassen.“

Die erforderlichen Granularitäten unterscheiden sich entsprechend der Erfordernisse der Planungsebenen erheblich (siehe Abbildung 3).

Abb. 3
figure 3

Quelle: Eigene Darstellung

Planungsebenen im Überblick

Full size image

In der strategischen Planung werden lediglich grobgranulare und in der operativen Planung detaillierte Geschäftsanforderungen benötigt. Bewährt hat sich hierzu eine Strukturierung in Investitionsthemen, Themenbereiche, Features und Realisierungsanforderungen (siehe [5]).

  • Investitionsthemen beschreiben Maßnahmen zur Umsetzung der Ziele eines Unternehmens oder einer Geschäftseinheit. Sie werden im Rahmen der Budgetierung ermittelt, bewertet und mit Budget versehen. Die Budget-Zuordnung erfolgt in der Regel für eine Planungsperiode (zum Beispiel ein Jahr) und kann im Rahmen einer rollierenden Planung, zum Beispiel je Quartal, angepasst werden.

    Investitionsthemen werden häufig durch Schlagworte benannt, wie zum Beispiel „Einführung Customer Relationship Management (CRM)“ oder „Partnerintegration des Unternehmens Energy Verde“.

  • Themenbereiche (Epic) beschreiben die konkreten Kundenbedürfnisse auf höchster Ebene. Sie füllen die Investi-tionsthemen mit Inhalten, sodass diese grob abgeschätzt und priorisiert werden können. Jeder Themenbereich kann jeweils unabhängig bewertet und priorisiert werden. Die Umsetzung eines Themenbereichs erfolgt über Projekte oder Wartungsmaßnahmen in einem oder mehreren Releases eines oder mehrerer IT-Systeme. Der Inhalt eines Themenbereichs wird in der Regel in wenigen Sätzen oder Aufzählungspunkten beschrieben. Die verfolgten Ziele müssen dabei klar hervorgehen.

    Beispiele für Themenbereiche für das Investitionsthema „CRM“ sind „Geschäftspartnermanagement“, „Call-Center-Unterstützung“ und „Servicesteuerung“. Im agilen Umfeld wird häufig der Begriff „Epic“ in diesem Kontext verwendet (siehe [6]).

  • Features sind Funktionalitäten eines oder mehrerer Systeme oder Produkte, die für den Anwender einen unmittelbaren Wert darstellen. Sie werden vom Anwender als ein sinnvolles Ganzes wahrgenommen. Bei (Software-)Produkten wird häufig bei der Bestimmung der Features hinterfragt, ob dieses für den Käufer kaufentscheidend ist.

    Ein Feature wird über ein Projekt oder eine Wartungsmaßnahme eines Release in einem oder mehreren miteinander verbundenen IT-Systemen umgesetzt. Für die Priorisierung und Umsetzungsplanung werden Features häufig in Teil-Features zerlegt, wenn eines von ihnen nicht in einer Iteration umgesetzt werden kann.

    Beispiele für Features für den Themenbereich „Geschäftspartnermanagement“ sind „Geschäftspartner-Stammdatenverwaltung“, „Geschäftspartner-Segmentierung“ und „Marketingaktions-Schnittstelle“. Teil-Features der „Geschäftspartner-Stammdatenverwaltung“ sind „Geschäftspartner-Stammdatenpflege“, „Beziehungsgeflechtpflege“ und „Kündigungsbearbeitung“.

    Ein Feature wird immer in einem Release, gegebenenfalls über mehrere Iterationen, umgesetzt. Der Umsetzungsaufwand für ein Feature sollte unter 100 Personentagen (PT) liegen. Liegt der Umsetzungsaufwand deutlich über 100 PT, muss für die Release-Planung eine weitere Detaillierung auf Teil-Features erfolgen.

  • Eine Realisierungsanforderung ist eine Aussage über eine Eigenschaft oder eine Leistung, die ein IT-System aus Sicht des Systemnutzers erbringen muss. Sie beschreibt nicht, wie diese Leistung zu erbringen ist. Realisierungsanforderungen werden im Rahmen vom Anforderungsmanagement in Projekten oder Wartungsmaßnahmen ermittelt. Eine Realisierungsanforderung bezieht sich immer auf ein System oder Produkt.

    Eine Realisierungsanforderung wird über ein Projekt oder eine Wartungsmaßnahme in einer Iteration umgesetzt.

    Im agilen Umfeld wird häufig stattdessen die Einheit einer User Story (siehe [6]) verwendet.

    Realisierungsanforderungen werden immer in einer Iteration umgesetzt. Der Umsetzungsaufwand sollte daher kleiner gleich 10 PT sein. Damit der Business-Analyst den Umsetzungsfortschritt in Projekten/Wartungsmaßnahmen beurteilen kann, muss jede Realisierungsanforderung einem (Teil-)Feature zugeordnet sein.

Für die strategische (Unternehmensplanung) und taktische Planungsebene (Projektportfolio- und Roadmap-Planung) wird eine gröbere Granularität benötigt, da hier frühzeitig und mit verhältnismäßig geringem Aufwand sichergestellt werden muss, dass das Richtige getan wird. Eine leichtgewichtige strategische und taktische Planung mit Bodenhaftung ist notwendig. So können Fehlinvestitionen vermieden und die relevanten Geschäftsanforderungen schnell und angemessen umgesetzt werden.

Die Detailierung auf Ebene von Features beziehungsweise Teil-Features erfolgt in enger Abstimmung mit den Fachbereichen und den Umsetzungseinheiten. Auf dieser Granularitätsebene wird das Planungsergebnis (Release oder Projekt) inhaltlich greifbar, Lösungsdetails sind aber noch nicht erarbeitet. Die Planung ist schon so konkret, um eine Orientierung für die konkrete Umsetzung in den Projekten zu geben. Ein kritischer Punkt ist hier sicherlich die Aufwandsschätzung. Man muss hinreichend zuverlässige Aussagen darüber machen, was in einem Release enthalten ist und was nicht. Die Schätzung auf operativer Ebene ist konkreter und damit einfacher. Hierzu werden in der agilen Planung die Features, die absehbar im nächsten Sprint umgesetzt werden sollen, in User Storys heruntergebrochen. Jede User Story ist so zu formulieren, dass sie innerhalb von ein bis zwei Wochen umsetzbar ist. So lassen sich User Storys in ihrer Komplexität schnell schätzen. Hierzu wird die Schätzeinheit Story Points verwendet. Schauen wir uns das Schätzen etwas näher an.

Schätztechniken

Für das Schätzen gibt es eine Reihe von Tipps und Tricks (siehe [2] und [5]). Ein paar wesentliche Beispiele sind:

  • Feature und Story Points („good enough“ Aufwandsschätzung): Im Unterschied zur Wasserfall-Planung wird bei der agilen Planung mit Feature Points die Komplexität der umzusetzenden Features vergleichend abgeschätzt und nicht der Aufwand. Story Points sind die Schätzeinheit für User Storys. Sie werden durch das Vergleichen von Storys im „Planning Poker“ vergeben. Durch das Mapping zu Story Points nach den ersten Sprints mit empirischen Daten kann die Größe der Features abgeschätzt werden.

    Vorteile:

    • — Dies ist eine vergleichende Schätzung, die schneller als die Schätzung absoluter Größen durchführbar ist. Menschen tun sich mit der Schätzung absoluter Dinge schwer. Es fällt viel leichter, Dinge in Relation zueinander zu setzen und zu erkennen, was größer und was kleiner ist. Auch hier sind einheitliche Granularitäten wichtig. Durch den Vergleich mit anderen wird aber schnell ersichtlich, ob ein Feature für eine Schätzung zu groß ist. Wenn es noch nicht greifbar oder vergleichbar ist, muss es heruntergebrochen werden. Wenn dies zeitlich nicht möglich ist, kann mit Puffern gearbeitet werden. Hierzu sei auf [2] verwiesen. Auf jeden Fall geht man bei der agilen Planung offen mit der Unsicherheit um.

    • — Die Komplexität ist objektiver einschätzbar. Sie bleibt im Gegensatz zum Aufwand im Projektverlauf gleich und ist unabhängig vom Umsetzer. Die Aufwände verringern sich dagegen zum Beispiel für ähnliche Aufgaben aufgrund des Erfahrungsgewinns, wenn sie von den gleichen Personen umgesetzt werden.

  • Planning Poker zur teambasierten transparenten Abschätzung der Komplexität.

    Für das Planning Poker gibt es zum Beispiel Kartensätze mit Fibonacci-Zahlen. Die Abstände zwischen den Zahlen werden also immer größer. Die Karten (die Zahlen auf den Karten) definieren quasi Aufwandskategorien. Jedes Teammitglied muss sich in der Sprint-Planung entscheiden. Jedes Teammitglied legt für jede User Story verdeckt (und damit von anderen unbeeinflusst) eine Karte mit dem geschätzten Komplexitätswert auf den Tisch. Dann werden alle Karten gleichzeitig aufgedeckt. Gibt es nach dem Aufdecken der Karten große Abweichungen in der Einschätzung, dann wird im Team über diese unterschiedlichen Bewertungen diskutiert. Nach ein bis zwei weiteren Schätzrunden sollten die Werte dann konvergieren. Auf diese Weise gelangt das Team schnell zu einem tieferen Verständnis der umzusetzenden Storys und zu guten Schätzwerten.

  • Velocity zur Umrechnung von Komplexität auf Aufwand. Die Velocity gibt an, wie viele Story Points im Sprint umgesetzt werden können. Bei den ersten Sprints ist die Velocity noch nicht bekannt. Hier können historische Daten herangezogen werden, wenn die Teamzusammensetzung vergleichbar ist. Eine andere Alternative ist ein Durchstich, in dem ein kleiner Ausschnitt des Gesamtprojektes umgesetzt wird, um ein Gefühl für die Velocity zu erhalten. Im Burn-down-Chart wird grafisch der verbleibende Aufwand in einem Projekt in Relation zur verbleibenden Zeit dargestellt (siehe [3]).

Weitere Tipps und Tricks zum agilen Schätzen finden Sie in [2] und [5].

Ein weiterer Problempunkt beim agilen Planen ist der Umgang mit der Unsicherheit. Für die Festlegung von Budgets oder die Beauftragung von Dienstleistern wird eine Grundlage benötigt. Eine Wasserfall-Planung liefert hier, wie schon ausgeführt, nur eine Scheinsicherheit. Dies hängt insbesondere mit dem Verändern der Anforderungen über die Zeit zusammen. Wie kommt man aus diesem Dilemma heraus? Auch hier gibt es eine Reihe von Best Practices (siehe [5]). Eine davon ist der agile Festpreis.

Der agile Festpreis schafft eine vertragliche Grundlage und ein Verfahren für die Änderung von Anforderungen im Projektverlauf. Neue Anforderungen tauchen auf, die Priorisierung von Anforderungen ändert sich oder der Inhalt bereits geplanter Anforderungen wird angepasst. Darüber hinaus kann sich die Umsetzung von Anforderungen verzögern. Ursachen hierfür können sein, dass der Umsetzungsaufwand für Features oder Realisierungsanforderungen zu gering eingeschätzt wurde, dass bestimmte Skills im Projektteam fehlen oder dass technische Risiken falsch eingeschätzt wurden.

Mit diesen Veränderungen muss auch vertraglich umgegangen werden, wenn die Umsetzung eines oder mehrerer Releases unternehmensextern oder intern beauftragt wurde. Ein Modell dafür ist der agile Festpreis.

Ein agiler Festpreis ist ein verbindlicher Gesamtpreis für eine gegebene Menge von Anforderungen mit inhaltlichem Spielraum. Der Auftraggeber erhält realisierte Anforderungen im Gesamtwert des Gesamtpreises und kann die Inhalte im Projektverlauf ändern. Hierzu werden ein für den Auftraggeber transparentes Verfahren für die Aufwandsschätzung bei neuen oder veränderten Geschäftsanforderungen sowie das Verfahren für den Austausch von Anforderungen im Lieferumfang vereinbart. So hat der Auftraggeber Planungssicherheit und zugleich Anforderungsflexibilität. Lästige und aufwendige Change-Request-Verfahren werden eingespart.

Der zeitliche Verlauf bei einem agilen Festpreis-Projekt ist in Abbildung 4 plakativ dargestellt. Zum Beauftragungszeitpunkt sind eine Reihe von Features und deren Aufteilung auf die Inkremente zwischen Auftraggeber und Auftragnehmer festgelegt. Auch der Gesamtpreis (Festpreis) ist fixiert. Mit der Planung jedes Inkrements (gegebenenfalls auch jeder Iteration) wird die initiale Planung verändert und ursprünglich eingeplante Features werden durch gegebenenfalls neue oder veränderte Features ersetzt, sofern dies in den Festpreisumfang passt.

Abb. 4
figure 4

Quelle: Eigene Darstellung

Agiler Festpreis im Überblick

Full size image

Zusammenfassung

Eine agile Planung ist nicht planlos. Es wird nur so viel geplant, wie nötig ist, um eine belastbare Aufwandsschätzung durchzuführen. So kann man mit angemessenem Aufwand sicherstellen, dass die richtigen Dinge getan werden. Sicherlich gibt es Unsicherheiten sowohl in der agilen als auch in der Wasserfall-Planung. Während die Wasserfall-Planung eine Pseudo-Unsicherheit erzeugt, geht man mit dieser Unsicherheit in der agilen Planung offen um. Exakte Planungen über große Zeitstrecken sind eine Illusion. Durch agile Planung kann entsprechend den Erfordernissen des Planungshorizontes in einer passenden Granularität zeitgerecht eine belastbare („good enough“) Aufwandsschätzung erstellt werden. So kann mit angemessenem Aufwand eine Grundlage für die Umsetzung und auch für Verträge geschaffen werden, die sich an Veränderungen anpasst.