Und plötzlich ist er da, der Moment, indem dein Dozent in die Kamera lächelt und sagt:” Zu einem Scrum Team nach Scrum gehören:…..” Und du wartest und wartest, aber deine Rolle kommt einfach nicht. Und jetzt?
Nun ja, da gibt es jetzt natürlich einige Möglichkeiten: Sich unendlich verloren und nicht dazugehörig, sogar überflüssig fühlen, vielleicht sogar schon den Sinn und Unsinn dieses agilen Konstruktes anzweifeln oder einfach arbeiten und schauen, wie das mit Scrum und unserem Team so funktioniert.
Der Scrum Guide kennt drei Rollen:
- Product Owner:in
- Scrum Master:in
- Developer:innen
Diese drei Rollen sind allen, die mit Scrum arbeiten, bestens bekannt. In der heutigen Zeit sind die Developer:innen aber nicht mehr nur Softwareentwickler:innen, die Teams bestehen immer mehr aus Spezialisten. Der offizielle ScrumGuide nach Ken Schwaber & Jeff Sutherland beschreibt die Developer:innen folgendermassen:
Zu den Developer:innen gehören, je nach Produkt, UX Designer, UX Researcher, ausgebildete Tester, Accessibility Verantwortliche und natürlich auch der Requirements Engineer. Natürlich haben wir in dieser Rolle auch nach wie vor die Softwareentwickler:innen.
Die Rolle des Requirements Engineer lässt sich meiner Meinung nach vor allem in den Punkten 1 und 3 des Scrum Guide-Auszuges abbilden. Meist erstellt ein Requirements Engineer nicht einen Plan für den Sprint, aber die Rolle ist verantwortlich, dass das Backlog mit Anforderungen gefüllt ist, die für den nächsten Sprint geplant werden können. Zudem kann der Zustand der Story, wenn sie in den Sprint gelangt, massgeblich dazu beitragen, ob das Sprint Ziel erreicht werden kann.
Wieso ein Requirements Engineer in einem Scrum Team?
Die Antworten auf diese Frage können sehr unterschiedlich sein, hier die wohl wichtigsten:
- Ein Product Owner kann zu stark eingebunden sein mit Meetings, weil so viele verschiedene Stakeholder vorhanden sind und er so das Tagesgeschäft nicht mehr alleine stemmen kann.
- Die Umgebung ist komplex, das Produkt besteht aus mehreren Applikationen.
- Durch die komplexen Grundanforderungen des Produktes sind sehr viele Personen/Teams involviert (z.B. spezielle Anforderungen an Sicherheit oder Regulatorien wie beim e-Banking oder Versicherungen).
Du Epic – Ich Story
Der Product Owner ist Epic Owner und ich Story Owner. So haben wir uns entschieden, mein Product Owner und ich, mal vorerst. Wir sind genau in dieser Lage, dass wir ein sehr komplexes Umfeld und auch viele Anforderungen an unser Produkt haben, das in allen 4 Sprachregionen angeboten wird. Die Linien sind für uns ganz klar getrennt und doch super offen und flexibel. Wir haben versucht, die Hauptmerkmale der Verantwortung des Product Owners nach Scrum auch beim Product Owner zu belassen.
Der Product Owner ist Ansprechpartner für alle Stakeholder, erstellt die Roadmap, ist verantwortlich für das erstellen und priorisieren von Epics und den daraus resultierenden Storys, die von mir als Requirements Engineer erarbeitet werden.
Als Requirements Engineer trage ich also die Verantwortung über die Storys. Das bedeutet grob, ich übernehme einen grossen Teil der Analyse, Dokumentation, Abstimmung und Verwaltung der Anforderungen. All diese Arbeiten geschehen innerhalb unseres crossfunktionalen Scrum Teams, das neben Front- und Backend Entwickler:innen, Tester:in auch die Rolle des UX Designs beinhaltet.
Ein wichtiger Teil dieser Zusammenarbeit ist die Kommunikation in Sprache und Schrift. Als Requirements Engineer mit dieser Aufgabenverteilung muss sichergestellt werden, dass der Product Owner alle relevanten Informationen und Erkenntnisse der Storys hat, um jederzeit kompetent Auskunft geben zu können. Der Product Owner seinerseits muss sicherstellen, dass ich über alle Epics im Bild bin, um Abhängigkeiten zu erkennen und im Notfall Alarm zu schlagen.
Nun bin ich doch froh, dass ich mich in diesen Scrum Rollen noch gefunden habe. Die Konstellation von Product Owner und Requirements Engineer, wie wir sie leben, braucht sehr viel ehrliche, offene und auch kritische Kommunikation, aber es lohnt sich.
Zum Schluss möchte ich euch ermuntern, auch eure Scrum Konstellation immer wieder kritisch zu hinterfragen und den Mut zu haben, eure Beobachtungen offen anzusprechen. Bleibt respektvoll, fokussiert und engagiert.
Weiterführende Links:
“Der Scrum Guide” https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf
