Stakeholder-Management in agilen Projekten: Viele Wünsche, eine Reihenfolge

Stakeholder-Management in agilen Projekten heißt, Wünsche in einem Eingang zu sammeln, nach festen Kriterien zu bewerten und in genau eine Reihenfolge zu bringen, die eine Person verantwortet. Die Methoden dafür sind etabliert: Eine Stakeholder-Landkarte zeigt, wen Sie wie oft einbinden, ein Bewertungsmodell wie Weighted Shortest Job First ordnet die Anliegen, und ein fester Rhythmus aus Review und Veröffentlichung der Reihenfolge hält die Erwartungen im Rahmen.

Dieser Beitrag zeigt, wie Product Owner und Projektleiter mit konkurrierenden Anforderungen aus den Fachbereichen, von der Geschäftsführung und von Kunden umgehen. Er enthält ein Rechenbeispiel zur Priorisierung, ein Raster für die Einbindung und eine Prüfliste.

Warum wird Stakeholder-Management in agilen Projekten schwierig?

Es wird schwierig, weil agile Teams Anforderungen laufend annehmen und damit jedem Beteiligten die Möglichkeit geben, jederzeit etwas zu wünschen. In einem klassischen Projekt fließen Wünsche in die Anforderungsphase. In einem iterativen Projekt bleibt das Backlog offen, und jede Führungskraft und jeder Fachbereich schlägt Ergänzungen vor, gewöhnlich mit gutem Grund und dem Hinweis auf Dringlichkeit. Das Team gerät zwischen Wünsche, die sich nicht gleichzeitig erfüllen lassen, weil seine Kapazität begrenzt ist, wie der Beitrag zur Kapazitätsplanung in agilen Teams zeigt.

Der Scrum Guide 2020 löst den Konflikt über die Rolle des Product Owners: Er ist verantwortlich dafür, den Wert des Produkts zu maximieren, und er ist eine einzelne Person. Der Product Owner kann die Anliegen vieler Stakeholder im Product Backlog vertreten, und wer das Backlog ändern will, muss ihn überzeugen. Das Dokument sagt auch, dass die gesamte Organisation seine Entscheidungen respektieren muss. In vielen Mittelstandsprojekten steht diese Rolle nur auf dem Papier, weil die Geschäftsführung bei Bedarf direkt in das Team hineinregiert. Wie die Rolle ausgestaltet wird, beschreibt der Beitrag zum Product Owner im Mittelstand.

Wen müssen Sie wie einbinden?

Sie binden Stakeholder nach Einfluss und Interesse ein: Wer viel Einfluss und viel Interesse hat, wird eng gesteuert, wer viel Einfluss und wenig Interesse hat, zufriedengestellt, wer wenig Einfluss und viel Interesse hat, informiert, und wer beides kaum hat, beobachtet. Das Raster geht auf das Stakeholder-Konzept von Aubrey Mendelow zurück, das er 1981 auf einer Konferenz zu Informationssystemen vorstellte, und es zählt bis heute zu den verbreiteten Grundlagen für Stakeholder-Analysen. In der Lehre sind Macht und Interesse die üblichen Achsen.

Ein Raster ist eine Momentaufnahme. Einfluss und Interesse verändern sich mit dem Verlauf des Vorhabens, und die Landkarte gehört daher in jeden Rhythmus der Planung. Ein Beispiel: Ein Fachbereich ohne Interesse am Start wird zum wichtigsten Stakeholder, sobald seine Prozesse berührt werden. Wer die Landkarte nur einmal zu Projektbeginn zeichnet, übersieht diese Verschiebung.

Wie priorisiert man konkurrierende Anforderungen fair?

Fair priorisieren heißt, alle Anliegen mit denselben Kriterien zu bewerten und das Ergebnis offenzulegen. Ein verbreitetes Verfahren ist Weighted Shortest Job First (WSJF): Die Verzugskosten eines Anliegens werden durch seine Größe geteilt, und das Anliegen mit dem höchsten Ergebnis kommt zuerst. Das Verfahren geht auf Donald Reinertsen zurück, der 2009 in „The Principles of Product Development Flow“ begründete, dass die Verzugskosten geteilt durch die Dauer die richtige Größe für eine Reihenfolge sind. Die Zerlegung der Verzugskosten in Nutzen, Zeitkritikalität und Risikominderung stammt aus der verbreiteten Ausprägung im Scaled Agile Framework. Eine Einführung bietet der Beitrag zu den Cost of Delay.

Die Werte im Beispiel sind illustrativ. Sie werden relativ vergeben, üblicherweise auf einer Skala mit den Zahlen 1, 2, 3, 5, 8, 13, und die Vergabe erfolgt gemeinsam mit den Stakeholdern. Das Beispiel zeigt einen Effekt, der Diskussionen entschärft: Die Anfrage mit dem höchsten Nutzen, das Portal, landet auf dem letzten Platz, weil sie viel Aufwand bindet. Sie bleibt im Backlog und erhält eine nachvollziehbare Position, und der Stakeholder sieht, was passiert, wenn die Anfrage kleiner geschnitten wird. Das Verfahren liefert eine Diskussionsgrundlage. Wer es mechanisch anwendet, übersieht Abhängigkeiten zwischen Anfragen und schneidet sie nachträglich neu.

Wie sagt man Nein, ohne den Stakeholder zu verlieren?

Ein Nein hält, wenn es eine Begründung mit Kriterien und eine Perspektive enthält: Das Anliegen steht an Position vier, aus diesen Gründen, und rückt auf, wenn sich Nutzen oder Größe ändern. Die Begründung folgt aus der veröffentlichten Reihenfolge, die jeder Beteiligte einsehen kann. So wird aus einer Absage eine Information, über die sich sachlich verhandeln lässt.

Drei Gewohnheiten helfen dabei. Erstens gibt es einen einzigen Eingang für Anliegen, etwa ein Formular oder ein Board, und keine Abkürzung über Flurgespräche und E-Mails an Teammitglieder. Zweitens ist die Reihenfolge für alle einsehbar, mit Datum der letzten Änderung. Drittens gibt es einen Rückkanal: Im Review sehen die Stakeholder, was fertig ist, und können Anliegen neu begründen. Wie ein Review Entscheidungen statt Vorführungen erzeugt, beschreibt der Beitrag zum Sprint Review.

Prüfliste: Ist Ihr Stakeholder-Management belastbar?

Das Stakeholder-Management eines Projekts ist belastbar, wenn Sie die folgenden Fragen mit Ja beantworten.

1. Gibt es eine Stakeholder-Landkarte, die in jedem Planungsrhythmus überprüft wird?
2. Ist genau eine Person für die Reihenfolge des Backlogs verantwortlich, mit Rückhalt der Geschäftsführung?
3. Gibt es einen einzigen Eingang für Anliegen?
4. Werden alle Anliegen nach denselben Kriterien bewertet, und ist die Bewertung einsehbar?
5. Ist festgelegt, wer entscheidet, wenn zwei Bereiche denselben Platz in der Reihenfolge beanspruchen?
6. Kennen die Stakeholder den Termin des nächsten Reviews, und nehmen die Entscheider daran teil?
7. Erhält jedes abgelehnte oder verschobene Anliegen eine Begründung mit Perspektive?
8. Zeigt eine Kennzahl, wie viel Arbeit außerhalb der Reihenfolge am Team vorbei eingeschleust wird?