Von Use Cases zu User Stories
Wir analysieren Anforderungen nach einer definierten Methodik, deren Ursprung in der Use Case Analyse nach Alistair Cockburn (Crystal Clear) liegt, und die wir in den letzten Jahren an unser Vorgehen nach Scrum angepasst haben (Epics, User Stories, Product Backlog). Auch wenn wir heute Anforderungen effizienter mittels User Stories darstellen können, haben wir auch jahrelang mit Use Cases gearbeitet und sind in der Lage damit umzugehen, oder auch diese bei Bedarf in User Stories überzuführen. Nicht zuletzt handelt es sich sowohl bei Crystal Clear als auch Scrum um Methoden, denen beiden die Prinzipien des agilen Manifests zu Grunde liegen.

Inspect and Adapt
Wir folgen nicht sklavisch einem vorgegebenen Prozess sondern hinterfragen ständig Nutzen und Effizienz jedes Elements unseres Vorgehens. Aus unserer praktischen Erfahrung leiten wir laufend Verbesserungen ab, die wir kontrolliert und ehestmöglich in unsere Methodik einfließen lassen. Verbesserungen und neue innovative Ansätze werden auf diese Weise von uns adaptiert, über welche wir auch häufig in Vorträgen  berichten.

Push vs. Pull
Klassische Analyse verfolgt einen „Push“ Ansatz, alle Anforderungen zu Beginn des Projekts möglichst vollständig und detailliert zu erfassen. Das verursacht eine Reihe von Problemen in der Praxis:

• Aktualität: die Verwaltung der Anforderungen wird sehr umfangreich. Viele Details werden schon zu Beginn unrichtig erhoben, weil die Anwender mit der Fülle von Fragen überfordert sind oder Details noch gar nicht festgelegt werden können. Selbst wenn alle Details im Vorhinein richtig festgelegt werden, unterliegt jedes Projekt äußeren Einflüssen, die unvorhersehbare Änderungen von Anforderungen bedingen. Dieser Zustand verschärft sich im Laufe des Projekts, wenn Änderungen oder notwendige Berichtigungen nicht mehr konsistent nachgezogen werden können.
• Verbindlichkeit: Die Folge ist, dass Anwender die festgelegten Details nicht mehr als verbindlich ansehen, und das Umsetzungsteam in Folge ebenso kein Vertrauen mehr in die erfassten Anforderungen hat. Letztendlich sind erfasste Details der Anforderungen jedoch Gegenstand von Vereinbarungen und Verträgen zwischen den Projektbeteiligten. Sie stellen erhebliches Konfliktpotential am Ende des Projekts dar, wenn sie inkonsistent sind oder nicht eingehalten wurden.
• Ungenutzte Funktionalität: selbst wenn streng nach Spezifikation implementiert wurde, stellt das noch immer nicht den Erfolg des Projekts sicher. Studien zeigen immer wieder, dass ein erheblicher Anteil implementierter Funktionalität im Endeffekt kaum oder gar nicht genutzt wird. Das vergeudet nicht nur Ressourcen, die für dringender benötigte Funktionalität eingesetzt werden könnten. Auch die Komplexität für den Anwender und der Aufwand für die Wartung werden dadurch unnötig erhöht.

Im Gegensatz dazu verfolgen wir einen „Pull“ Ansatz bei der Analyse, bei dem Informationen nur dann erhoben werden, wenn diese auch tatsächlich benötigt werden. Im Wesentlichen sind dabei folgende drei Fragestellungen für uns relevant:

• WARUM? Vor Beginn eines Projekts erheben wir immer den eigentlichen Nutzen oder Grund, der eine Investition in das Projekt rechtfertigt. Dieser ist auch der ultimative Gradmesser für den Erfolg des Projekts. Der Nutzen wird von uns daher zu Beginn explizit und in Abstimmung mit den Stakeholdern erhoben und dokumentiert. Ändert sich der erwartete Nutzen eines Projekts, hat das erhebliche Auswirkungen auf das Projekt.
• WAS? Mit dieser Fragestellung erheben wir zu Beginn des Projekts einen angenommenen Funktionsumfang für das Projekt, soweit sich dieser vorab aus dem gewünschten Nutzen ableiten lässt. Dies entspricht dem gedachten Weg zum Ziel, der sich im Laufe eines jeden Projekts noch ändert. Daher wird diese Fragestellung zu Beginn des Projekts nur soweit beantwortet, wie dies vorab möglich und notwendig ist, um einen Überblick zu erhalten bzw. eine gewünschte Verbindlichkeit bezüglich erforderlicher Ressourcen eingehen zu können (z.B. ein Fixpreis für das Projekt). Egal welches Vertragsmodell zur Anwendung kommt, der Umfang unterliegt einem ständigen Change-Management-Prozess, der im Rahmen von Scrum durch die Wartung des Product Backlogs und dessen Prioritäten abgewickelt wird.
• WIE? Diese Frage versuchen wir so lange wie möglich hinauszuzögern, da sie mit einer Fülle von Details verbunden ist, die schwer zu erheben, dokumentieren und konsistent zu halten sind. Auch werden Fragen zu diesem Bereich von Detailentscheidungen während der Umsetzung beeinflusst, und können nur im Kontext der eigentlichen Entwicklung sinnvoll erhoben werden. Details werden dementsprechend im Rahmen der Sprintplanung jeweils nur für ein Zeitfenster von 1-4 Wochen (Sprint) erhoben, und als informelle Notizen bzw. Akzeptanzkriterien für einzelne User Stories dokumentiert. Weitere Details erhält das Team bei Bedarf (just-in-time) während der Umsetzung.

Praxistauglichkeit
In praktisch jeden unserer Projekte wird von uns eine Festlegung bezüglich Aufwand für einen angenommenen Umfang verlangt. Unsere Analysemethodik ist darauf abgestimmt, vorab gerade genügend Details zu erheben, um diese Festlegung machen zu können. Sie erlaubt aber auch, Änderungen im Projekt schnell zu berücksichtigen, ohne vorab erstellte Arbeitsergebnisse zu verlieren. Agilität in der Analyse bedeutet für uns daher nicht Unvorhersehbarkeit sondern höhere Planungssicherheit für Projekte und die bessere Nutzung vorhandener Ressourcen.