Requirements Engineering (RE) findet in Scrum kontinuierlich statt – wir nennen es nur nicht so

„Wir arbeiten agil und benötigen kein RE mehr“. Diese Aussage hört man immer häufiger in unterschiedlichen Organisationen. Ist die Zeit des Requirements Engineerings (RE) durch die Verbreitung von der agilen Methoden (z.B. durch das Scrum-Framework) damit abgelaufen und werden nicht mehr benötigt?

Agilität macht RE überflüssig?

Der Eindruck könnte auf den ersten Blick entstehen, da Requirements Engineering in der agilen Entwicklung nicht isoliert betrachtet wird, sondern die Aktivitäten des RE elementare Bestandteile der alltäglichen Arbeit eines Product Owners sind – nur würde dies in einem agilen Team selten jemand so explizit benennen.  Deswegen möchte ich in diesem Blogbeitrag die Aufgaben eines Product Owners und des Teams mit den Aufgaben eines Requirements Engineers vergleichen, um aufzuzeigen, dass die RE-Aktivitäten auch in einem Scrum-Team wiederzufinden sind.

Die Aufgaben des Requirements Engineers 

Dazu sollen zunächst die vielfältigen Aufgaben eines Requirements Engineers festgehalten werden.  Am Anfang stehen Ideen zu einem Produkt oder Problemstellungen von Stakeholder, die einer Lösung bedürfen. Dazu sind  Anforderungen zu erheben, die dokumentiert werden müssen. Oder bereits erhobene Anforderungen sind nach einer Analyse in weitere Anforderungen zu verfeinern und zu konkretisieren. Für die Feststellung des Nutzens der Anforderungen sind diese zu analysieren und daraus eine Priorität abzuleiten. Zu den Aufgaben gehört es, Anforderungen zu konsolidieren und die Qualität der Anforderungen durch Kriterien wie Widerspruchsfreiheit, Testbarkeit, Eindeutigkeit, Vollständigkeit und Notwendigkeit usw. sicherzustellen. Zudem sollte ein Requirements Engineer über Modellierungs-Fähigkeiten verfügen  und in der Lage sein, eine Prozess-Analyse durchzuführen.

Zusammenfassend kann man die Aufgabe eines Requirements Engineers auch folgendermaßen ausdrücken: Anforderungen sind in einer angemessenen Detaillierung, zum benötigten Zeitpunkt, für die zu erwartenden Beteiligten verständlich darzustellen.

Diese Aufgabendefinition eines Requirements Engineers wird durch agile Vorgehensweisen (z.B. durch Scrum) besonders geeignet unterstützt.

Was passiert in den Scrum Events?

In manchen Organisationen wird man bei der Vorstellung von Scrum allerdings darauf hingewiesen, dass die Mitarbeiter für die zahlreichen und zusätzlichen Meetings in Scrum keine Zeit hätten. Diese Aussage überrascht, denn die Scrum-Meetings (oder genauer gemäß Scrum-Guide ausgedrückt, handelt es sich um „Events“) sind keine klassischen Meetings, sondern eher Workshops zur Erhebung, Analyse oder Designentscheidung von User Stories. Betrachten wir nun diese Meetings im Hinblick auf das Themengebiet des Requirements Engineerings im Einzelnen.

Im Sprint Planning Meeting Teil 1 werden die geplanten und hoch priorisierten Kundenanforderungen i.d.R. User Stories für den anstehenden Sprint durch den Product Owner vorgestellt und durch Akzeptanzkriterien detailliert und konkretisiert. Es wird dadurch das WAS geklärt und dieses Meeting stellt dadurch eine Anforderungsanalyse dar.

Das Sprint Planning Meeting Teil 2 stellt einen Designworkshop dar, indem das Entwicklungsteam auf der Grundlage der vorgestellten User Stories das Design für das umzusetzende Produktinkrement erstellt. Es wird dadurch über das WIE entschieden und das Design festgelegt. Das Ziel dieses Meetings ist nicht das Herunterbrechen der User Stories in Task, sondern das Design steht im Vordergrund, die Tasks sind ein Mittel zur Umsetzung und dadurch nur ein „Nebenprodukt“.

Das Review Meeting am Ende eines Sprint, stellt neben der Abnahme von umgesetzten User Stories  das Feedback in dem Mittelpunkt, um neue User Stories von anwesenden Kunden, Anwendern und weiteren Stakeholdern zu erheben – Erhebung ist eine klassische Aktivität eines Requirements Engineers – und um das Verständnis des Product Owners für bereits vorhandene User Stories bzw. Epics zu schärfen und zu konkretisieren. Die Konkretisierung bedeutet, dass z.B. weitere Akzeptanzkriterien hinzukommen – dies könnten wir auch als abgeleitete Anforderungen bezeichnen und erkennen eine weitere RE-Aktivität.

Wir finden im Scrum Prozess RE Aktivitäten

In einem Review Meeting mit mehreren anwesenden Stakeholder könnte es durchaus passieren, dass sich die Anwesenden in Ihren Wünschen widersprechen – und schon muss der Product Owner die Wünsche konsolidieren – eine weitere RE-Aktivität.

Im Daily Scrum steht zwar „inspect and adapt“ im Vordergrund, kann aber dazu genutzt werden, um noch nicht getroffene  Implementierungsentscheidungen von User Stories zu treffen und liefert einen aktuellen Überblick über den Umsetzungsgrad der User Stories. Die Auswertung und das Reporting im Hinblick auf den Status von Anforderungen ist ebenfalls in vielen Organisationen eine Aufgabe des Requirements Engineers.

Eine kontinuierliche Aufgabe des Product Owners ist es, sein Product Backlog zu pflegen („Backlog Grooming“). Dies bedeutet:

• Neue User Stories sind z.B. durch das Feedback während des Sprint Review Meetings in Erfahrung zu bringen (Erhebung)
• Neue User Stories zu beschreiben (Dokumentation)
• Die Rangfolge durch neue User Stories im Product Backlog anzupassen  (Priorisierung)
• Epics, die nach Schätzung des Teams nicht sprintfähig sind, zu schneiden  und in mehrere User Stories aufzuteilen (Ableitung / funktionale Dekomposition)
• User Stories mit Akzeptanzkriterien zu detaillieren (Konkretisierung)
• User Stories mit nicht-funktionalen Anforderungen in Verbindung zu setzen (Qualitätsverbesserung)
• Widersprüchliche Erwartungen der Stakeholder aufzulösen und zu kommunizieren (Konsolidierung)
• Die funktionale Unterstützung von Prozessen durch ein Story Mapping mit Aktivitäten und Aufgaben zu analysieren (Prozessanalyse)
• Bei Bedarf zum besseren Verständnis des Entwicklungsteams Abläufe oder Zusammenhänge zu skizzieren (Modellierung)

Die in den Klammern aufgeführten Bezeichnungen sind die Tätigkeiten eines Requirements Engineers.

Um das Backlog Grooming als Gemeinschaftsaufgabe zwischen Product Owner und Team durchzuführen oder weil es für viele Entwickler nicht ausreichend ist, wenn User Stories erstmalig im Sprint Planning Meeting 1 vorgestellt und besprochen werden, haben sich zahlreiche Scrum-Teams dazu entschlossen, das Scrum-Framework um ein weiteres Event zu erweitern und nennen es Story Time, Estimation Meeting, Backlog Refinement oder Grooming Meeting. In diesem Meeting werden zukünftige User Stories durch den Product Owner vorgestellt und Akzeptanzkriterien besprochen, um ein gemeinsamen Verständnis sicherzustellen und gleichzeitig die Schätzung der Story durchzuführen. Dabei werden nur User Stories besprochen, die in den unmittelbar anstehenden 1-2 folgenden Sprints umgesetzt werden sollen oder der Product Owner  eine Einschätzung des Aufwands von seinem Entwicklungsteam für eine User Story oder ein Epic möchte, um eine weitere Entscheidungsgrundlage für die Eingruppierung im Backlog für diese User Story  zu erhalten.

Dieses Vorgehen wird durch den Scrum-Guide von Ken Schwaber und Jeff Sutherland abdeckt und stellt keine Störung des geschützten Raums dar, da in dem offiziellen Scrum-Guide vorgesehen ist, dass sich das Team mit bis zu 10% seiner Zeit mit zukünftigen „Anforderungs-Items“ beschäftigt – wir haben dieser beschriebenen Empfehlung einfach nur einen Namen gegeben, indem wir es z.B. Story Time nennen. Um das Entwicklungsteam frühzeitig einzubinden und die Team-Kompetenzen zu nutzen, führt der PO bei Bedarf eine Story Time durch – dies dient der Anforderungserhebung und Anforderungsanalyse.

Zusammenfassung

RE-Aktivitäten lassen sich im Scrum-Framework an zahlreichen Stellen identifizieren. Die Anwendung findet im Gegensatz zu einem phasen- oder dokumenten-getriebenen Entwicklungsansatz aber kontinuierlich statt, die Kommunikation zwischen Fachseite und Entwicklern muss im Mittelpunkt stehen und die reine Übergabe von Dokumenten ist zu vermeiden und die zu erstellenden Artefakte werden nur so umfassend wie nötig und parallel zur Entwicklung oder unmittelbar vor der Umsetzung erstellt.

Organisationen, die RE als Selbstzweck betreiben und über eine klare Kosten-Nutzen-Abwägung durchführen, sind sowohl in einem klassischen Entwicklungsumfeld sowie einem agilen Umfeld unproduktiv.

 

Wenn Sie an weiteren Informationen zum Thema agiles Requirements Engineering interessiert sind oder Sie sich über die  Zusammenhänge zwischen dem Scrum-Framework und RE informieren möchten, empfehle ich Ihnen, eines unserer beliebten Trainings, wie beispielsweise das zum  Certified Agile Requirements Specialist (CARS), zum Scrum Master,  der Intensivworkshop zur IREB® CPRE-Foundation Level Zertifizierung, CPRE Advanced Level . Es ist bestimmt etwas für Sie dabei.