Wer ist zuständig für das Requirements Engineering im agilen Umfeld? Dieser Blogpost geht der Frage nach, die im Blogpost von Tamer Kuyucu „Wo um Scrums Willen ist der Requirements Engineer?“ zur Diskussion gestellt wurde: Ist Requirements Engineering in Scrum eine Rolle oder eine Fähigkeit einer oder mehrerer Personen?
Im Scrum Guide ist die Rolle des Requirements Engineer nicht definiert. Die Auswertung einer nicht repräsentativen Umfrage auf Linkedin zeigt, dass die Hälfte der Teilnehmenden den Product Owner in der Verantwortung sehen. Für ein Viertel der Befragten sind alle Mitglieder des Scrum Teams für das Requirements Engineering zuständig und die restlichen 25 Prozent plädieren für einen Requirements Engineer als Mitglied des Scrum Teams. Das Ergebnis widerspiegelt die vielen unterschiedlichen Meinungen der Experten zu diesem Thema. In der Folge gehe ich auf die verschiedenen Möglichkeiten kurz ein.
Product Owner
Ein Product Owner stellt gemäss Scrum Guide sicher, dass das Team kontinuierlich Business-Value liefert und priorisiert und verfeinert das Product Backlog. Ausserdem managt der Product Owner die Stakeholder und liefert ausreichend detaillierte Anforderungen in Form von User Stories an das Entwicklungsteam. Oftmals haben Product Owner aber nebenbei ein Tagesgeschäft zu bewältigen und nicht die dafür benötigten Ressourcen oder Skills, um Anforderungen auf dem Level zu definieren, wie sie für die Entwicklung notwendig sind.
Der Product Owner ist zwar gemäss Scrum Guide verantwortlich für die Anforderungen an das System. In der Praxis aber oft mit dieser Verantwortung überfordert. Bevor ein Projekt wegen schlechtem Anforderungsmanagement scheitert, sollten andere Varianten geprüft werden.
Requirements Engineer als Rolle
Wird das Entwicklungsteam um einen Requirements Engineer ergänzt, so stärkt es den Fokus auf die Anforderungen. Der Product Owner wird entlastet und die Entwicklerinnen und Entwickler profitieren von qualitativ hochwertigen User Stories und aktivem Change Management. Die Variante wird vielfach aus Kostengründen nicht verfolgt, weil aus Sicht der Projektsponsoren der Product Owner verantwortlich ist. Gerade in grösseren, komplexen Projekten kann sich eine Investition in diese separate Rolle im Scrum Team aber lohnen.
Requirements Engineering als Fähigkeit
In der dritten Variante wird das Requirements Engineering auf alle Mitglieder des Scrum Teams aufgeteilt. Somit sind Entwickler/innen, Architekt/innen, Tester/innen und der Product Owner gleichermassen für das Anforderungsmanagement verantwortlich. Es empfiehlt sich, zu Beginn des Projekts die Aufgaben zu klären und ein gemeinsames Verständnis zu schaffen. Zum Beispiel kann ein Backlog Refinement Meeting dazu genutzt werden, um die User Stories zu detaillieren, damit sie von den Entwicklerinnen und Entwickler verstanden werden. Die Entwicklerinnen und Entwickler können dann mit den Akzeptanzkriterien die Test Cases umsetzten. Wichtig ist, dass allen Teammitgliedern auch entsprechende Rollenprozente für die Requirements Engineering Arbeiten zugesprochen werden.
Meine Erfahrung in vielen unterschiedlichen Projekten zeigt, dass die Kunden beim Requirements Engineering im agilen Kontext oft die Kosten des Requirements Engineering sparen wollen, weil man ja «agil unterwegs ist». Es ist egal, ob das Requirements Engineering beim Product Owner, als separate Rolle oder als Fähigkeit aller Mitglieder des Scrum Teams angesehen wird. Es ist entscheidend, dass die Verantwortlichkeiten explizit gemacht werden und den Rollen genügend Zeit für das Anforderungs-management zur Verfügung gestellt wird. Ansonsten ist im Projekt am falschen Ort gespart, da der Schaden von mangelhaftem Requirements Engineering für den Betrieb einer Software sehr hoch ist.
Weiterführende Links
Blogpost „Braucht ein agiles Projekt einen Requirements Engineer?“: https://www.valion.ch/2018/10/26/requirements-engineer/
Blogpost „Ein klaffendes Loch im agilen Requirements Engineering“: https://www.zuehlke.com/de/insights/ein-klaffendes-loch-im-agilen-requirements-engineering
