Unter dem Begriff agiles Arbeiten werden immer mehr Themen gebündelt: von inkrementeller Software-Entwicklung über Rapid Prototyping und Continuous Integration bis hin zu selbstorganisierten Teams, New Work und Agile Leadership. Die Zusammenführung dieser vielen Konzepte und Methoden ist ein perfekter Nährboden für Missverständnisse.

Für agiles Arbeiten, vor allem in einem regulierten Arbeitskontext, wollen wir deshalb eine klare Empfehlung aussprechen: Trennen Sie das Product Backlog (und dessen Backlog Items) von den Anforderungen! Denn Anforderungen definieren, was das Produkt können muss, während mithilfe des Backlogs festgelegt wird, wie dieses Ziel erreicht wird. Das Product Backlog umfasst alle notwendigen Aufgaben zur Zielerreichung, während Anforderungen die gewünschten Produkteigenschaften beschreiben, was insbesondere für stark regulierte Branchen notwendig ist.

Die Trennung dieser konzeptionellen Ideen ist eine wichtige Grundlage für agiles Arbeiten und hilfreich für die Arbeitsweise jedes Unternehmens. Dies gilt unserer Erfahrung nach ganz besonders in regulierten Industrien wie der Medizintechnik, weil explizit die Dokumentation von Anforderungen einigen rechtlichen Vorgaben unterliegt. Die Regulatorik und die zugehörige Dokumentation sowie lückenlose Nachvollziehbarkeit von Anforderungen lösen erhebliche Mehraufwände aus. Gleichzeitig betont die Regulatorik aber, dass zwischen den Anforderungen an das Produkt und der Umsetzung der Anforderungen unterschieden wird.

Anforderungen und Product Backlog: Strenge Trennung für mehr Agilität

Wie der von der FDA unterstützte Leitfaden für den Einsatz agiler Methoden bei der Entwicklung von medizinischen Geräten (AAMI TIR45 Stand 2023) bereits feststellt, sollte ein Product Backlog alle Arbeiten umfassen, die ein Team erledigen muss. Die Betonung liegt hierbei auf allen Arbeiten (all work), was für medizinische Produkte auch die Arbeit an der Dokumentation des Produkts und die Dokumentation der Anforderungen beinhaltet. Ein gemeinsamer Nenner, der sowohl die agile Arbeitsweise als auch die Entwicklung der Anforderungen positiv beeinflusst, sind das Product Backlog und dessen Inhalte, die Backlog Items.

Auch bei der Entwicklung medizinischer Produkte gelten die betriebswirtschaftlichen Grundsätze – agile Arbeitsweise hin oder her. Jedoch liegt bei der agilen Vorgehensweise der Fokus des Magischen Dreiecks auf dem Umfang der Entwicklung (Scope), und die Größe "Zeit" wird fixiert (siehe "Timeboxing" durch fixe Sprintlängen und Release(-trains)). Die anderen Größen des Dreiecks, also Kosten und Qualität, gelten als unverrückbar. Aus diesem Grund muss der Entwicklungsfortschritt des Produkts fortwährend überprüft und "gemanagt" werden – wodurch sich der Fokus auf den möglichen Umfang und dessen jeweiligen Wertbeitrag richtet. Und genau hier fungiert der Product Backlog als das Werkzeug im agilen Werkzeugkoffer, um den Umfang kontinuierlich anzupassen.

Agiles Arbeiten mit Anforderungen und das Zusammenspiel mit dem Product Backlog

Das Product Backlog ist, wie der Name bereits klarstellen soll, voll und ganz ausgerichtet auf das gemeinsame Ziel: das Produkt. Für das Beispiel in Bild 1 haben wir ein Wohnhaus als Produkt gewählt. Das ist bewusst weder medizinisch oder komplex, sondern für jeden nachvollziehbar und auf den Kern unserer Aussage reduziert.

Eine Produktversion 1, die sich bereits auf dem Markt befindet, erfüllt die an das Produkt gestellten Anforderungen. Das Product Backlog ist (für die Version 1) leer, da wir nichts mehr für das Produkt umsetzen müssen, um die nötigen Anforderungen zu erfüllen. Während der Entwicklung der Version 1.0 gab es einen Backlog, den die Teams entsprechend abgearbeitet haben. In unserem Beispiel hält das Haus erfolgreich den Regen von den Bewohner:innen und Möbeln ab und genügt somit den Anforderungen.

Eine geplante Produktversion 2.0, wie auf dem Bild 1 rechts zu sehen, soll nun weitere Bedürfnisse erfüllen und Probleme des Nutzers lösen. Die Anforderungen treffen also eine Aussage darüber, wie die Beschaffenheit eines Produkts (Haus mit Garage) sein muss, damit der Nutzer sein Ziel erreicht bzw. seine Bedürfnisse erfüllt sind. Die Anforderungen bzw. deren Dokumentation existiert also so lange, wie das zugehörige Produkt existiert, und wird über neue Versionen erweitert. Selbst wenn das Produkt fertig und auf dem Markt ist (und der Backlog mit seinen Aufgaben abgearbeitet), sind die Anforderungen Teil der permanenten Dokumentation (in der Medizintechnik: Technische Dokumentation). Die Anforderungen dienen also als ein mentales Modell aller Kriterien, die das Produkt erfüllen soll. In der Medizintechnik ist u.a. diese Dokumentation Teil des Produkts, weil es für die Zulassung und damit die Lizenz für den Verkauf regulatorisch gefordert ist.

Problembereich und Lösungsbereich trennen

Diese abstrakte Formulierung der Anforderungen, ohne bereits auf die Lösungsmöglichkeiten (Problembereich) einzugehen, ist in der Praxis schwieriger als in unserem Beispiel – ganz besonders wahrscheinlich für Ingenieure, deren Aufgabe die spezifische Lösungsfindung ist. Hohe Aufmerksamkeit und Disziplin sind gefordert, damit die Anforderungen für unser Haus nicht zu eng an die Umsetzung gebunden sind. Beispielsweise klingen Formulierungen wie "Das Haus braucht eine Garage" oder "Es soll ein Dach über das Auto" zwar sehr ähnlich und naheliegend, sie sind aber bereits an eine bestimmte Lösung gekoppelt und reduzieren unseren Entwicklungsspielraum erheblich. Es ist essenziell, erst die Kundenperspektive zu verstehen, bevor über Details einer Lösung nachgedacht wird.