Wir organisieren Vorsprung.
Bereit für die Arbeitswelt von morgen.
Agile Business Analyse
Umgang mit Requirements im agilen Umfeld
Agiles Arbeiten verändert die Arbeitsweise zwischen Fachbereich und IT. Doch wann ist agile Business Analyse sinnvoll?
Wo und wie kommen Business Analysten in agilen Vorgehensmodellen (z.B. Scrum) zum Einsatz? Welche Aufgaben und Aktivitäten üben sie aus? Was sind agile Prinzipien? Eine Orientierung.
Wann ist agiles Arbeiten mit Anforderungen sinnvoll?
Agile Business Analyse und agiles Arbeiten mit Requirements sind umso sinnvoller, desto unklarer die Ziele und Ergebnisse sind. Je unbekannter die (IT-)Lösung und die Anforderungen sind, desto besser ist es, Schritt für Schritt voranzugehen, also iterativ zu arbeiten. Die Technologie bzw. die Art der Umsetzung spielt ebenfalls eine Rolle: wird zum Beispiel am bekannten Kernsystem gearbeitet, kann auch klassische Business Analyse genutzt werden. Handelt es sich hingegen um eine neue Technologie oder neue Systeme, ist ein agiles Business Analyse Vorgehen häufig besser. Hinzu kommt, dass agile Vorgehensmodelle wie Scrum in Unternehmen etabliert sind.
Prinzipien agiler Business Analyse
Agiles Arbeiten bedeutet Flexibilität in der Zusammenarbeit und häufig auch Flexibilität beim Ergebnis. Business Analyse ist zuständig für die Ermittlung, Analyse und Dokumentation von Anforderungen. Ob die beteiligten Rollen „Business-Analyst“, „Requirements Engineer“ oder anders benannt werden, ist dabei eigentlich zweitrangig. Entscheidend ist, dass agile Business Analyse den agilen Grundprinzipien folgt:
7 Prinzipien agilen Arbeitens
- Vorgehen in Schleifen: iteratives Arbeiten, immer wieder überprüfen, ob man auf dem Weg zum Endergebnis ist.
- Feste und kurze Zeitfenster: sogenannte Sprints, in denen Anforderungen bearbeitet und umgesetzt werden. Kurze Zeitfenster sind leichter zu planen.
- Ergebnisorientiert arbeiten: auf konkrete und eher kleine Zwischenergebnisse (sogenannte Inkremente) hinarbeiten, die man ausprobieren kann, z. B. eine konkrete Funktionalität als Zwischenergebnis.
- Co-Kreation: mit anderen Teammitglieder zusammenarbeiten, direkt kommunizieren und verschiedene Perspektiven einbringen.
- Selbstorganisiert: das Team entscheidet, wer welche Aufgaben bearbeitet, wer seine Kapazität einbringt und Aufgaben eigenverantwortlich übernimmt
- Überprüfen und Anpassen: sowohl die Zusammenarbeit im Team reflektieren als auch Zwischenergebnisse überprüfen und dabei insbesondere die Kundensicht einnehmen
- Transparenz: über absolvierte Aufgaben und Ergebnisse, über offene oder nicht erledigte Aufgaben, über Fortschritt und Hindernisse
Erfolgsfaktoren und Herausforderungen für Arbeit als agile Business Analyst
Erfolgsfaktoren
- Stetige Zusammenarbeit mit den (internen und externen) Kunden
- Denken wie ein Kunde – die Wünsche und Erwartungen des Kunden kennen und verfolgen
- Den Blick auf das Ganze behalten, das “Big Picture” verstehen – welche Probleme soll die Lösung beseitigen?
- Das Wertvolle bestimmen – eine Lösung entwickeln, die für den Kunden wertvoll ist und von ihm positiv bewertet wird
Herausforderungen
- „Schlanke“ Anforderungen z. B. in Form von User Storys, die in jedem Sprint erarbeitet werden (statt vollständig zu Beginn des Projekts)
- Kommunikation, Verhandlung und Moderation - auch im agilen Umfeld dafür sorgen, dass die beteiligten Personen eine Sprache sprechen
- Leichtgewichtige Dokumentation - es gilt alle Verschwendungen zu vermeiden, die nicht unmittelbar in das Endergebnis einfließen
- Pragmatisches Vorgehen - einen Ausgleich finden zwischen den eigenen Kapazitäten und den gestellten Anforderungen
Klassisches und agiles Vorgehen in der Business Analyse im Vergleich
Im Vergleich zur klassischen Vorgehensweise, bei der alle Anforderungen vorab definiert werden, betont agiles Requirements Engineering Flexibilität und iterative Entwicklung. Während traditionelle Methoden oft an starren Zeitplänen scheitern, ermöglicht agile Business Analyse schnelle Anpassungen und kontinuierliche Verbesserungen durch enge Zusammenarbeit aller Beteiligten. Agile Modelle reagieren somit effektiv auf Veränderungen und Herausforderungen, im Gegensatz zu den sequenziellen, oft weniger anpassungsfähigen klassischen Ansätzen.
Klassisch sequentiell | Agil, iterativ | |||
---|---|---|---|---|
Ergebnistyp | (Vollständiges) Anforderungsdokument | Grobe Anforderung insgesamt, feine Anforderung für nächste Iteration | ||
Anforderungsermittlung | (Möglichst) alle Anforderungen vorab | Kontinuierlich in richtiger Menge der Iteration | ||
Anforderungsdokumentation | Erstellt durch Business-Analysten und ggf. Anforderungsersteller | Erstellt durch agile Business Analysten und ggf. Product Owner und Lösungsteam | ||
Anforderungsformat | Ganze Sätze, Stichworte, Modelle | Häufig User-Stories, Modelle | ||
Genehmigung | Formal und verpflichtend, für gesamtes Anforderungsdokument | Anforderungen für jeweilige Iteration verpflichtend | ||
Anforderungsänderung | (Streng) kontrolliert nach Genehmigung | Antizipierte Veränderungen für kommende Iterationen möglich | ||
Anforderungsdokumentation | Erstellt durch Business-Analysten und ggf. Anforderungsersteller | Erstellt durch agile Business Analysten und ggf. Product Owner und Lösungsteam | ||
Organisatorische Einbettung | Business-Analysten häufig separat vom Entwicklungsteam | Oft nah beim Lösungsteam |
Podcasts rund um agile Business Analyse
Agile Business Analyse mit Scrum & Co. verbinden
Bei agilen Vorgehensmodellen steht die stetige Zusammenarbeit mit den (internen und externen) Kunden im Vordergrund. Business Analysten stellen dabei den Entwicklern die richtigen Anforderungen mit der richtigen Detaillierung zur richtigen Zeit zur Verfügung, damit diese das richtige Produkt entwickeln. Wir beleuchten wo und wie Business Analyse in agilen Vorgehensmodellen zum Einsatz kommt.
Agile Business Analyse und Scrum
Scrum ist als agile Arbeitsweise weit verbreitet. Alle Anforderungen werden im Product Backlog gesammelt, aus dem für jeden Sprint Anforderungen priorisiert und in das Sprint Backlog überführt werden. Scrum kennt dabei 3 Rollen: den Product Owner, das Entwicklungs- bzw. Lösungsteam und den Scrum Master. Welche der drei Rollen kann ein Business Analyst einnehmen? Wir beleuchten die Möglichkeiten und zeigen, welche Abweichungen sich zur klassischen Rollenbeschreibung ergeben.
Product Owner
Beim Product Owner gibt es Überschneidungen zur Business Analyse: die Zusammenarbeit mit allen Stakeholdern und das Verständnis ihrer Anforderungen. Allerdings hat ein Product Owner mehr Verantwortung und Befugnisse als ein Business Analyst, z. B. Anforderungen zu priorisieren. Product Owner haben dadurch auch ein anderes Standing.
Scrum Master
Die Rolle Scrum Master hat wenig Schnittmengen zur Business Analyse. Scrum Master arbeiten nicht inhaltlich im Projekt, sondern sind zuständig für die Einhaltung der Scrum-Regeln und die gute Zusammenarbeit des Teams. Als Scrum Master zu arbeiten ist daher selten eine gute Wahl für Business Analysten.
Lösungsteam
Als Teil des agilen Lösungs- bzw. Entwicklungsteams kann ein Business Analyst die rechte Hand des Product Owners sein und sich voll den Anforderungen widmen. Eine klare Absprache mit dem PO ist essenziell, um gut abgestimmt zusammen zu arbeiten. Manchmal sind neben Business-Analyse-Tätigkeiten auch andere Teamaufgaben zu übernehmen.
Ansätze für agile Business Analyse im Kanban
Kanban fördert Flexibilität und Effizienz durch vier Prinzipien: die Visualisierung der Arbeit, die Begrenzung der Arbeitsmenge, der Fokus auf den Arbeitsfluss und das Streben nach ständiger Verbesserung. Agile Business Analyse sorgt dafür, dass erste Anforderungen für die Queue ermittelt und dokumentiert werden. Wenn die Entwickler diese Anforderungen umsetzen, ermittelt der Business Analyst weitere Requirements für die nächste Funktionalität.
Einsatzgebiete
- Queues (Arbeitsstapel): Ähnlich wie Backlogs in Scrum werden in Queues alle Aufgaben zum Produkt oder zu den Funktionen hinterlegt.
- Priorisierung und Dringlichkeit: Neue Anforderungen werden systematisch nach ihrer Wichtigkeit in die Queue eingeordnet.
Grooming the Queue: Sind Funktionalitäten zu umfangreiche (z. B. für ein Release), werden diese zerlegt; irrelevante Anforderungen werden herausgefiltert.
Agile Business Analyse und Extreme Programming (XP)
Extreme Programming (XP) setzt auf User Stories zur Definition von Requirements. Diese sind kurze, prägnante Sätze, die folgendermaßen formuliert werden: „Als [Akteur/Rolle/Kunde] möchte ich [Funktionalität/Eigenschaft], um [Nutzen/Ziel] zu erreichen.“
Im Rahmen des Release Plannings werden diese Funktionalitäten ähnlich wie beim Sprint Backlog in Scrum für das anstehende Release zusammengestellt. Während des Iteration Plannings erfolgt dann die Priorisierung der User Stories.
Business Analysten können eine entscheidende Rolle in XP spielen. Sie sorgen für ein einheitliches Verständnis der zu entwickelnden Funktionalitäten. Sie verhandeln bei Meinungsverschiedenheiten, moderieren, entwickeln Akzeptanzkriterien für die User-Storys und stellen so sicher, dass die Anforderungen den Kundenwünschen entsprechen.
Agile Business Analyse - Methoden und Techniken, die zum Erfolg führen
Übersicht agiler Anforderungs-Techniken zum Download
In unserem PDF erhalten Sie eine umfangreiche Übersicht zu Techniken für agile Business Analyse, die Sie unabhängig vom agilen Vorgehensmodell einsetzen können.
Weiterbilden für erfolgreiches agiles Arbeiten
Seminar Agile Business Analyse
Tools und Methoden für die Praxis im agilen Requirements Engineering. Beste Vorbereitung für die internationalen Zertifikate RE@Agile Primer und zum Advanced-Level RE@Agile (Practitioner und Specialist).
Senior Business Analyst mit ibo-Zertifikat
Agile Business Analyse, Prozesse digitalisieren und Data Analytics. Zertifiziertes Spezialwissen über Anforderungen hinaus.
Expert:in für agile Organisation
Agile Strukturen und Praktiken kennenlernen, für das eigene Unternehmen prüfen und Transformation begleiten.
SAFe Zertifizierungen
Agiles Arbeiten im Unternehmen skalieren mit dem Scaled Agile Framework (SAFe®).
✉ ibo Newsletter
Wir informieren über aktuelle Themen, praxisnahes Know-how, Webinare und Veranstaltungen.