Anforderungsermittlung in einer hochkomplexen, fast chaotischen Umgebung — Das Backlog Refinement in Scrum!
Von Nils Hyoma, Jan Schneider und Wuk Petrovic.
Die erste Version ist erschienen in bei Entwickler.de. Dank an die Novatec Consulting GmbH besonders die PA Agile Methoden für den Support.
“Backlog refinement takes you from Vision to Value”
[1], so beschreiben Ellen Gottesdiener und Jeff Sutherland Backlog Refinement. Für Jeff Sutherland, einer der beiden Schöpfer von Scrum, ist das Backlog Refinement das Rückgrat von hoch performanten Teams (HPT). Doch was macht diese Teams aus und welche Vorteile bringen diese? Durch starken Fokus auf das Erreichen ihrer Ziele liefern sie deutlich wertvollere Ergebnisse als weniger zielorientiere Teams. Häufig übertreffen sie schon kurzfristig die Erwartungen ihrer Organisation [2].
Scrum bringt bereits grundlegende Voraussetzungen mit, um das Entstehen von HPT zu fördern: eine klare Rollendefinition und greifbare Ziele in der Form von Sprint und Product Goals. Zusätzlich ist die Retrospektive ein mächtiges Werkzeug, um Barrieren zu beseitigen, die dem Team im Weg stehen. Unterstützen die Organisation und die Stakeholder:innen das HPT in der Produktentwicklung, wird dieser Effekt deutlich verstärkt. Doch wie setzt die Organisation die richtigen Ziele? Gemeinsam mit Nutzer:innen, Kund:innen, Stakeholder:innen und insbesondere dem Scrum-Team. Eine vor dem oder im ersten Sprint erstellte Produktvision gibt allen beteiligten Personen klaren Fokus. Für deren Erstellung und Aktualisierung im Sprint gibt es von Scrum einen dafür vorgesehenen Prozess: das Backlog Refinement. Dieses ist am wenigsten aller Events beschrieben, ist aber essenziell für agiles Vorgehen. Der Prozess, der sich in einer komplexen Welt bewährt hat, wird in Abbildung 1 dargestellt. Die Motivation für das Vorgehen hierfür ist im “Kapitel Kollaboratives Product Ownership durch Backlog Refinement” beschrieben.
Backlog Refinement
Der Scrum Guide von 2017 beschreibt den Vorgang mit genau einem Absatz: “Als Refinement [Verfeinerung] des Product Backlogs wird der Vorgang angesehen, in dem Details zu Einträgen hinzugefügt, Schätzungen erstellt, oder die Reihenfolge der Einträge im Product Backlog bestimmt werden. Das Refinement ist ein kontinuierlicher Prozess, in dem der Product Owner und das Development Team gemeinsam die Product-Backlog-Einträge detaillieren. Beim Refinement des Product Backlogs werden die Einträge begutachtet und revidiert. Das Scrum Team bestimmt, wann und wie diese Verfeinerungsarbeit erfolgt. Sie sollte normalerweise nicht mehr als 10% der Kapazität des Development Teams beanspruchen. Der Product Owner kann jedoch jederzeit die Einträge im Product Backlog aktualisieren oder aktualisieren lassen.” [3]
Für neu zusammengesetzte Teams ist diese Freiheit, die das Produktentwicklungsframework lässt, häufig überfordernd. Was in der Definition gezielt nicht berücksichtigt ist: Wie die später zu verfeinernden Anforderungen gefunden und erstellt werden. Außerhalb des Scrum-Guides sind folgende Elemente zu finden, die ein Backlog Refinement ausmachen [4]:
· Schätzen der Backlog Items
· Priorisierung des Backlogs
· Aufsplitten von zu großen Arbeitspaketen
· Finden und Auflösen von Abhängigkeiten
· Entfernen von nicht mehr relevanten Anforderungen
· Erstellen von neuen Requirements
· Erkenntnisse gewinnen
Das Ziel vom Backlog Refinement besteht darin, sicherzustellen, dass das Product Backlog mit relevanten, detaillierten und priorisierten Elementen gefüllt ist. Das Product Backlog entspricht damit dem aktuellen Verständnis des Produkts und dessen Zielen. Im Gegensatz zu einem formelleren “Anforderungsdokument” ist das Product Backlog ein dynamischer, emergenter Informationsbestand. Beispielsweise müssen nicht alle User Stories zu Beginn des Projekts auf ein feines Niveau heruntergebrochen oder mit detaillierten Schätzungen versehen werden. Es ist jedoch wichtig, dass jederzeit eine ausreichende Anzahl von Anforderungen für die Teams zur Verfügung steht.
In dem nächsten Kapitel wollen wir zeigen, wie das Product Ownership kollaborativ vom ganzen Team übernommen wurde und welche positiven Effekte entstanden sind.
Kollaboratives Product Ownership durch Backlog Refinement
Das bisherige Vorgehen ist durch eine herausfordernde Ausgangssituation entstanden, in welcher ein Product Owner gleichzeitig ein Geschäftsführer einer Firma mit 1500 Mitarbeiter:innen war. Er hatte durch seine Verpflichtungen deutlich weniger Zeit, als sich seine Scrum-Teams gewünscht hätten und die Rolle eigentlich vorsieht. Er war durch sein Wissen über die gewünschten Prozesse und die Umgebung nicht einfach ersetzbar. Sein Einfluss als Geschäftsführer rückte die Produktentwicklung signifikant in die Ausrichtung der Organisation. Das zu entwickelnde Produkt war eine fast vollständig automatisierte Dispositionssoftware für einen großen Flughafen. Diese stellt den reibungslosen Ablauf zwischen Dienstleistungen sicher und hat die Zielsetzung, dass Flugzeuge so schnell wie möglich abgefertigt werden. Die eng vernetzten Prozesse, kurze Time-Slots und unvorhersehbare Ereignisse sowie Anbindung an verschiedene Fremdsysteme sind permanente Herausforderungen bei der komplexen Planung des Dispositionsalgorithmus. Jede falsche Entscheidung kann zu Kettenreaktionen — auch im Luftraum — führen. Im schlimmsten Fall kommen Hunderte Passagiere nicht am geplanten Tag an ihr Ziel.
Das Produkt selbst ist in einem Product-Hub eingebettet. Das bedeutet, dass die vollständige Wertschöpfungskette sich über mehrere zusammenwirkende, aber unabhängige Produkte erstreckt. Bei einer Analyse der Anwendungsdomäne unter Gesichtspunkten von Domain-driven Design haben wir die Disposition als Kerndomäne des Auftraggebers identifiziert. Andere Domänen, wie die Rechnungsstellung hingegen haben wir als generische Domänen klassifiziert. Für diese werden vom Kunden, soweit möglich, Standardprodukte eingesetzt. Ein entscheidendes Alleinstellungsmerkmal für die Organisation ist die Entwicklung von Individualsoftware in ihrer Kerndomäne. Deshalb wurde die Dispositionssoftware der Bodenverkehrsdienste als führendes Produkt ausgewählt. Diese Strukturierung ermöglicht es, Abhängigkeiten auf Quellcodeebene zwischen den einzelnen Teams zu minimieren. Hierdurch können mehrere Teams Software in einer gemeinsamen Domäne entwickeln, ohne auf demselben Product Backlog oder derselben Codebasis arbeiten zu müssen.
Definieren von Zielen durch ein Product Vision Board
Der erste Schritt vor dem Füllen des Backlogs mit Anforderungen besteht aus dem Erarbeiten einer Vision im oder vor dem ersten Sprint. Um eine Basis für eine Zusammenarbeit zu etablieren, findet zwischen Scrum-Team, User:innen und Stakeholder:innen ein Kick-off-Workshop statt. Bei dem Gedankenaustausch werden erste wertvolle Kontakte zu positiven und einflussreichen Stakeholder:innen und Nutzer:innen geknüpft, die auch später für die Refinement-Prozesse und das Change-Management wichtig sind. Durch den Austausch auf Augenhöhe werden Ideen und Bedürfnisse aller Beteiligten gesammelt, ein gemeinsames Verständnis zur Produktvision aufgebaut und das Team-Commitment gestärkt.
Methodisch empfehlen wir hierbei ein angepasstes Product Vision Board von Roman Pichler(Abb. 2). Bei der Orientierung an diesem Schema werden sowohl Zielgruppen als auch Bedürfnisse diskutiert und ausgewählt. Im nächsten Schritt einigt sich das Team dann auf Produkte, Produkt- sowie Sprint-Ziele. Dieses gibt dem Team durch eine abgestimmte Priorisierung einen klaren Fokus.
Im nächsten Schritt muss das Product Backlog dann mit Anforderungen gefüllt werden, die den Produktzielen entsprechen. Anforderungen, welche diese Voraussetzungen nicht erfüllen, können zwar knapp dokumentiert werden, liegen aber nicht im Fokus des Scrum-Teams. Gute Erfahrungen gibt es mit fachlichen Produktzielen, die den Lösungsraum offenlassen und das Problem in den Vordergrund stellen. Exemplarisch seien hier die “Abschaffung des Funkverkehrs in Standardabläufen bei Bussen” oder die “Automatisierte Disposition von Bussen” genannt. Das erstgenannte Ziel lässt es offen, ob dieses durch Softwareentwicklung, durch Change-Management oder einer Kombination erreicht werden wird.
Füllen des Product Backlogs
Basierend auf dem höchsten priorisierten Sprintziel (hier exemplarisch das Ziel “Abschaffung des Funkverkehrs in Standardabläufen bei Bussen”) gilt es jetzt, Anforderungen zu identifizieren und diese kontinuierlich zu verfeinern. Für die Identifikation und ein besseres Verständnis bietet sich Job-Shadowing an. Das Formulieren und bedarfsgerechte Schneiden von User-Stories sind hierbei erfahrungsgemäß gut über Tools zu lösen, welche die Zusammenarbeit im Team, aber auch im gesamten Unternehmen unterstützen. Hier bietet sich unserer Erfahrung nach Jira (Abb. 3) an, da dieses auf agiles Arbeiten ausgelegt ist und sich auf die individuellen Anforderungen und Arbeitsweisen des Teams anpassen lässt.
Job-Shadowing
Das Begleiten von Mitarbeiter:innen bei der Arbeit ist ein effektives Werkzeug, um mit — in der Regel — wenig Aufwand Wissen über die jeweilige Domäne aufzubauen. Je nach Situation ist es im Job-Shadowing auch möglich, Arbeitsschritte selbst auszuprobieren oder zumindest zu beobachten. Dabei wird ein Verständnis aufgebaut, wie Prozesse und Arbeitsabläufe wirklich durchgeführt werden, welche Probleme auftreten können und wie diese bisher gelöst werden. Die Methode ist eigentlich für die Personalentwicklung gedacht, lässt sich dennoch genauso gut bei der Anforderungsermittlung einsetzen. Ein positiver Nebeneffekt kann hierbei der Aufbau von Vertrauen zwischen Arbeiter:innen und Entwickler:innen sein (Abb. 4). Stellen Sie sich vor, Sie seien ein:e Lader:in an einem Flughafen und ein:e Entwickler:in entlädt mit Ihnen gemeinsam ein Flugzeug. Die Mitarbeiter:innen werden direkt mit den Entwickler:innen offen und ehrlich über Anforderungen an die Software sprechen. Anhand des Informationsaustausches zwischen Entwickler:in und Arbeiter:in wird eine zukunftsgerichtete Strategie erarbeitet. Diese unterstützt dabei, den gewonnen Input in der Produktentwicklung effektiv zu nutzen.
Vom (Domain) Storytelling zu User-Stories
Das im vorherigen Schritt erworbene Wissen muss festgehalten und bestätigt werden. In einer komplexen Domäne ist es fast unmöglich, Businessprozesse treffend zu definieren. Um eine Kollaboration zwischen dem Scrum-Team und den Expert:innen zu ermöglichen, bietet sich Storytelling [6] an. Eine Geschichte beim Storytelling ist immer chronologisch aufgebaut und es gilt das Kredo: je genauer, desto besser. Das macht sie auch für Menschen ohne IT- oder Prozessmanagement-Background einfach zu verstehen.
Domain Storytelling als Methode nutzt eine simple Bildsprache. Hiermit können Geschichten über den Anwendungsbereich erzählt und dokumentiert werden. Die Methode setzt auf drei Arten von Symbolen, die durch Icons und Pfeile dargestellt werden: Akteure, Arbeitsgegenstände und Aktivitäten. Wenn sich das Team an das Vorgehen hält, ist die Ableitung von User-Stories in der Regel sehr trivial.
Um ein gemeinsames Grundverständnis über die zu entwickelnde Software zu gewinnen, bietet sich der sogenannte „Happy Path“ an. Dieser stellt einen einfachen Ablauf, in dem alles problemlos funktioniert dar. Er bildet somit die Verständnisgrundlage über den Zweck des gelebten Prozesses. Anschließend werden dann weitere kritische Geschichten basierend auf eigenen Erfahrungen erzählt und als Domain Story dokumentiert. Durch die skizzierten und wirklich erlebten Geschichten können alle User:innen die Sinnhaftigkeit und Korrektheit von Anforderungen bestätigen oder konkrete Änderungswünsche äußern.
In Abbildung 6 ist ein gelebter Prozess ohne Tablet und Dispositionssoftware dargestellt. Er bildet die Basis für eine Diskussion zu der gewünschten Digitalisierung. In Abbildung 5 ist zu sehen, wie Domain Storytelling kollaborativ eingesetzt worden ist.
In Abbildung 7 ist ein Soll-Diagramm. Gemeinsam wurde erarbeitet, wie eine Digitalisierung stattfinden könnte, ohne die Nutzer:innen zu überfordern. Aus dem Ergebnis können relativ einfach User Stories abgeleitet werden.
Planung eines Minimal Viable Product
In der Praxis hat sich nach Klärung der Anforderungen das Vorgehen etabliert, dass die entscheidenden Bestandteile für die gewünschte Anwendung identifiziert werden. Hierbei spricht man vom Minimum Viable Product (MVP) (Abb. 5). Dieses ist nur mit den Kernfunktionen der geplanten Software ausgestattet, da der Fokus auf einer schnellen Einführung und anschließend auf kleinen Experimenten liegt, welche den Wert der Annahmen zum Produkt bestätigen sollen. Frühzeitiges Feedback wird benutzt, um das MVP Iteration für Iteration zu verbessern und den Nutzen, sowie die Zufriedenheit der Nutzer:innen zu maximieren.
Doch wie kann ein Produkt sinnvoll auf ein MVP reduziert werden? Ein möglicher Weg: eine reduzierte Qualität des User-Interface, möglichst keine Abhängigkeiten zu Fremdsystemen und eine Auswahl von minimalen, aber mehrwertbringenden Funktionalitäten, wie dem Happy Path. Wichtig ist, dass bei der Wahl der Anforderungen eine Lösung geplant wird, welche die zukünftigen Anwender:innen nicht überfordert und gleichzeitig die wichtigsten Use Cases erlebbar macht. Dieses wird erreicht, wenn wir uns an den aktuellen Prozessen der Anwender:innen orientieren.
Design Studio
Durch die vorangegangenen Schritte des Job-Shadowing und Storytelling hat sich das Team auf eine Umsetzungsreihenfolge der User-Stories und einen groben Zeitplan geeinigt. Das Ziel ist, das Produkt zeitnah zu veröffentlichen und Experimente starten zu können. In unserem Szenario geht es um eine Expertensoftware für die Disponent:innen von Bodenverkehrsdiensten, bei der die Funktionalität eine höhere Priorität als die User-Experience und intuitive Bedienbarkeit besitzt.
Die User-Stories mit den technischen und fachlichen Anforderungen sind schon vorhanden und jetzt steht das Team vor der Herausforderung, ein passendes UX/UI-Design mit den Stakeholder:innen zu entwickeln.
Design Studio ist ein interaktiver Ideation-Workshop, der Scrum ergänzt und in dem gemeinsame Gedanken und Ideen zu möglichen Lösungen ausgetauscht und erarbeitet werden. In dieser Zusammenarbeit entwickelt sich ein Verständnis, wie das Produkt gestaltet wird und es sich verhält. Dies startet mit dem Erstellen eines Initialprozesses und geht über die User Experience bis zu Wireframes eines User Interfaces und wird immer wieder durch Sprinterkenntnisse ergänzt und weiterentwickelt. Auf Basis der grafischen Mockups können die Nutzer:innen und Stakeholder:innen jetzt das zukünftige Produkt einfacher verstehen und gezielt Änderungswünsche, Bedenken oder Fragen einbringen. Durch das in diesem Prozess gewonnene Feedback und die gemeinsame Zusammenarbeit wird das MVP für alle Beteiligten greifbar. Dabei wird das Wissen über die Kerndomäne durch diesen Austausch und Einbeziehung verschiedener Sichtweisen weiter ausgebaut.
Exkurs Design Studio:
Hier ist ein online Workshop zu Design Studio zu finden:
Auflösen von externen Abhängigkeiten
In der letzten Phase des Backlog Refinement liegt der Fokus darauf, teamübergreifend Abhängigkeiten zu identifizieren und den Umgang mit ihnen zu planen. Dieses konnte in folgende Schritte unterteilt werden:
· Weitere Anpassung des MVP auf Basis von Produkt- und Sprintzielen
Der Product Owner der Dispositionssoftware erstellt mit Stakeholder:innen und Entwickler:innen eine Releaseplanung für das MVP oder ein neues Modul auf Basis von priorisierten Produktzielen, oder wenn möglich Sprint-Zielen.
· Koordination von teamübergreifenden Sprintzielen
Die Sprint-Ziele wurden in einer Releaseplanung den Product Ownern aus den weiteren Domänen vorgestellt. Wenn das Produkt der Kerndomäne Anforderungen an andere Produkte hat, werden die Sprints bestenfalls synchronisiert.
· Detailplanung mit mehreren Scrum-Teams
Nach der Harmonisierung der Sprint-Ziele durch die beteiligten Product Owner wurden die Entwickler:innen mit eingebunden. Diese klären miteinander ab, ob die Sprint-Ziele trotz möglicher Abhängigkeiten erreichbar sind bzw. angepasst werden müssen.
· Umsetzung der Anforderungen im Sprint
Die Teams setzen die Anforderungen mit Abhängigkeiten zeitgleich und als teamübergreifende Pairs um. Dies verringert die Notwendigkeit von Dokumentation für die weitere Planung immens. Fertige Inkremente können so schon während des Sprints den Product Ownern oder Stakeholder:innen präsentiert werden. Technische Fragen werden im Pair geklärt.
· Gemeinsame Sprint-Review
Das Ende oben skizzierter Sprints wird durch eine gemeinsame Sprint-Review der beteiligten Teams abgeschlossen, in der der Status-Quo der Entwicklung domänenübergreifend ersichtlich wird. Die Sprint-Review für mehrere Gruppen von Stakeholder:innen durch den Fokus auf untereinander verbundene Produkte ist für die Gäste zudem greifbarer und weniger abstrakt.
Experimentieren und Coaching
Nach der Umsetzung der Features — teilweise vor der Sprint-Review — wurden die Veränderungen in die Produktion übernommen. Die minimalen, aber stetigen Änderungen führen dazu, dass die Nutzer:innen konstant mit eingebunden, jedoch nicht überfordert, werden. Für kritische Anpassungen ist das Scrum-Team in die Leitstelle der Bodenverkehrsdienste gegangen und hat mit dem dortigen Team vor Ort Entscheidungen getroffen.
Dies bringt neben Wissen über die Software und den Einsatzbereich noch weitere wesentliche Vorteile:
· Aufbau von Wissen bei den Entwickler:innen über Extrem- und Ausnahmesituationen sowie über Wünsche und Bedürfnisse der Nutzer:innen
· Bildung einer engen Vertrautheit und Verbundenheit zwischen Scrum-Team und Nutzer:innen der Software
· Zeitnahe Einschätzung der Kritikalität von Fehlern und deren mögliche Lösungen durch das Scrum-Team
Bei Tests werden, trotz strukturiertem Backlog Refinement, häufig Probleme gefunden — ausgelöst durch bisher unbekannte Situationen. Diese werden entweder als Bug zeitnah behoben oder als neue Anforderung im Backlog aufgenommen. Wenn das neue Feature stabil funktioniert, werden die Nutzer:innen gecoacht.
Mehrwert durch Kollaboration im Backlog Refinement
Nachdem wir im vorherigen Abschnitt einen möglichen Ablauf des Refinement-Prozesses in einer sehr komplexen Umgebung beschrieben haben, gehen wir in diesem Kapitel auf den entstehenden generellen Mehrwert von Zusammenarbeit in der Produktentwicklung ein.
Nachhaltige Lösungen
Eine konventionelle Lösung für ein Problem geht von Annahmen einer idealen Welt aus. In komplexen Umfeldern entsprechen definierte Prozesse aber nicht gelebten Arbeitsabläufen. Das führt zu Problemen, wenn ein neues Produkt eingeführt wird, da durch mangelnde Flexibilität in der neuen Software die Prozesse jetzt starr gelebt werden müssen. Wenn bei der Lösungsfindung — hier der Anforderungsermittlung — unterschiedliche Sichtweisen einbezogen werden, dann kann das helfen, die wirklichen Kriterien für ein erfolgreiches Produkt zu verstehen. Durch eine Diskussion und ein iteratives Vorgehen bei der Lösungsfindung, wie bei Design Studio, entstehen so innovative, nachhaltige und wertvolle Lösungen. Nachhaltige Lösungen bedeuten langfristig auch geringere Risiken und auch Kosten.
Identifikation
Eine Innovation ist nur erfolgreich, wenn die Mitarbeiter des Unternehmens hinter ihr stehen und von ihr profitieren. Der sicherste Weg, diese Unterstützung zu gewinnen und ihre Bedürfnisse zu berücksichtigen, besteht darin, sie in den Prozess der Ideengenerierung so früh, wie möglich einzubeziehen. Für das Produktentwicklungsteam bedeutet die Identifikation, dass die Mitglieder befähigt werden, mit den Stakeholder:innen und Nutzer:innen Diskussionen auf Augenhöhe führen zu können.
Change-Management
Durch das oben beschriebene frühe Einbeziehen der Nutzer:innen und der Berücksichtigung ihrer Bedürfnisse in den Anforderungen des zu entwickelnden Produktes, findet beiläufig ein Wissenstransfer zwischen allen Beteiligten statt.
Zusätzlich zu der Akzeptanz sind für eine erfolgreiche Etablierung einer Software auch Einführungen in kurzen und stetigen Zyklen förderlich, damit die User:innen nicht überfordert werden. Ein Vorgehen in Sprints mit häufigen kleinen Releases und Feedbackschleifen ist hierfür ideal. Unterstützt wird dieses Vorgehen durch persönliche Kontakte, die u.a. beim Job-Shadowing und beim Coaching aufgebaut werden. Das führt dazu, dass alle Beteiligten die Bedürfnisse aller sehen und diese in der Software und darüber hinaus berücksichtigen.
Unbewusst wird bei dem von uns skizzierten Vorgehen schon ein positives, agiles und produktives Change-Management mit dem agilen Team im Kern durchgeführt. Die frühe und stetige Wissensvermittlung an die User:innen wird häufig unterschätzt.Dieses kann unterstützend durch traditionelle Change-Managementmethoden gefestigt werden.
Scrum-Events und -Artefakte
Durch die Kollaboration der unterschiedlichen Gruppen wird ein gemeinsames Verständnis der Kerndomäne bei allen Beteiligten aufgebaut. Basierend auf diesem Verständnis wurden die Scrum-Events und Artefakte mit der gemeinsamen Vision ergänzt. Wir beobachteten, dass die Dokumentation, wie zum Beispiel die tiefe Granularität von User-Stories oder die schriftliche Planung des Umgangs mit Abhängigkeiten auch über unterschiedliche Teams hinweg deutlich abnimmt, ohne zu Problemen zu führen. Die hierdurch gewonnen Freiheiten führten in Kombination mit der Identifikation und dem Domänenwissen zu einer höheren Effektivität. Die Scrum-Events, wie die Sprint Planung, konnten so deutlich zielgerichteter durchgeführt werden und die vom Scrum-Guide vorgegebenen Time-Boxen wurden selten vollständig ausgenutzt. Das liegt auch daran, dass schon viel Kommunikation vorab stattfindet.
Done ist Done
Durch die Einbindung von einflussreichen Gruppen von Stakeholder:innen in den Refinement-Prozess, wie den Betriebsrat, sind die Product Backlog Items so gut geklärt, dass es keine weitere technische und fachliche Kontrolle mehr nach der Softwareentwicklung bedarf. Somit sind die Product Backlog Items, wenn sie der Definition of Done entsprechen, risikolos auslieferbar.
Fazit
Die Erkenntnisse aus unserem Vorgehen konnten schon in mehreren Teams und Projekten zielführend eingesetzt werden. So lässt sich für die Autoren ein Muster erkennen: je mehr die Entwickler:innen eingebunden werden, umso stärker können sie auch Verantwortung übernehmen und sich einbringen. Damit steigt die Zuverlässigkeit, die Vorhersagbarkeit, die Softwarequalität und der wirkliche Nutzen der Software.
In unserem Fall war bis zum ersten Experiment in der Leitstelle der Wert der Anforderungen trotz Kollaboration mit User:innen und Stakeholder:innen nur Theorie. Durch die Validierung wurden Abweichungen und damit auch weiteres Wissen über die Kerndomäne entdeckt. Die Entwickler:innen konnten ihr Domänenwissen deutlich vertiefen.
Für die Akzeptanz und damit den erfolgreichen Einsatz einer[JK1] [HN2] Software ist das Vertrauen der Nutzer:innen in das Produkt essentiell. Durch den persönlichen Austausch zwischen Entwickler:innen und Nutzer:innen wurden Ängste genommen und das Vertrauen gestärkt. Wie bei Job-Shadowing entwickelten sich hilfreiche Bindungen und ein Verständnis über die wahren Bedürfnisse und damit Anforderungen.
So gelang es dem Scrum-Team, federführend in einer komplexen Umgebung nachhaltig Software zu erstellen, die auch stetige Anpassungen in der Organisation des Auftraggebers erforderte. Das Team hat durch den kollaborativen Refinement-Prozess sich nicht nur Anforderungen selbständig erarbeitet, sondern auch modernes Change-Management angestoßen. Durch dieses konnte die Software nachhaltiger gestaltet und ein Wandel zu einer modernen und agilen Kultur bei den Bodenverkehrsdiensten angestoßen und begleitet werden.
Weitere Informationen zu Backlog Refinement
Links
[1] https://www.scruminc.com/backlog-refinement-vision-value/
[2] Katzenbach et al.: The Wisdom of Teams, HarperBusiness, 2003
[3] https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf
[4] https://www.zombiescrum.org/
[5] https://miro.com/templates/technology-product-canvas/
[6] https://domainstorytelling.org/
Der Artikel ist auch auf Englisch veröffentlich: Backlog Refinement
