Agile Business Analyse: Verstehe, was machbar ist

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. 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).
5. In diesem Blog-Artikel: Verstehe, was machbar ist (und unterstütze dadurch die Entwickler in ihrer Umsetzung der Anforderungen).
6. Fördere Zusammenarbeit und kontinuierliche Verbesserung; mit den Techniken Collaborative Games und Retrospektive.
7. Vermeide Verschwendung (und erkenne diese rechtzeitig).

Fünftes der sieben Prinzipien: Verstehe, was machbar ist

Wenn ein agiles Team plant, ist es wichtig pragmatisch vorzugehen und darauf zu achten, was machbar ist. Wenn die zu erledigenden Arbeiten abgeschätzt werden, muss das Team einen Ausgleich finden zwischen den eigenen Kapazitäten und den gestellten Anforderungen. Agile Teams überprüfen fortlaufend ihre zeitlichen Kapazitäten, vergangene und aktuelle Schätzungen sowie eventuelle Abweichungen, um die Schätzungen fortlaufend anzupassen. Das hilft dem Team zu entscheiden, was geliefert werden kann, und es kann bessere Schätzungen abgeben.
Dabei können folgende Techniken zum Einsatz kommen: Schätzung, Planungsworkshop.

Schätzung

Schätzung wird als Technik bereits im BABOK aufgeführt. Der Basisansatz der Schätzungen beruht auf Wissen aus vergangenen Projekten.

Die agile Extension zum BABOK fasst die wesentlichen Schätzungstechniken zusammen, die in agiler Umgebung angewendet werden. Agile Schätzer wenden häufig relative Schätzungen an, bei der das Team Beschreibungen entwickelt (z.B. User Stories), die die Bedürfnisse der Kunden/Nutzer und deren Nutzen enthalten. Das Team analysiert die User Stories und vergibt Werte für jede Story. Diese Story Points sind eine Zahl, die den geschätzten Aufwand für die Story angibt. Bei der Schätzung berücksichtigt das Team vier Schlüsselgebiete:

• Wissen: Wie viele Informationen haben wir?
• Komplexität: Wie schwierig wird die Umsetzung voraussichtlich sein?
• Volumen: Wie groß ist die Story? Wie lange wird es dauern?
• Unsicherheit: Welche Variablen und Unsicherheitsfaktoren bringt die Story mit sich?

Die Summe der Story Points, die ein Team in einer Iteration bewältigen kann, gilt als Geschwindigkeit (Velocity) des Teams. Nach einigen Iterationen wird das Team besser wissen, wie seine aktuelle Velocity aussieht. Dadurch werden bessere Schätzungen und Absprachen in kommenden Iterationen möglich sein.

Es gibt verschiedene Ansatzpunkte für Schätzungen mit Story Points. Der agile Schätzer kann starten mit

• WAG (wide angle guess), eine grobe Rahmenschätzung,
• einem vorgegebenen Set an Ressourcen und einer festen Iteration, oder
• einer Schätzung, wie viel Zeit für einen Story Point benötigt wird, um daraus zu extrapolieren, wie viel Arbeit schätzungsweise in einer Iteration erledigt werden kann.

Eine genaue Schätzung ist wichtig für die Produktivität eines agilen Teams, aber auch für die Zuverlässigkeit und die Reputation. Wenn Kosten, Zeit und der Arbeitsaufwand gut abgeschätzt werden, kann das Team glaubwürdige Aussagen zum Projekt- oder Arbeitsverlauf treffen.

Auch wenn Schätzungen im fertigen Produkt nicht zu erkennen sind, liefern sie einen erheblichen Wert für ein agiles Projekt. Wenn glaubwürdige Schätzungen abgegeben werden, ermöglichen sie dem Team

• Kosten und Aufwand zu bestimmen,
• die Prioritäten des Projekts festzulegen,
• sich auf einen Plan festzulegen.

Bei allen agilen Vorgehen werden die Schätzungen fortlaufend und in Verbindung mit den Iterationen eingesetzt. Dabei werden spätere Schätzungen normalerweise exakter sein als frühe Schätzungen. Verbesserungen ergeben sich im Laufe der Zeit, wenn das Team Vertrauen in seine Kapazitäten und Fähigkeiten fasst.

Schätzung ist eine Teamaufgabe. Business Analysten helfen dem Team, die Bestandteile, Charakteristika und Komplexität der Anforderungen und der daraus resultierenden Arbeit zu verstehen.

Vorteile: Relative Schätzung ist eine einfache, zuverlässige Technik, die gut zu agilen Vorgehen passt. Sie kann leicht angepasst werden und wird mit späteren Iterationen zunehmend genauer.

Nachteile: Relative Schätzung basieren auf historischen Daten. Damit hängt die Genauigkeit von der Vergleichbarkeit der aktuellen Stories mit vergangenen Stories ab. Wenn die neuen Stories erheblich abweichen, kann die Genauigkeit der Schätzung entsprechend fehlen.
Die Genauigkeit der Velocity hängt vom Wissen und der Erfahrung des Entwicklungsteams ab. Alle Änderungen der Teamzusammensetzung werden die Velocity und damit auch die Schätzungen beeinflussen.

Planungsworkshop

Zweck des Planungsworkshops ist es, dass das Team bestimmt, welche Arbeiten während der Iteration zu erledigen sind bzw. welches Set an Funktionalität fertig zu stellen ist.
In den meisten agilen Vorgehen wird der Planungsworkshop am Anfang jeder Iteration durchgeführt. Er kann aber auch durchgeführt werden, wenn das Team das Backlog fast abgearbeitet hat oder das Backlog neu sortiert werden soll.
Vor dem Workshop gibt es normalerweise eine Vorplanungsphase, die eine Schätzung der Größe, des Umfangs (Scopes) und der Komplexität jedes Backlogitems erbringt, das im Planungsworkshop behandelt wird.

Im Planungsworkshop werden regelmäßig folgende Elemente behandelt:

• Geschätzter und sortierter Product Backlog: typischerweise in Form von User Stories.
• Team Velocity: siehe oben.
• Ziel der Iteration: Welche Ziele des Releases sollen in dieser Iteration erreicht werden?
• Auswahl der Anforderungen/Features: Welche Anforderungen/Features haben die höchste Priorität unter Berücksichtigung des Wertes/Nutzens, des Ziels der Iteration und der Team Velocity?
• Auswahl der Non-Features: Welche Non-Features, die auch Wert/Nutzen erzeugen, sollen bearbeitet werden (z.B. Fehlerbeseitigung, Systemumgebung, Recherchen)?
• Planung der Aufgaben: Die Anforderungen/Features und Non-Features werden in Aufgaben umgesetzt. Dabei beträgt das typischerweise Zeitfenster pro Aufgabe vier Stunden bis zwei Tage. Diese Schätzung sollte zur späteren Überprüfung festgehalten werden.

Die regelmäßige Durchführung der Planungsworkshops erlaubt dem Team und den Kunden die Prioritäten der ausstehenden Aufgaben zu ändern, um damit Feedback oder geänderte Anforderungen zu berücksichtigen.

Business Analysten können wertvoll zum Teamergebnis beitragen, indem sie

• die Anforderungen dem Team verdeutlichen,
• den Fokus auf die Ziele setzen,
• den Wert, der mit bestimmten Anforderungen verbunden ist, darlegen,
• Story Decomposition betreiben.

Vorteile sind die regelmäßige Kommunikation und Zusammenarbeit und die fortwährende Steuerung. Es ist einfacher, den Umfang kleiner Iterationen zu verstehen, zu schätzen und zu planen; im Vergleich zu großen Releases. Agile Pläne können verändert werden.

Herausfordernd kann es sein, alle Beteiligten zur Planung zusammenzubringen (insbesondere bei mehreren Teams, die nicht am selben Standort sind). Wenn der Blick für das Gesamtprojekt fehlt, geht die Planung möglicherweise in eine falsche Richtung (dies gilt aber natürlich auch für nicht-agile Ansätze).

Weitere Informationen zum Thema Business-Analyse haben wir auf unserer Homepage für Sie zusammengefasst.