Das Anforderungsmanagement bei agilen Projekten bildet die Grundlage für das Projekt, wie es auch bei traditionellen Projekten ist. Bei agilen Projekten und auch bei Scrum unterscheidet sich das Anforderungsmanagement jedoch in wesentlichen Punkten von dem in traditionellen Projekten nach dem Wasserfall-Modell. In diesem Artikel lernen Sie die Unterschiede kennen und erfahren, wie die Anforderungen identifiziert und weiter verarbeitet werden, bis das erste Product Backlog bereit ist.
Der Unterschied bei der Anforderungsbeschreibung bei traditionellen und bei agilen Projekten
Bei traditionellen Projekten werden die Anforderungen zu Projektbeginn in der Definitionsphase möglichst vollständig erfasst und präzise beschrieben. Danach werden sie vom Kunden, Auftraggeber oder Fachbereich abgenommen. Erst dann beginnt die Umsetzung der Anforderungen in den Folgephasen. Dies mag bei einigen Projektarten sehr sinnvoll sein, z.B. wenn Sie ein Haus bauen oder ein Flugzeug entwickeln. Bei vielen Softwareprojekten sind die Anforderungen bei Projektbeginn noch nicht vollständig bekannt oder sie ändern sich oft oder es kommen neue dazu. Hier ist die traditionelle Projektvorgehensweise nach dem Wasserfall-Modell sicher nicht sinnvoll.
In Scrum vertritt der Product Owner die Bedürfnisse des Kunden, der Anwender und anderer Stakeholder. Das heißt, er ist für die Anforderungen verantwortlich und bestimmt, welche Anforderungen in welcher Reihenfolge umgesetzt werden.
Anforderungen werden in Scrum während der ganzen Projektdauer erfasst und immer wieder neu priorisiert. In der folgenden Abbildung können Sie den Unterschied zu traditionellen Projekten gut erkennen. Der große Vorteil von Software ist natürlich, es wird nichts Physisches hergestellt und darum ist man hier mit Änderungen und neuen Anforderungen natürlich viel flexibler.
Wer liefert die Anforderungen?
Für die Anforderungen ist der Product Owner verantwortlich. Er wird aber nicht die Hauptquelle für Anforderungen sein. Wie Sie sicher bereits wissen sind dies der Kunde und die Nutzer. Ein Product Backlog, bei dem alle Anforderungen vom Product Owner stammen ist ein schlechtes Zeichen.
Es ist ein gutes Zeichen wenn auch Andere einen Beitrag leisten. Speziell, wenn es um nichtfunktionale Anforderungen geht ist die Erfahrung z. B. von Architekten oder anderen Spezialisten gefragt. Vielleicht bringt ein Teammitglied Erfahrungen aus einem ähnlichen Projekt bei einem anderen Kunden mit? Hier ist der Product Owner gefragt all dieses Wissen, Erfahrungen und Kunden- und Nutzerbedürfnisse zusammenzubringen.
Der Beitrag des Scrum-Teams selbst hat folgende Vorteile:
- Wenn die Scrum-Teammitglieder aktiv mitarbeiten, dann fühlen sie sich mitverantwortlich für die Anforderungen. Das ist viel besser als die Einstellung: “Ich tue nur das, was man mir sagt.”
- Wenn mehr Köpfe über die Frage nachdenken, was die Nutzer wollen oder was das System tun soll, wird mehr Kreativität in das Problem einfließen.
- Developer, die ermutigt werden, Ideen zum Product Backlog beizutragen, werden sich notwendigerweise die Zeit nehmen, um mehr über die Benutzer, Ziele, Wettbewerber und mehr des Produkts zu erfahren. Dieses Wissen wird den Developern bei der Entwicklung der Funktionalität weiterhelfen.
Das heißt aber schlussendlich nicht, dass ein Product Owner auf alle Ideen anderer reagieren muss. Aber mit ziemlicher Sicherheit werden einige dieser Ideen es wert sein, weiterverfolgt zu werden.
Der Product Owner entscheidet zwar darüber, was entwickelt werden soll, aber nicht alle Ideen dafür müssen von Ihm stammen. Wenn Andere zum Product Backlog beitragen, ist es viel wahrscheinlicher, dass das Team und das Projekt erfolgreicher ist.
Mit was für Hilfsmitteln der Product Owner die Anforderungen findet, analysiert und erfasst erfahren Sie im den nächsten Abschnitten.
Erfassen der Anforderungen
Wie Sie bereits in vorhergehenden Abschnitt gelesen haben können die Anforderungen mit verschiedenen Methoden bei den Stakeholdern erfasst und analysiert werden. Zu Beginn des Projektes gehören dazu zum Beispiel:
- Interviews
- Beobachten der Anwender bei der Arbeit
- Workshops
Im weitern Verlauf des Projektes werden immer wieder neue Anforderungen erfasst, bestehende angepasst oder verworfen. Dafür wird dann meistens das Estimation Meeting (Backlog Refinement Meeting) verwendet.
Der Anforderungsworkshop
Einer der effizientesten Mittel Anforderungen zu erfassen ist ein 1-2 tägiger Anforderungsworkshop mit dem Kunden, Anwendern und evtl. anderen Stakeholder. Wichtig ist, dass auch Developer daran teilnehmen, denn diese werden später die Anforderungen umsetzen.
Der Vorteil dabei ist, dass die Developer ohne „Übermittler“ die Anforderungen direkt hören, was Kommunikationsfehler und somit Missverständnisse vermeidet und sie somit ein besseres Verständnis für die Kundenbedürfnisse erhalten. Auch können sie bei Unklarheiten sofort nachfragen.
Als erstes stellt der Product Owner den Teilnehmern die Produktvision vor und danach findet ein Brainstorming statt, um die Anforderungen zu erfassen. Die Teilnehmer am Workshop sind aktiver, wenn sie die Anforderungen auf Pinwandkarten erfassen.
Gleiche oder ähnliche Anforderungen können Sie dann gut an einer Wand gruppieren, damit diese dann detailliert besprochen werden können.
Ideal ist es, wenn die Teilnehmer die Anforderungen als User Stories definieren, diese einen Business Grund und Wert (Business Value) besitzen und Akzeptanzkriterien enthalten, die definieren, wann die Anforderung umgesetzt (Done) ist. User Stories werden für einige Teilnehmer neu sein. Deshalb sollten Sie zu Beginn des Workshops eine kurze Einführung in diese Art von Anforderungsbeschreibung machen.
Verstehen der Kundenanforderungen
Die Anforderungen des Kunden zu verstehen ist nicht immer einfach, denn oft redet der Kunde in Lösungen statt in Anforderungen.
Hier ein einfaches Beispiel: „Die Applikation muss eine Anmeldemaske haben“. Wie ich das sehe ist dies keine Anforderung. Eine Anforderung müsste (lösungsneutral) heißen: „Sicherstellen, dass nur autorisierte Personen die Applikation X ausführen können.“ Diese Anforderung kann auf verschiedene Arten gelöst werden, z. B. mit einem Login Screen, Single Sign-On, Fingerabdruckscanner usw.
Ein anderer wichtiger Punkt ist, zu verstehen WARUM der Kunde diese Anforderung hat. Dies um sicherzustellen, dass man nicht über Lösungen spricht, und um den Business Nutzen dahinter zu verstehen. Hier zwei Fragen, die Sie dem Kunden Stellen können: „Helfen Sie mir zu verstehen, warum dies für sie wichtig ist.“ Oder: „Was für einen Business-Nutzen erwarten Sie davon?“
Rangieren der Anforderung zum ersten Product Backlog
Am Schluss können Sie dann die Karten in der Form des Product Backlogs nach Business Value rangiert aufhängen. Hier kann auch das Minimum Marketable Feature Set (MMF) in Betracht kommen, welches eine minimale verkaufsfähige Lieferung darstellt.
Dies ist dann Ihre erste grobe Ansicht des Product Backlogs mit einer Rangierung, aber noch ohne Unterteilung in Iterationen (Sprints) und Releases. Diese Aufgabe erledigen Sie dann später mit dem Scrum-Team. Mehr darüber erfahren Sie hier (Artikel folgt).
Mit dem Anforderungsworkshop erhalten alle Beteiligten ein gemeinsames Verständnis der Ausgangslage und der Anforderungen an das Produkt. Dies stellt auch sicher, dass diese richtig beschrieben sind. Der Kunde, bzw. die verantwortlichen Fachbereiche können dann diese Anforderungen direkt am Workshop abnehmen, dann sind spätere Reviews überflüssig. Das Resultat des Meetings ist das initiale, abgenommene Product Backlog.
Den ersten Anforderungsworkshop wird der Product Owner möglichst vor dem ersten Sprint durchführen, damit für das erste Sprint Planning ein initiales, grob rangiertes Product Backlog vorhanden ist. Der Product Owner wird dann je nach Bedarf zu weiteren Workshops einladen, um fortlaufend neue Anforderungen zu erfassen und bestehende weiter zu detaillieren.
Bis wann sind die Anforderungen umgesetzt?
Der Kunde wird Sie sicher fragen, bis wann er welche Anforderung umgesetzt bekommt und was dies ungefähr kostet. Da müssen Sie Ihn auf einen weiteren Workshop/Meeting vertrösten, bei dem Sie ihn dies dann detailliert präsentieren können. Zuerst müssen Sie mit den Developern noch folgende Aktivitäten ausführen:
- Das Resultat des Workshops klären und detaillieren
- für die hoch priorisierten Anforderungen den Aufwand schätzen
- Das erste Product Backlog in Releases und Sprint aufteilen
Wie Sie in den letzten Abschnitten festgestellt haben hat das Anforderungsmanagement bei agilen Projekten einige wesentliche Unterschiede zu dem in traditionellen Projekten nach dem Wasserfall-Modell. Ein wesentliches Merkmal ist, dass zu Beginn des Projektes nicht alle Anforderungen für das gesamte Projekt lückenlose erfasst werden, sondern nur die wichtigsten und bereits bekannten und dies für die ersten Iterationen des Projektes. In diesem Artikel erfahren Sie, was die Merkmale guter Anforderungen bzw. User Stories sind und wie Sie dieses wirkungsvoll beschreiben.
Hier gibt es noch mehr Wissen
Wollen Sie mehr erfahren, wie Sie Ihre agilen Projekte noch erfolgreicher machen? Mein Buch Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden bringt Sie einen wichtigen Schritt weiter!
Kennen Sie jemanden, den dieser Beitrag auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn in Ihrem Netzwerk. Vielen Dank!
