Scrum Produktmanagement: Der vollständige Leitfaden + Beispiele
Scrum ist im Bereich Produktmanagement nichts Neues. Die meisten von uns nutzen Scrum in ihren Unternehmen und versuchen, die Rollen und Prinzipien dieses Frameworks zu navigieren, um unsere Ziele zu erreichen.
Leider interpretieren Unternehmen die Prinzipien von Scrum häufig falsch und wenden sie nicht richtig an. Dadurch bleiben den Nutzern viele Vorteile von Scrum verwehrt.
Dieser schöne kleine Leitfaden soll dir helfen, dieses Framework besser zu nutzen, indem er erklärt, worum es dabei geht, warum es verschiedene Scrum-Rollen gibt, welche Verantwortlichkeiten im Produktmanagement bestehen und wie du in der bereichsübergreifenden Zusammenarbeit glänzt.
Du willst mehr vom The CPO Club?
Registriere dich für eine kostenlose Mitgliedschaft, um diesen Artikel vollständig zu lesen:
Have an account? Log In
Was ist Scrum im Produktmanagement?
Viele von uns diskutieren gerne die Rolle eines Product Managers im Kontext von Scrum-Prozessen und der agilen Methodik (anders gesagt: was ein PM in einem Scrum-Team macht). Anstatt das nur zu erklären, finde ich es einfacher, einfach zu zeigen, wo sich der PM im Organigramm des Teams befindet.
In diesem Leitfaden möchte ich das Thema jedoch aus der entgegengesetzten Richtung angehen und zeigen, wie Scrum in deiner Realität als Produktmanagement-Profi passt und wie es dir dabei hilft, deine Produktziele zu erreichen.
Ich möchte damit beginnen, die Auswirkungen der Grundprinzipien des Scrum-Frameworks auf die Effektivität unserer Arbeit zu beleuchten.
Wahrscheinlich ist das wertvollste Scrum-Prinzip für uns die kontinuierliche Wertlieferung an die Nutzer. Je schneller Menschen Probleme lösen können, desto besser wird sich dein Produkt entwickeln. Außerdem erhältst du frühzeitiges Feedback von Personen, die das Feature in einem realen Szenario ausprobiert haben.
Der zweite Vorteil von Scrum ist die Flexibilität. Wenn sich die Marktrealität verändert, kannst du schnell reagieren, indem du dein Product Backlog komplett umstrukturierst und dem Team in der nächsten Iteration neue Features übergibst (hier kann KI in der Sprint-Planung unterstützen).
Diese beiden Vorteile sind bei traditionellen Frameworks wie dem Wasserfallmodell schwer oder beinahe unmöglich zu realisieren. Hier ist alles im Vorfeld festgelegt, und die Nutzer greifen erst am Ende des SDLC auf das Produkt zu.
Beispiele für Produkterfolg dank Scrum-Integration
Nachdem ich jahrelang mit Scrum-Teams gearbeitet habe, bin ich natürlich voreingenommen gegenüber diesem agilen Framework. Verlass dich deshalb nicht nur auf mich. Schauen wir uns reale Fälle an, in denen der Wechsel zu Scrum Produktteams schneller zum Erfolg verhalf.
Microsoft Visual Studio: Das wichtigste Code-Editor-Tool des IT-Riesen war berüchtigt für seine wiederkehrenden Produktionskrisen, fehlerhafte Releases und extrem seltene Veröffentlichungen. Seit das Produktteam Scrum einsetzt, verzeichnet das Unternehmen deutlich stabilere Produkte und viel häufigere Release-Zyklen – und gewann so seine Wettbewerbsfähigkeit am Markt zurück.
Spotify: Unser beliebter Musikstreaming-Dienst ist eines der bekanntesten Beispiele für Scrum in der Praxis. Spotify konnte sich lange nicht schnell genug anpassen und skalieren, um Herausforderungen im Prozess zu meistern...bis das Unternehmen Scrum übernahm. Was Spotify auszeichnet: Sie entwickelten ihr eigenes Scrum-Projektmanagementmodell, das auf autonome agile Teams setzte, denen jegliche Expertise zur Verfügung stand, um Experimente umzusetzen und Nutzerfeedback unmittelbar einzubinden.
ING: Die niederländische Großbank gehörte zu den ersten Finanzinstituten, die erkannten, dass die Zukunft des Bankwesens digital ist. Sie stellten auch fest, dass ihre traditionellen Projektmanagement-Prozesse für Softwareentwicklung nicht taugten. Also setzten sie konsequent auf Lean- und Scrum-Methodik und wurden – wenig überraschend – Marktführer im E-Banking.
Schlüsselrollen im Scrum-Produktmanagement
Wenn du als PM entscheidest, dass Scrum der richtige Ansatz ist, findest du hier einen schnellen Überblick über die Schlüsselrollen in diesem Framework. Damit kannst du deine Rolle als Product Manager von der des Scrum Product Owners unterscheiden.
Lass mich mit den Rollen anfangen. Ein typisches Scrum-Team besteht aus folgenden Personen:
- Scrum Master: Diese Person hilft dem Team, die Scrum-Regeln einzuhalten und die Abläufe zu optimieren.
- Product Owner: Diese Rolle vertritt das Unternehmen und die Nutzer im Scrum-Team. POs besitzen das Backlog und legen die Ziele und Prioritäten für die Sprints fest.
- Scrum-Team: Ihre Entwickler, Designer, QAs und andere Spezialisten, die das Produkt entwickeln.
Bezüglich des Scrum-Teams können dort viele verschiedene Spezialisten arbeiten. Das Konzept der cross-funktionalen Teams geht davon aus, dass das Team eigenständig und mit allen nötigen Kompetenzen ausgestattet ist. Wenn Ihr Produkt zum Beispiel einen starken Fokus auf Analysen hat, kann dem Team auch ein Datenanalyst angehören.
Product Manager vs. Product Owner: Was ist der Unterschied?
Die von mir angegebene Definition des Product Owners kann etwas verwirrend sein, da sie sehr ähnlich klingt wie die typische Arbeit eines Product Managers.
Was ist also der Unterschied zwischen Product Manager und Product Owner?
Um den Unterschied zu verstehen, schauen wir uns zunächst die Kernaufgaben jedes Einzelnen an.
Product Manager
- Führen Produktentdeckung durch und verstehen die Bedürfnisse und Probleme der Kunden.
- Definieren die Produktvision und die Richtung, der das Team folgen wird.
- Entwickeln Produktlösungen, die den Kundenbedürfnissen entsprechen.
- Leiten den Prozess der Produktbereitstellung.
- Verfeinern das Produkt in kleinen Schritten auf Basis von Kundenfeedback und datengetriebener Entscheidungsfindung.
- Verwalten die Produktvision und deren Umsetzung im ganzen Unternehmen.
Product Owner
- Erstellung und Pflege des Product Backlogs.
- Dient als alleinige Quelle für Strategie, Design und Geschäftslogik für das Scrum-Team.
- Priorisiert die Einträge im Product Backlog und sorgt für Klarheit bezüglich der wichtigsten Punkte für das Team.
- Definiert Akzeptanzkriterien für Features und nimmt die Sprint-Ergebnisse anhand dieser Kriterien ab.
- Beseitigt Blockaden für Teammitglieder, indem Anforderungen geklärt und damit verbundene Probleme gelöst werden.
- Nimmt an Scrum-Events teil und agiert als Stimme des Geschäfts und der Kunden im Team.
Wie wir sehen, gibt es viele Aufgaben, die in beiden Listen auftauchen. Das ist ganz normal, denn viele Personen nehmen gleichzeitig Aufgaben als Product Manager und Product Owner wahr.
Der wesentliche Unterschied zwischen den beiden ist, dass Produktmanagement ein Beruf und eine Kompetenz ist, während Product Ownership eine Rolle im Scrum-Team darstellt.
Aber was bedeutet das?
Das bedeutet, dass ein Product Owner kein Product Manager sein muss. In einem kleinen Startup, in dem es einen CEO und drei Entwickler gibt, übernimmt der CEO die Rolle des Product Owners, indem er den Entwicklern ein priorisiertes Backlog liefert.
Auch die umgekehrte Situation ist möglich: Sie können Product Manager sein, ohne Product Owner zu sein. Ich bin ein gutes Beispiel, denn eines meiner früheren Teams arbeitete nicht mit Scrum. Kein Scrum, also kein Product Owner im Team. Wir folgten jedoch Lean- und Agile-Prinzipien.
Um den Unterschied zwischen diesen beiden Rollen noch deutlicher zu machen, finden Sie hier einen direkten Vergleich ihrer Tätigkeiten.
Aber was war überhaupt der Sinn, eine spezielle Rolle im Scrum-Team zu schaffen? Hätten sie nicht einfach mit Produktmanagern zusammenarbeiten können, die nicht Teil des Teams sind? Ich mag die Antwort von Teresa Torres dazu sehr.
Der Hauptgrund, warum es eine spezielle Produktrolle im Scrum-Team gibt, ist, internes Produktwissen und Expertise einzubringen und die Cross-Funktionalität des Teams weiter zu verstärken.
Wie der Product Manager mit Scrum-Teams zusammenarbeitet
Angenommen, Sie entscheiden sich für den Scrum-Weg, dann sollten Sie wissen, wie Sie ein Teammitglied werden und mit Ihren Kollegen zusammenarbeiten können. Nachfolgend gebe ich Ihnen einen kurzen Überblick zu jedem Scrum-Event und Artefakt.
- Tägliches Scrum (auch als Stand-ups bezeichnet): Die wichtigste Arbeit, die Sie während dieser zeitlich begrenzten Meetings leisten, besteht darin, die produktbezogenen Fragen Ihres Entwicklungsteams zu beantworten und Hindernisse aus dem Weg zu räumen.
- Sprint-Planungsmeeting: Hier sind Sie die Person, die das Ziel des Sprints festlegt, indem Sie Ihre Erwartungen hinsichtlich der Features, die Sie liefern wollen, klar definieren.
- Sprint-Retrospektive: Die Prozesse, mit denen Sie dem Team Prioritäten und Anforderungen vermitteln, können darüber entscheiden, wie effektiv sie arbeiten. Nutzen Sie also dieses Meeting, um Feedback vom Team einzuholen und Ihre Prozesse zu verbessern.
- Sprint-Review: Ihre Aufgabe ist es hier, die abgeschlossenen Features des Sprints abzunehmen und dem Team Rückmeldung zu ihrer Arbeit zu geben.
- Produkt-Refinement (auch Grooming genannt): Sie sind für dieses Meeting verantwortlich und sollten die Ihnen zugewiesene Zeit nutzen, um die Prioritäten und Details der User Stories zu besprechen, die Sie für das Team vorgesehen haben. Ermutigen Sie das Team stets, Ihre Anforderungen zu hinterfragen und „Produkt-Bugs“ zu finden, die Sie übersehen haben.
- Product Backlog: Es ist Ihre Aufgabe, das Product Backlog zu verwalten und ordentlich sowie priorisiert zu halten, da das Team den Sprint darauf aufbaut.
- Sprint Backlog: Dies gehört nicht Ihnen. Ihre wichtigste Schnittstelle hierbei ist es, das Team dazu zu führen, die richtigen Stories ins Sprint Backlog zu übernehmen, damit sie Ihr Sprintziel erreichen können.
Abgesehen davon übernehmen Sie auch andere Aufgaben im Produktmanagement, wie Stakeholder-Management oder Product Discovery. Als Mitglied des Scrum-Teams ist es Ihre Aufgabe, das Team nach Klärung über die Bedürfnisse von Stakeholdern und Nutzern auf dem Laufenden zu halten.
Wenn Sie beispielsweise mit einem Nutzer ein Interview führen und herausfinden, dass der Login-Prozess in der Nutzung allgemein verwirrend ist, ist es wichtig, diese Information mit dem Team zu teilen, damit darauf in zukünftigen Sprints geachtet wird.
Best Practices für Scrum-Produktmanagement
Produktmanagement scheint im Rahmen von Scrum (und agiler Entwicklung insgesamt) einfach zu sein, doch es gibt zahlreiche Fehler, die wir in unseren selbstorganisierenden Teams häufig machen.
Hier finden Sie daher einige Scrum-Best-Practices, die Ihnen helfen, diese zu vermeiden:
- Klare Erwartungen setzen: Der größte Fehler besteht darin, Ihrem Team vage Prioritäten und Anforderungen zu geben. Fehlende Klarheit ist eine Hauptursache für Entwicklungsverzögerungen und Spannungen zwischen Ihnen und dem Team. Wir gehen gleich näher darauf ein, wie Sie dies erreichen können.
- Anpassungsfähigkeit nicht überstrapazieren: Die Möglichkeit, den Kurs zu ändern, ist wichtig – aber das gilt nur für das Product Backlog, nicht das Sprint Backlog. Sobald der Sprint begonnen hat, fügen Sie bitte keine weiteren Stories hinzu oder entfernen Sie keine mehr. Das bringt die Pläne und Fortschritte Ihres Teams durcheinander und führt zu unvollendeten Sprints.
- Ein emotional sicheres Umfeld schaffen: Sie sind ein Mitglied des Teams, nicht der Chef. Setzen Sie das Team also nicht unter Druck, größere Zusagen zu machen oder früher fertig zu werden. Scrum Guides – unter anderem von Scrum.org – betonen immer wieder, wie wichtig eine gesunde Beziehung mit Ihren Teammitgliedern ist, da diese eine Grundvoraussetzung für effektive Teamarbeit ist.
Diese drei Best Practices sind meiner Erfahrung nach die wichtigsten. Wenn Sie jedoch noch mehr Tipps zu agilen Arbeitsweisen und Scrum-Best-Practices für Produktmanager suchen, schauen Sie unbedingt in unseren separaten Ratgeber zu Agile Product Management.
Das Product Backlog effektiv verwalten
Wie bereits erwähnt, ist es eine der wichtigsten Aufgaben eines Produktmanagers, dem Team Klarheit zu verschaffen. Die gute Nachricht: Ihr Product Backlog ist vermutlich das beste Werkzeug, um dies zu erreichen. Hier daher einige Tipps zum Managen des Product Backlogs:
Groomings: So gut Sie User Stories auch schreiben, Sie werden dort immer "Bugs" hinterlassen – und möchten, dass Ihr Entwicklungsteam diese findet und Sie darauf hinweist. Zudem sind Sie selbst nicht Entwickler und schreiben vielleicht Anforderungen, die schwer umzusetzen sind. Auch darauf wird Ihr Team Sie beim Grooming-Prozess aufmerksam machen.
Priorisierungstechniken: Nutzen Sie die zahlreichen Priorisierungsmodelle, um zu verstehen, welche Features wichtiger sind als andere. Mein persönlicher Favorit ist MoSCoW – wegen seiner Einfachheit.
Abgleich mit Roadmap und Vision: Die Epics und Stories in Ihrem Backlog sollten die übergeordneten Produktziele und Metriken widerspiegeln, die Sie erreichen möchten. Überprüfen Sie bei Änderungen im Backlog deshalb regelmäßig Ihre Roadmap.
Das offensichtlichste Zeichen dafür, dass einer Organisation die Klarheit fehlt, zeigt sich, wenn Sie sich in der Organisation umhören und unterschiedliche Personen dazu befragen, was ihrer Meinung nach die Erfolgskriterien für den nächsten großen Meilenstein sind, und plötzlich hören Sie ganz verschiedene Ansichten.
Abstimmung der Stakeholder im Scrum
Das Wesentliche an der Rolle eines Product Managers im Scrum ist, dass Sie im Grunde das verbindende Glied zwischen dem selbstorganisierten Team und der Außenwelt sind – seien es Nutzer, Stakeholder oder andere Teams.
Abgesehen davon, dass Sie als PM die üblichen Aufgaben im Stakeholder-Management übernehmen, müssen Sie diese Informationen auch an Ihr Team weitergeben und umgekehrt. Es wird zudem Situationen geben, in denen Sie Informationen vom Team an die Stakeholder weiterleiten müssen.
Ein gutes Beispiel hierfür ist das Auftreten technischer Herausforderungen, wie etwa Probleme bei der kontinuierlichen Integration, die den Zeitplan oder den Umfang eines bestimmten Features beeinflussen können. Dies ist ein Thema, das Sie mit den Stakeholdern besprechen sollten, um entweder den neuen Zeitplan/Umfang zu akzeptieren oder eine andere Lösung zu finden (z. B. durch die Verstärkung des Teams mit mehr Expertise zu diesem Thema).
Es gibt auch Fälle, in denen Ihr Team eine interessante Idee für ein Feature oder eine Lösung entwickelt hat, die es wert ist, in die Roadmap aufgenommen zu werden. Auch hier geben Sie diese Information an die Stakeholder weiter und entscheiden gemeinsam, ob sie in den Plan aufgenommen wird oder nicht.
Die Bedeutung agiler Roadmaps im Scrum
Auch wenn sie nicht direkt Teil von Scrum sind, gehören agile Roadmaps zu den Werkzeugen, die Scrum erst ermöglichen. Schließlich: Was nützt eine iterative Planung, wenn Sie für Ihr Produkt das Wasserfall-Modell anstelle einer agilen Roadmap verwenden?
In diesem Fall würde das, was Sie Strategie für Ihr Scrum-Produkt nennen, darin bestehen, einen vordefinierten und festen Plan mit klassischem SDLC in 2-wöchige (oder wie lang Ihre Sprints auch immer sind) Teile aufzuteilen. Damit Scrum für Ihr Team sinnvoll ist, müssen Sie also agile, interaktive Planung betreiben und eine Roadmap erstellen, die im Laufe der Zeit anpassbar ist.
Um Ihre agile Roadmap richtig mit den Scrum-Prozessen Ihres Teams zu verbinden, empfehle ich Ihnen folgendes Vorgehen:
- Verknüpfen Sie Roadmap-Elemente (meistens Epics) mit User Stories im Product Backlog. Auf diese Weise besteht eine direkte Verbindung zwischen Ihrem taktischen Arbeiten (Stories) und Ihrer strategischen Ausrichtung (Roadmap).
- Präsentieren Sie Ihre Roadmap dem Scrum-Team. So wissen alle, wohin das Produkt gehen soll, und können zukünftige Features bei der Gestaltung der Frontend- oder Backend-Architektur berücksichtigen.
- Nutzen Sie spezialisierte Tools wie Jira, Monday.com und Clickup, um Ihren Roadmapping- und Backlog-Management-Prozess zu optimieren.
Zu diesem letzten Punkt: Diese drei Tools habe ich in der Praxis verwendet. Es gibt jedoch viele weitere Produktmanagement-Tools, die Sie alternativ nutzen können.
Herausforderungen im Scrum-Produktmanagement
Obwohl Scrum ein hervorragendes Framework für die Erreichung Ihrer Produktziele ist, bringt die Nutzung dieses Frameworks eine eigene Reihe von Herausforderungen mit sich, wie zum Beispiel:
- Ihr Team oder Ihre Stakeholder verstehen möglicherweise nicht, worum es bei Scrum geht. Das kann natürlich zu erheblichen Problemen bei der Einführung von Scrum führen, etwa wenn bestimmte Artefakte abgelehnt werden. Ich empfehle, dem zuvorzukommen, indem Sie veranschaulichen, wie der gewünschte 'Endzustand' aussieht, wenn das Framework vollständig eingeführt ist – wie Team und Arbeitsablauf dann ablaufen.
- Menschen (und Sie selbst) können über Ihre Rolle im Team und außerhalb des Teams verwirrt sein. Jedes Unternehmen, für das ich in meiner Laufbahn gearbeitet habe, hatte sein eigenes Verständnis davon, was ein Scrum-PO ist. Es ist am besten, für Ihr Team klar zu definieren, was diese Rolle ist – und was nicht.
- Der Umfang der von Ihnen bearbeiteten Features neigt dazu, sich endlos zu erweitern. Wenig überraschend ist es dadurch sehr leicht, beim sogenannten "Scope Creep" zu landen. Scrum-Teams müssen kompromisslos darin sein, was sie übernehmen – und wozu sie "Nein" sagen.
- Die Roadmap kann leicht aus dem Ruder laufen. Da das relativ unabhängige Team oft selbst entscheiden kann, woran gearbeitet wird, kann es passieren, dass Dinge umgesetzt werden, die nicht auf Ihrer Roadmap stehen. Das übergeordnete Ziel stets klar im Fokus zu behalten, ist entscheidend, um dieses Problem zu vermeiden.
Auch wenn diese Herausforderungen recht häufig sind, ist das Gute daran, dass der PM nach nur wenigen Sprints den Scrum-Prozess versteht und die meisten Schwierigkeiten überwinden kann. Wer seine Expertise formalisieren möchte, kann durch das Lernen wie man Scrum Master wird einen echten Vorteil dabei gewinnen, Teams kompetent durch das Framework zu führen.
Fazit
Scrum ist eines der besten Geschenke für Produktmanager. Dank des Gleichgewichts zwischen langfristiger Agilität und strikter Struktur in kurzen Iterationen können Sie das Chaos eines rahmenlosen agilen Entwicklungsprozesses vermeiden und zugleich Ihre Produktstrategie flexibel am Markt ausrichten.
Wir hoffen, Ihnen hat unser Leitfaden gefallen. Wenn ja, vergessen Sie nicht, unseren Newsletter zu abonnieren – für weitere Ressourcen und Guides zum Produktmanagement sowie aktuelle Podcasts, Interviews und Einblicke von Branchenführern und Experten.
FAQ:
Welche Aufgabe hat ein Product Manager im Scrum?
Produktmanager, die im Scrum-Team typischerweise die Rolle des Product Owners einnehmen, sind dafür verantwortlich, dem Team Klarheit zu verschaffen, indem sie die Produktpläne, Prioritäten und notwendigen Feature-Anforderungen transparent machen.
Wie unterscheidet sich Scrum von anderen agilen Methoden im Produktmanagement?
Im Gegensatz zu Kanban oder anderen agilen Rahmenwerken ist Scrum strukturierter und gibt klare Regeln vor, wie die Arbeit im Team mit Hilfe seiner Ereignisse (Standup, Grooming usw.) und Artefakte (Sprint Backlog, Product Backlog etc.) organisiert wird.
Was sind typische Herausforderungen beim Produktmanagement mit Scrum?
Die häufigste Herausforderung ist, dass Ihr Team und Ihre Stakeholder die Regeln und Artefakte des Scrum-Frameworks missverstehen und dessen Regeln ändern möchten, bevor das Unternehmen ernsthaft versucht hat, sich auf das neue Framework einzulassen.
Kann ein Product Manager auch Product Owner sein?
Ja. Product Manager ist ein Beruf. Product Owner ist eine Rolle im Scrum-Team. In den meisten Fällen ist der Product Owner im Team auch der Product Manager. Gelegentlich, insbesondere in kleinen Startups, übernimmt z. B. der CEO diese Rolle im Team.
