Agilität bringt Vorteile, davon sind heute viele Unternehmen überzeugt. Prioritäten können in kurzen, regelmässigen Abständen neu gesetzt, Resultate schneller sichtbar gemacht und durch selbstorganisierte Teams das volle Potenzial der Mitarbeiter ausgeschöpft werden – um nur einige Vorteile zu nennen. Laut dem SwissQ Trends & Benchmarks Report 2017 werden in der Schweiz bereits fast 60% der Projekte agil umgesetzt.
Business Analysten, Requirements Engineers und Product Owners werden dabei meistens auf die neuen Vorgehensmodelle wie Scrum oder SAFe vorbereitet. Sie kennen die neuen Rollen und Zeremonien und sind mit den agilen Werten und Prinzipien vertraut. Dem agilen Requirements Engineering – also dem Ermitteln, Dokumentieren, Abstimmen und Managen von Anforderungen im iterativ-inkrementellen Vorgehen – wird indes oft zu wenig Aufmerksamkeit geschenkt.
Dies führt dazu, dass gerade zu Beginn von Vorhaben oft wenig Brauchbares aus den Sprints geliefert wird. Entweder weil Entwickler zu wenige oder falsche Informationen erhalten, oder weil User Stories eingeplant werden, die in ihrer Kombination keinen echten Mehrwert für den im Fokus liegenden Endnutzer liefern. Des weitere kann sich auch die Kommunikation mit Stakeholdern, vor allem mit solchen, die wenig oder keine agile Erfahrung haben, als sehr schwierig gestalten. Dies, weil sie Entscheide über Prioritäten nicht nachvollziehen können und weil sie das Vorgehen im agilen Requirements Engineering bis hin zum Requirements Management und zur Planung der Produktinkremente zu wenig oder gar nicht verstehen.
Um diese Probleme zu lösen, sind folgende fünf Punkte sehr hilfreich:
- Definieren Sie, welche Informationen in den User Stories stehen müssen
Bereits zu Beginn eines neuen Vorhabens sollte vom gesamten Team definiert werden, welche Informationen in einer User Story enthalten sein müssen. Welche Informationen eine User Story beinhalten soll, wird am besten im Sinne einer Checkliste in einer Definition of Ready (DoR) festgehalten. Nur wenn diese Informationen zur gewünschten Produkterweiterung vorhanden sind, ist die User Story „Ready“ für die Umsetzung.
- Arbeiten Sie mit Akzeptanzkriterien
Eine der wichtigsten Informationen in einer User Story sind die Akzeptanzkriterien. Anhand der Akzeptanzkriterien weiss auf der einen Seite der Verfasser eines agilen Artefakts (Epic, Feature oder User Story), was er schlussendlich erhält. Auf der anderen Seite weiss der Entwickler, was er liefern muss, damit die Umsetzung akzeptiert wird. Akzeptanzkriterien sollen einfach, klar und eindeutig formuliert werden und klar messbar sein. Sie bilden gleichzeitig eine gute Basis für das Testing.
- Stellen Sie den richtigen Detaillierungsgrad für Epics, Features und User Storys sicher
Bei agilen Vorhaben wird oft eine High-Level Planung in Form einer Roadmap gemacht, um eine Vorhersehbarkeit über zukünftige Produkterweiterungen zu erlangen. Je nach Organisationaufbau wird auf Portfolio- und/oder Programmebene über neue Produktefeatures in den nächsten Entwicklungszyklen entschieden. In jedem Projekt muss bestimmt werden, welche Artefaktelevel, mit entsprechendem Detaillierungsgrad der Anforderungen, benötigt werden, um an der richtigen Stelle entscheiden und planen zu können.
- Definieren Sie MVPs und machen Sie diese sichtbar
Ein Minimal Viable Product (MVP), übersetzt ein "minimal brauchbares Produkt", ist die erste funktionsfähige Implementierung eines Produktefeatures, mit der man ein schnelles Feedback vom Kunden und vom Markt erhalten kann. Stellen Sie dabei sicher, dass für alle Stakeholder klar ersichtlich ist, welche Anforderungen im Scope des MVPs sind und welche nicht. Anforderungen welche bei der Definition von MVPs nicht berücksichtigt werden, sollten im Backlog erhalten bleiben, um sie allenfalls später berücksichtigen zu können.
- Kommunizieren Sie Ihr Vorgehen an alle Stakeholder
„Das Projekt war zwar erfolgreich, aber für alle Beteiligten sehr intensiv“. Ein Satz, den man oft hört nach Abschluss erfolgreicher agiler Vorhaben. Häufig sind die Vorhaben genau deshalb erfolgreich, weil sie so intensiv sind. Und zwar intensiv im Austausch der Beteiligten, also in der Kommunikation. Gerade neue Stakeholder müssen über die iterativ-inkrementelle Vorgehensweise und deren Vorteile informiert oder gegebenenfalls in die Thematik eingeführt werden. So entsteht ein Verständnis für die häufigen Reviews, Demos und Abstimmungstätigkeiten und oft werden diese neuen Möglichkeiten zur Qualitätsverbesserung dann auch gerne genutzt.
Obwohl die die Disziplin des Requirements Engineerings in den offiziellen Frameworks wie Scrum oder SAFe wenig Erwähnung findet, ist sie nach wie vor von grosser Wichtigkeit. Sind Sie kurz vor dem Start eines neuen Vorhabens oder haben ähnliche Erfahrungen gesammelt? Versuchen Sie, die fünf oben erwähnten Punkte im Auge zu behalten.
Noch Fragen?
Eine gute Übersicht über Agiles Requirements Engineering, zeigt unser agile Requirements Engineering Poster.
Unsere Kurse zum Thema:
IREB CPRE Advanced Level RE@Agile
Blogbeitrag zum Inhalt des RE@Agile Primer
Haben Sie Fragen zum Agile Requirements Engineering, dem Poster oder den Kursen? Zögern Sie nicht und nehmen Sie Kontakt mit uns auf. Wir helfen Ihnen sehr gerne weiter!