Mit agiler Business Analyse Werte schaffen

In mehreren Blog-Artikeln betrachten wir, wo und wie Business Analysten in agilen Vorgehensmodellen (z.B. Scrum) zum Einsatz kommen, welche Aufgaben und Aktivitäten sie dabei ausüben. Den Auftakt machte eine Übersicht zum Thema. Nach und nach erläutern wir die 7 Prinzipien für erfolgreiche „agile“ Business Analyse:

Drei Prinzipien beschreiben das Was? und Warum?

1. Sieh auf das Ganze (auf Personen, Prozessen und Technologie); mit den Techniken Personas und Value Stream Mapping (Wertstromanalyse).
2. Denke wie ein Kunde (und höre auf die Stimme des Kunden mit seinen Werten und Erwartungen); mit den Techniken User Story, Story Decomposition, Story Elaboration, Story Mapping.
3. In diesem Blog-Artikel: Bestimme das Wertvolle (entwickle dadurch eine Lösung, die wertvoll und positiv bewertet ist).

Vier Prinzipien für das Wie? und Wann?

4. Nutze reale Beispiele (um echte Kundenbedürfnisse zu ermitteln und zu validieren); mit der Technik Behaviour Driven Development.
5. Verstehe, was machbar ist (und unterstütze dadurch die Entwickler in ihrer Umsetzung der Anforderungen); mit den Techniken Schätzung und Planungsworkshop.
6. Fördere Zusammenarbeit und kontinuierliche Verbesserung; mit den Techniken Collaborative Games und Retrospektive.
7. Vermeide Verschwendung (und erkenne diese rechtzeitig).

Drittes der sieben Prinzipien: Bestimme das Wertvolle

Agile Vorgehen legen Wert darauf, dass jederzeit Wertvolles für den Endkunden erarbeitet wird. Dazu wird kontinuierlich geprüft und priorisiert, damit die richtigen Anforderungen analysiert werden. Anforderungen ohne Wert sind auszusortieren.

Folgende Techniken unterstützen dabei:

• Management des Backlogs
• Kano-Analyse
• Priorisierung mit MoSCoW

Management des Backlogs

Das Backlog ist ein „lebendes“ Dokument mit Anforderungen bzw. gewünschten Funktionalitäten. Diese werden insbesondere nach Wert oder Wichtigkeit für den Kunden sortiert und priorisiert. Die Anforderungen können z.B. in Form von User Stories (insbesondere bei XP), Use Cases, Features oder funktionalen Anforderungen hinterlegt werden.

Am Anfang eines Releases/Iteration werden die Bestandteile des Backlogs entnommen, die umgesetzt werden sollen. Diese sollten in einem angemessenen Detaillierungsgrad zur Verfügung stehen; z.B. werden Epics in User Stories zerlegt (vgl. Story Decomposition). Dadurch können die Entwickler präzise Aufwandsschätzungen abgeben und ihre konkreten Aufgaben der Umsetzung planen. Anforderungen, die erst später umgesetzt werden sollen, benötigen diese Detaillierung (noch) nicht.

Weil sich Anforderungen über den (Projekt-) Verlauf durchaus ändern können, kommen am Ende eines Releases/Iteration möglicherweise neue Anforderungen hinzu, ändert sich die Reihenfolge/Priorisierung oder Bestandteile des Backlogs werden entfernt (entweder weil sie fertig umgesetzt wurden oder weil sie künftig nicht umgesetzt werden sollen). Diese Aktualisierung des Backlogs wird auch als pruning oder grooming des Backlogs bezeichnet.

Im Scrum trägt der Product Owner die Verantwortung für das Backlog. Ein Business Analyst kann dabei die Rolle des Product Owners einnehmen oder diesen bei seinen Aufgaben unterstützen.

Vorteile des Managements des Backlogs sind: das Team weiß, dass es an Aufgaben arbeitet, die Wert schaffen. Denn die Anforderungen des Backlogs sind entsprechend priorisiert. Weil in jedem Release normalerweise eine überschaubare Anzahl von Anforderungen implementiert wird, werden diese just-in-time analysiert. Gewonnene Erkenntnisse (Lessones learned) fließen in kommende Iterationen ein.

Nachteile des Backlogs: Große Backlogs sind möglicherweise unübersichtlich und schwierig zu managen. Dies lässt sich durch Release-Backlogs umgehen, die nur die Anforderungen der jeweiligen Releases enthalten.

Kano-Analyse

Hier greift der Draft der Agile Extension eine meiner Lieblingstechniken auf 😉

Mit der Kano-Analyse werden die Anforderungen identifiziert, die zur Kundenzufriedenheit beitragen. Dass dabei konsequent die Kundensicht eingenommen wird, gefällt mir besonders.

Dabei werden drei Kategorien von Anforderungen gebildet: Basisanforderungen, Leistungsanforderungen und Begeisterungsanforderungen. Jeweils ist zu prüfen, ob das Fehlen oder Vorhandensein der Anforderungen im zu erstellenden Produkt zu Kundenzufriedenheit oder –verärgerung führen.

• Basisanforderungen (Elementare Anforderungen): Sind sie in der zu erstellenden Lösung nicht umgesetzt, sind die Kunden unzufrieden; sind Basisanforderungen in der Lösung vorhanden, erzeugen sie aber beim Kunden keine Zufriedenheit (Die allermeisten Kunden gehen wohl davon aus, dass ein aktuelles Handy Vibrationsalarm bietet; fehlt dieser, führt dies wahrscheinlich zu Unzufriedenheit; ist ein Vibrationsalarm vorhanden, wird das noch kein ausschlaggebendes Kaufargument sein).
• Leistungsanforderungen (Performance-Anforderungen): Entsprechen diese nicht den Kundenerwartungen, führen sie zu Unzufriedenheit; übertreffen die Leistungsanforderungen die Erwartungen, führen sie zu mehr Kundenzufriedenheit (Je kürzer die Akkulaufzeit meines Handys, desto unzufriedener bin ich; je länger die Akkulaufzeit, desto zufriedener).
• Begeisterungsanforderungen (Überzeugende Anforderungen): Fehlen diese, führt das zu keiner Unzufriedenheit; sind allerdings Begeisterungsanforderungen vorhanden, so stellt sich beim Kunden ein „Wow-Effekt“ ein (eine funktionierende Sprachsteuerung meines Handys würde mich begeistern; obwohl die Sprachsteuerung nicht so recht klappt, bin ich allerdings nicht unzufrieden).

Anders als der Draft zur Agile Extension bin ich allerdings der Meinung, dass sich die Kano-Analyse nicht nur für externe Kunden eignet. Auch interne Kunden verdienen es m.E., dass Business Analysten prüfen, welche ihrer Anforderungen als Basis- und Leistungsanforderungen einzustufen sind. Und auch interne Kunden verdienen es, dass die ein oder andere Begeisterungsanforderung in der Lösung umgesetzt wird.

Im Seminar Requirements Engineering ergänzen wir das Kano-Modell gerne noch um die Kano-Analyse. Dazu vielleicht in einem späteren Blog-Artikel mehr. (Das ibo Trendforum im November 2012 beschäftigt sich übrigens auch mit Requirements Engineering.)

MoSCoW-Priorisierung

MoSCoW wird als Priorisierungstechnik bereits im BABOK beschrieben (daher gehen wir auch im Seminar darauf ein). MoSCoW kann auch genutzt werden, um z.B. User Stories eines Backlogs zu priorisieren.
Das Akronym setzt sich aus folgenden Bestandteilen zusammen.

• Mo: Must Have. Diese Anforderungen müssen umgesetzt werden, um die aktuelle Lösung erfolgreich zu gestalten.
• S: Should Have. Diese Anforderungen sind ähnlich wichtig, wie die Must have; allerdings nicht so zeitkritisch oder sie können eventuell durch andere Anforderungen kompensiert werden.
• Co: Could Have. Diese Anforderungen sind weniger kritisch.
• W: Would Like. Diese Anforderungen werden voraussichtlich nicht umgesetzt (oder eventuell zu einem späteren Zeitpunkt).

Vorteile der MoSCoW-Priorisierung sind ihre einfache Handhabung und dennoch wirkungsvoller Einsatz. Nachteilig sind die mögliche Subjektivität in der Einteilung und dass Stakeholder dazu neigen, ihre eigenen Anforderungen auf Must Have zu setzen (dies gilt allerdings für die meisten Priorisierungstechniken).

Im nächsten Blog-Artikel dieser Reihe geht es dann um das vierte Prinzip: „Nutze reale Beispiele (um echte Kundenbedürfnisse zu ermitteln und zu validieren).“

Sie interessieren sich für weitere Themen rund um Business-Analyse? Abonnieren Sie den ibo-Newsletter, um immer up to date zu sein!