Vom Business Model Canvas zum Backlog

Stellen Sie sich vor, Sie sind ein Product Owner in einer kleinen bis mittelgroßen Organisation und beginnen mit einem neuen Projekt. Der Product Owner ist eine wichtige Rolle im agilen Kontext. Er ist die Brücke zwischen den Unternehmenszielen, die eine Organisation verfolgt, und dem Scrum Entwicklungsteam, die diese umsetzt. Er ist die Schnittstelle, von der die Organisation abhängig ist, um Wertströme zu generieren. Für Kunden erzeugt er maximalen Nutzen, indem er das Product Backlog sein eigen macht und entsprechend priorisiert.

Wie gehen Sie nun als Product Owner vor, wenn Sie das Backlog erstmals mit Inhalten füllen wollen? Wie und wo fangen Sie an? In der Praxis haben sich einige Praktiken bewährt:

1. Handelt es sich um ein kleines Projekt, lassen sich aus den Projektzielen Backlog Items ableiten. Damit dies gelingt, ist es wichtig, dass der Product Owner ein gutes Verständnis der Ziele gewinnt und die Ziele mit den Stakeholdern thematisiert. In der Folge bespricht er seine Erkenntnisse und die initialen Backlog Items mit den Stakeholdern. Diese Praxis folgt einem heuristischen Ansatz.
2. Das Backlog wird von älteren Projekten übernommen oder extrahiert. In diesem Fall muss der Product Owner nur von Fall zu Fall eine erneute Priorisierung vornehmen. Dieser Prozess basiert auf Erfahrung.
3. Der Product Owner tauscht sich mit Fachexperten und Business Analysten aus und erstellt das Backlog. Normalerweise führt er getrennte Gespräche mit Unternehmensvertretern, Analysten und anderen Stakeholdern. So erhält er schrittweise ein gutes Verständnis über die Ziele des Vorhabens und erzeugt ein Backlog, das er im Anschluss mit dem Scrum Entwicklungsteam bespricht.
4. Auch gemeinsam lässt sich ein initiales Backlog erzeugen: im Zuge eines Anforderungsworkshops bringt der Product Owner Stakeholder und erfahrene Teammitglieder für 4-8 Stunden zum Dialog zusammen. Die Erkenntnisse werden später Gegenstand im Sprint Planning.

Abhängig von der Größe und dem Umfang des Projekts wählt der Product Owner eine passende Praktik für die Gestaltung des initialen Produkt-Backlogs aus. Welche würden Sie nutzen?

Die Business Model Generation

Als Scrum Master bin ich immer auf der Suche nach neuen Methoden und Prozessen, die ich in Projekten nutzen kann. Vor kurzem bin ich beim Coaching eines Startups auf einen Ansatz gestoßen, mit dem Product Owner ein initiales Backlog erstellen können. Gerne möchte ich den Ansatz im Folgenden beschreiben.

Beginnen möchte ich mit der Erstellung des Business Model Canvas, wie es im Buch “Business Model Generation” von Alexander Osterwalder & Yves Pigneur beschrieben wird. Einfach ausgedrückt: für jedes Business Model gibt es neun Bausteine:

• Customer Segment (Kundensegmentierung)
• Value Proposition (Werteversprechen)
• Channels (Kanäle)
• Customer Relationship (Kundenbeziehung)
• Revenue Stream (Einnahmequellen)
• Key Resources (Schlüsselressourcen)
• Key Activities (Schlüsselaktivitäten)
• Key Partnerships (Zentrale Partnerschaften)
• Cost Structure (Kostenstruktur)

Jeder Baustein wirkt wie ein Zahnrad in einem Gefüge. Um ein erfolgreiches Gesamtmodell zu erzeugen, wird jeder der neun Bausteine benötigt. Idealerweise sollten die Bausteine in der genannten Reihenfolge diskutiert werden. Da eine ausführliche Diskussion über die Inhalte oder die Vor- und Nachteile des Modells den Rahmen des Beitrags sprengen würde, möchte ich mich auf auf das initiale Backlog konzentrieren, das der Product Owner mit Hilfe des Business Model Canvas erstellen und priorisieren kann.

Die Implementierung des Business Model Canvas

Insbesondere für den Product Owner sind einige Bausteine – Customer Segment, Value Proposition, Channels, Customer Relationship sowie Key Activities – besonders interessant. Auf diese möchte ich nun im Detail eingehen:

Customer Segment

Bei der Kundensegmentierung geht es um die Identifikation der wichtigsten Kunden und das Gruppieren von Kunden nach definierten Kriterien. Das Ergebnis ist abhängig von der Fähigkeit, Kunden über definierte Kanäle anzusprechen und ihnen ähnliche Werte zu offerieren. Für den Product Owner bedeutet dies, ein klares Bild über die Zielgruppe zu gewinnen, für die eine Lösung entwickelt wird. Diese Klarheit hilft später auch dem Entwicklungsteam beim Sprint Planning.

Werfen wir ein Blick auf ein praktisches Beispiel:

Ein Startup hat erste Überlegungen zu einem primären Kundensegment angestellt. Nun findet ein Business Modell Generation Meeting statt. Die Frage, ob sich die Kundenbasis durch die Einbeziehung von B2C-Kunden erweitern lässt, steht im Raum. Folgender Dialog entsteht:

Peter: “Bis zum heutigen Tag haben wir lediglich das B2B-Kundensegment im Blick. Wir verkaufen eine Sicherheitslösung inklusive Kameras und einer Managementsoftware lediglich an andere Unternehmen. Könnten wir nicht auch den Endverbraucher aktiv als Segment kultivieren?”

Stan: “Das könnten wir sicher tun, zumal unser Produkt auch für diesen Kundenkreis interessant wäre. Vielleicht müssten wir aber unsere Vertriebs- und Kommunikationskanäle anpassen und somit auch unsere Kundenbeziehungen überdenken.”

Peter: “Nicht nur das, auch der Nutzen unserer Lösung könnte für diesen Kundenstamm ein anderer sein. Dennoch steht die Frage im Raum, ob wir dieses interessante Kundensegment vernachlässigen wollen? Ich schlage vor, das neue Kundensegment in unsere Betrachtung mit aufzunehmen. So können wir auch schauen, welche Erkenntnisse sich durch die Betrachtung weiterer Bausteine ergibt.”

Durch die Anpassung der Kundensegmentierung ergeben sich mit großer Wahrscheinlichkeit neue Backlog Items; dies sollte der Product Owner entsprechend im Blick behalten.

Value Proposition

Meiner Meinung nach ist die Value Proposition für den Product Owner das wichtigste Segment im Business Model Canvas. Hier dreht sich alles um die Werte und den Nutzen, die der Hersteller einer Lösung seinen Kunden bieten möchte. Die Ziele und die Werte der Organisation gehen Hand in Hand. Zudem können die Stakeholder den Erfolg des Vorhabens durch die Anpassung des konkreten Wertversprechens bestimmen. Dies hat den Vorteil für den Product Owner, dass er daraus direkt Epics für das initiale Backlog ableiten kann.

Werfen wir wieder einen Blick auf unser Beispiel:

Stan: “Da wir zwei unterschiedliche Kundensegmente ansprechen, ändert sich eventuell der jeweilige Nutzen. Was ist der zentrale Wert, den wir unseren Einzelhandelskunden bieten?” Nina: “Unsere Lösung ist innovativ. Wir bieten den Kunden die Möglichkeit, alle übermittelten Kamerabilder in einer gemeinsamen Sicht der Managementsoftware zu sehen.”

Peter: “Unsere Lösung ist vor allem wirtschaftlich sinnvoll, denn mit einem günstigen Leasingangebot muss der Kunde keine Hardware kaufen.”

Sandra: “Liegt der größte Nutzen für unsere Kunden nicht in der Einfachheit der Anwendung? Der Kunde muss schließlich nichts einrichten oder selbst konfigurieren, zumal unsere Lösung auf allen gängigen Plattformen läuft.”

Stan: “Und was machen wir mit dem zweiten Kundensegment, den Endanwendern? Wie unterstützen wir die? Wie können wir Werte liefern, ohne eine angemessene Kundenbetreuung zu bieten?

Peter: “Das können wir leider nicht leisten. Es wäre viel zu aufwändig und teuer. Vielleicht müssen wir unsere Kundensegmentierung nochmals überdenken?”

Nina: “Das klingt sehr gut für mich. Wir bieten einen Support für Großkunden an und schauen, wie dies funktioniert. Damit haben wir zwei Segmente für Einzelhandelskunden, die sich in der Größe unterscheiden.”

Sandra: “Um die Werte zusammenzufassen, die wir Segment ‘große Einzelhandelskunden’ bieten: Ein innovatives Produkt, das sich wirtschaftlich betreiben lässt, in der Anwendung und Einrichtung sehr leicht funktioniert und für das wir Support anbieten.”

Können Sie sich vorstellen, dass ein Product Owner aus dieser Value Proposition Epics ableitet? Natürlich ist dies lediglich ein einfaches Beispiel, mit dem ich die Vorgehensweise demonstrieren möchte. Im realen Leben werden mehrere Iterationen auf dem Weg zur Value Proposition und somit auch in der Folge für die Ableitung von Epics durchlaufen.

Channels

Was tut der Kunden, um das Produkt und/oder die Dienstleistung zu kaufen? Für Hersteller ist es eine wichtige Aufgabe, Vertriebs- und Kommunikationskanäle zu verstehen, zu betreiben und ggf. zu entwickeln. Hier entscheidet sich, ob bspw. ein neuer Online-Shop benötigt wird, der ggf. vom Entwicklungsteam implementiert werden muss, so dass Kunden den Zugang zum Produkt per Knopfdruck erhalten. Die Auseinandersetzung mit den Channels bietet für den Product Owner die Gelegenheit, weitere Epics abzuleiten.

Werfen wir nochmals einen Blick auf unser Beispiel:

Peter: “Können unsere Einzelhandelskunden unsere Produkte über die ‘E-Com-Plattform’ erwerben? Oder eröffnen wir einen neuen Online-Shop? Evtl. könnten wir unser Produkte auch stationär im Einzelhandel anbieten.”

Stan: “Die Platzierung unserer Hardware im Einzelhandel kostet uns viel Geld, das wir derzeit nicht haben.”

Nina: “Außerdem könnten wir über einen Online-Shop leichter Upgrades verkaufen bzw. dann entsprechend auch per Mail und Download-Link ausliefern.”

Sandra: “Dann benötigen wir aber auch Erinnerungsfunktionen, standardisierte Benachrichtigungen und eine Sicherung, dass die Upgrades nur für den befugten Anwender funktionieren.”

Auch aus diesen Antworten kann der Product Owner weitere Epics ableiten.

Customer Relationship

Unternehmen wollen positive Beziehungen zu aktuellen Kunden aufrechterhalten und neue Kunden gewinnen. Auch aus den Fragen, die sich aus bestehenden Kundenbeziehungen und der Gewinnung neuer Kunden ergeben, kann der Product Owner weitere Backlog Items extrahieren.

In unserem Beispiel entwickelt sich folgende Diskussion:

Peter: “Können wir die Kosten reduzieren und gleichzeitig die gute Beziehung zu Bestandskunden aufrechterhalten? Wenn ich an den Support für unser Segment ‘große Einzelhandelskunden’ denke, ist es wichtig, die Kosten im Blick zu behalten.”

Sandra: “Nach meiner Erfahrung arbeiten die meisten Kunden mit “How To” -Hilfestellungen. Wir könnten Tutorials entwickeln und so die Anwender von Anfang an unterstützen. Das ist zwar aufwändig, wird aber die Anzahl der späteren Anfragen deutlich reduzieren.”

Nina: “Wir könnten auch Videos mit Anleitungen produzieren.” Sandra: “Genau.” Peter: “Die helfen aber leider nicht, wenn unsere Geräte versagen, oder?”

Stan: “Wir benötigen auf jeden Fall eine absolut strenge Qualitätskontrolle. Vielleicht stellen wir den Support erst zu einem späteren Zeitpunkt zur Verfügung, aber bei der Qualität können wir keinerlei Abstriche machen.”

Vielleicht geht es Ihnen wie mir, denn mir springen sofort einige nicht-funktionale Anforderungen und Spike Storys ins Auge. Darum sollte es an dieser Stelle noch nicht gehen. Behalten Sie die Epics im Blick.

Key Activities

Was sind die wichtigsten Aktivitäten, um dieses Geschäftsmodell zu verwirklichen? Umfasst es Aktivitäten auf Produktions- / Betriebsebene? Wenn ja, welche Änderungen sind im laufenden Betrieb vorgesehen? Wird eine neue Plattform benötigt, über die sich die Produkte leichter monetarisieren lassen? Wird ein Abonnenten-Modell auf API-Ebene erstellt? Wird sich das API-Management in diesem Fall zur Hauptaktivität entwickeln? Solche Fragen helfen dem Product Owner bei der Ermittlung weiterer und der Verfeinerung bestehender Backlog Items.

Werfen wir einen letzten Blick auf unser Beispiel:

Peter: “Unsere E-Com Plattform ist unabhängig vom Kundensegment unser wichtigstes Kapital.”

Stan: “Richtig. Sie ist skalierbar und kann sowohl große und kleinere Einzelhändler bedienen.”

Sandra: “Hat sich denn durch unser neues Kundensegment unsere wichtigste Tätigkeit verändert?”

Peter: “Ich glaube nicht, denn unsere Hauptaktivität besteht weiterhin darin, sicherzustellen, dass unsere Plattform als Service mit einwandfreier Qualität erhalten bleibt. Nebentätigkeiten betreffen die Kundenbetreuung.”

Nina: “Darüber hinaus ist aber Offenheit ein weiterer Aspekt unserer Plattform und muss auch beibehalten werden.”

Peter: “Ja, auch das gehört zu unserer Kernaktivität.”

Sandra: “Daher können wir die wichtigsten Aktivitäten auf hoher Ebene ermitteln. In erster Linie ist es eine offene und qualitativ hochwertige Plattform, die einen Service bietet. Zu den sekundären Aktivitäten gehören die für die Kundenbetreuung erforderlichen Aktivitäten. Jetzt lasst uns ins Detail gehen …”

Aus einem solchen Gespräch lassen sich viele Punkte ableiten, die das initiale Backlog und seine Elemente ergänzen und abrunden. Als Ergebnis erhalten Sie eine Mischung aus funktionsfähigen Backlog Items sowie Aktivatoren / Spikes.

Fazit

Durch das beschriebene Vorgehen hat der Product Owner viel Input für sein initiales Backlog erhalten. Dieses sollte nun von allen Teilnehmern überprüft werden, denn dadurch ergeben sich weitere Erkenntnisse u.a. über die Eignung der identifizierten Backlog Items. Jetzt ist auch ein guter Zeitpunkt, um die relative Priorisierung in Angriff zu nehmen. Eine Priorisierung bereits im Laufe der verschiedenen Gespräche durchzuführen, ist nicht zweckmäßig, denn erst wenn das Business Model Canvas vollständig beschrieben ist kann ein Abgleich mit den Unternehmenszielen und -werten erfolgen. Und was passiert als nächstes? Der Product Owner nimmt das Backlog mit in das erste Meeting mit dem Scrum Entwicklungsteam, so dass sich die Teammitglieder mit den Inhalten auseinandersetzen können.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Der Beitrag von Saugata Das ist im Original unter https://www.saugatadas.net/scrummasterblog/5-effective-steps-for-initial-product-backlog-creation-using-business-model-canvas erschienen. Mit Zustimmung von Saugata Das übersetzen wir verschiedene Beiträge von ihm hier in unserem Blog vom Englischen ins Deutsche. Beiträge im Original finden Sie unter https://www.saugatadas.net/scrummasterblog/. In LinkedIn können Sie sich mit ihm unter www.linkedin.com/in/withsaugata vernetzen.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.