Der Product Owner ist eine wichtige Rolle im Scrum-Vorgehen. Sie übernimmt die Verantwortung für das Produkt, steuert die Weiterentwicklung des Produktes und dient als wertvolle Schnittstelle zwischen Stakeholdern und Entwicklern.
In diesem Artikel erkläre gehen wir im Detail auf die Rolle des Product Owners. Du bekommst Informationen rund um seine Verantwortung, Aufgaben, Herausforderungen und Werkzeuge. Außerdem beantworten wir die wichtigsten inhaltlichen Fragen, sowie solchen rund um Weiterbildungen, Bücher und Zertifizierungen.
Hinweis: Auch wenn ich meine eigenen Gedanken zu den verschiedenen Punkten hier einfließen lasse, basieren die Konzepte, Ideen und grundlegenden Inhalte auf Schulungen und Büchern.
Auch wenn dieser Artikel sehr ausführlich ist, empfehlen wir dir, selbst einen Kurs zu besuchen oder dich zusätzlich über Bücher weiterzubilden.
Keine Produkte gefunden.
Produkt Owner Definition
Der Product Owner ist eine zentrale Rolle im agilen Vorgehen, insbesondere in der Scrum-Methode.
Er ist verantwortlich für die Maximierung des Produktwerts, indem er die Anforderungen der Stakeholder versteht und diese in klare und priorisierte Einträge im Product Backlog übersetzt. Der Product Owner sorgt dafür, dass das Entwicklungsteam stets an den Aufgaben arbeitet, die den größten Mehrwert für das Produkt liefern.
Dabei ist er das Bindeglied zwischen Stakeholdern und Entwicklungsteam, trifft Entscheidungen über die Priorisierung von Aufgaben und nimmt fertige Funktionalitäten ab.
Produkt Owner Verantwortungen
Der Product Owner hat eine zentrale Rolle im Scrum-Prozess und trägt eine immense Verantwortung für den Erfolg des Produkts. Im Fokus steht dabei immer die Maximierung des Produktwerts. Das bedeutet, dass du als Product Owner sicherstellst, dass das Entwicklungsteam an den Funktionen arbeitet, die den größten Nutzen bringen. Du bist also die Person, die die Richtung vorgibt und entscheidet, was als nächstes entwickelt wird.
Hauptverantwortung: Maximierung des Produktwerts
Deine Hauptaufgabe besteht darin, den Wert des Produkts kontinuierlich zu steigern. Dabei stellst du die Bedürfnisse der Stakeholder in den Mittelpunkt, behältst aber auch die technischen und geschäftlichen Anforderungen im Blick. Hier ist eine klare Priorisierung entscheidend, damit das Team effizient arbeiten kann.
Delegation
Auch wenn du bestimmte Aufgaben delegieren kannst, wie z.B. die Pflege einzelner Backlog-Einträge, bleibt die Verantwortung für das Endergebnis bei dir. Das bedeutet, du triffst die finalen Entscheidungen und musst den Überblick behalten. Es ist wichtig, dass du das Vertrauen des Teams und der Stakeholder besitzt und sicherstellst, dass alle auf dasselbe Ziel hinarbeiten.
Produktentscheidungen
In deiner Rolle triffst du wichtige Produktentscheidungen, die von der gesamten Organisation respektiert werden. Das gibt dir viel Verantwortung, aber auch die notwendige Entscheidungskraft, um das Produkt in die richtige Richtung zu lenken. Deine Entscheidungen sind die Grundlage, auf der das Team arbeitet, und sie sollten daher klar und gut durchdacht sein.
Verwaltung des Product Backlogs
Der Product Backlog ist dein zentrales Werkzeug. Du bist für dessen Pflege verantwortlich, sorgst dafür, dass er stets aktuell und vollständig ist. Dabei geht es nicht nur um das Hinzufügen neuer Anforderungen, sondern vor allem um die Priorisierung. Die Einträge müssen klar formuliert und priorisiert sein, sodass das Team ohne Verzögerungen arbeiten kann.
Entscheidungskraft
Als einzelne Person trägst du die volle Verantwortung. Es gibt kein Gremium, das mit dir gemeinsam Entscheidungen trifft. Diese klare Struktur ermöglicht es dir, schnell zu handeln und agil auf Veränderungen zu reagieren. Gleichzeitig trägst du die Konsequenzen für jede Entscheidung, was die Rolle so entscheidend macht.
Sprint-Abbruch
Eine besondere Macht, die du hast, ist das Recht, einen Sprint abzubrechen, wenn das Sprintziel nicht mehr relevant ist. Dies ist eine drastische Maßnahme, die du nur ergreifen solltest, wenn es wirklich nötig ist. Aber sie zeigt, wie wichtig es ist, dass du den Überblick behältst und flexibel genug bist, um auch mal unpopuläre Entscheidungen zu treffen.
Produktziel und Stakeholder-Kommunikation
Zu deinen Aufgaben gehört es, das Produktziel zu entwickeln und klar zu vermitteln. Dabei geht es nicht nur darum, eine Vision zu haben, sondern diese auch in greifbare Ziele zu übersetzen. Eine regelmäßige und transparente Kommunikation mit den Stakeholdern ist dabei entscheidend, damit alle wissen, wohin die Reise geht und was von ihnen erwartet wird.
Produkt Owner Aufgaben
Verwaltung des Product Backlogs
Was macht der Product Owner genau?
Hier eine Übersicht der wichtigsten Aufgaben:
- Entwicklung und Vermittlung der Produktvision: Der Product Owner entwickelt eine klare Vision für das Produkt, die die Richtung vorgibt und das Team motiviert. Diese Vision wird kontinuierlich mit den Stakeholdern und dem Entwicklungsteam kommuniziert.
- Erstellung und Pflege des Product Backlogs: Der Product Owner erstellt und pflegt den Product Backlog, eine priorisierte Liste von Anforderungen und Features, die entwickelt werden sollen. Es ist seine Aufgabe, sicherzustellen, dass der Backlog stets aktuell und gut strukturiert ist.
- Priorisierung der Anforderungen: Eine der wichtigsten Aufgaben des Product Owners ist die Priorisierung der Einträge im Product Backlog. Dabei muss er abwägen, welche Funktionen den größten Mehrwert für das Produkt bieten, und sicherstellen, dass das Team an den wichtigsten Aufgaben arbeitet.
- Stakeholder-Management: Der Product Owner steht in engem Kontakt mit den Stakeholdern, um deren Anforderungen zu verstehen und diese in den Entwicklungsprozess einfließen zu lassen. Er sorgt für regelmäßige Kommunikation, um Erwartungen zu managen und Feedback einzuholen.
- Unterstützung bei der Sprintplanung: Der Product Owner arbeitet eng mit dem Entwicklungsteam zusammen, um die Ziele für jeden Sprint festzulegen. Dabei stellt er sicher, dass die Anforderungen klar sind und dass das Team genau weiß, welche Aufgaben im nächsten Sprint bearbeitet werden.
- Klärung der Anforderungen: Bei Unklarheiten oder Fragen ist der Product Owner die zentrale Ansprechperson für das Entwicklungsteam. Er sorgt dafür, dass die Anforderungen verstanden und korrekt umgesetzt werden.
- Review und Abnahme der Ergebnisse: Nach jedem Sprint überprüft der Product Owner die umgesetzten Features und entscheidet, ob sie den Anforderungen entsprechen und abgenommen werden können.
- Kontinuierliche Produktverbesserung: Der Product Owner ist verantwortlich für die kontinuierliche Weiterentwicklung des Produkts. Er sammelt Feedback von Nutzern und Stakeholdern und integriert es in den Product Backlog, um das Produkt stetig zu verbessern.
- Markt- und Wettbewerbsanalyse: Der Product Owner beobachtet den Markt und analysiert die Wettbewerber, um sicherzustellen, dass das Produkt den Marktanforderungen entspricht und langfristig wettbewerbsfähig bleibt.
- Entscheidungsfindung: Der Product Owner ist die zentrale Instanz für produktbezogene Entscheidungen. Er trifft diese unabhängig und trägt die Verantwortung für den Erfolg oder Misserfolg der Produktstrategie.
User Storys
Formulierung einer User Story
Eine klassische User Story wird in einem einfachen, aber wirkungsvollen Format formuliert:
„Damit <Mehrwert>, möchte ich als <Rolle>, <Funktionalität>.“
Dieses Format deckt die wesentlichen Fragen ab:
- Warum? – Der Mehrwert erklärt, warum diese Funktionalität überhaupt benötigt wird. Es hilft dem Team zu verstehen, welchen Nutzen die Umsetzung für den Benutzer oder das Produkt hat.
- Wer? – Die Rolle gibt an, wer der direkte Nutzer oder der Begünstigte dieser Funktionalität ist. Dies hilft, den Kontext und die spezifischen Bedürfnisse dieses Benutzers im Auge zu behalten.
- Was? – Die Funktionalität beschreibt, was konkret umgesetzt werden soll, allerdings ohne technische Details. Das „Was“ bleibt auf einer hohen Abstraktionsebene, damit es klar bleibt, worum es geht, ohne in Details zu versinken.
Die 3 Cs von User Storys
User Storys bestehen aus drei wichtigen Elementen, die als die 3 Cs bekannt sind:
Card – Jede User Story sollte auf einer Karte (physisch oder digital) festgehalten werden. Dies macht sie übersichtlich und greifbar. Die Karte selbst enthält die User Story in ihrer kurzen, prägnanten Form, also das „Was“, „Wer“ und „Warum“.
Conversation – Die Karte allein reicht nicht aus. Der wahre Wert einer User Story liegt in der Konversation, die sie anstößt. Diese Gespräche zwischen dem Product Owner, den Stakeholdern und dem Entwicklungsteam klären Details, definieren Erwartungen und sorgen dafür, dass alle Beteiligten ein gemeinsames Verständnis der Anforderung haben.
Confirmation – Schließlich muss jede User Story auch klare Bestätigungskriterien enthalten, um festzulegen, wann sie als erfolgreich umgesetzt gilt. Diese Akzeptanzkriterien geben dem Team die nötige Sicherheit, dass die Story korrekt implementiert wurde und die Anforderungen erfüllt sind.
Das Konzept der 3 Cs zeigt, dass User Storys mehr sind als nur eine Liste von Anforderungen. Sie sollen den Dialog zwischen allen Beteiligten fördern und sicherstellen, dass die Bedürfnisse der Nutzer in den Mittelpunkt gestellt werden. Durch die klare Struktur und den Fokus auf den Mehrwert werden sie zu einem effektiven Werkzeug, um Anforderungen flexibel und verständlich zu kommunizieren.
Der Product Backlog
Der Product Backlog ist das zentrale Element des Anforderungsmanagements im Scrum-Prozess und spielt eine entscheidende Rolle in der agilen Entwicklung. Er fungiert als eine priorisierte Liste von Aufgaben, Anforderungen und Ideen, die das Produkt betreffen und vom Scrum-Team abgearbeitet werden sollen. Der Product Backlog ist dynamisch und wächst im Laufe des Projekts kontinuierlich, da neue Erkenntnisse, Kundenwünsche oder Marktanforderungen aufgenommen werden.
Funktion und Zweck des Product Backlogs
Der Product Backlog dient dazu, alle geplanten und potenziellen Produktfeatures an einem zentralen Ort zu sammeln und sie für das Entwicklungsteam sichtbar zu machen. Dabei handelt es sich nicht um eine starre Liste, sondern um ein lebendiges Dokument, das sich ständig weiterentwickelt.
Neue Ideen, Feedback von Nutzern oder Stakeholdern, technische Verbesserungen oder geänderte Marktbedingungen können jederzeit neue Einträge im Backlog erzeugen.
Der Hauptzweck des Backlogs besteht darin, das Scrum-Team zu steuern und zu priorisieren, welche Aufgaben wann umgesetzt werden sollen. Dabei obliegt es dem Product Owner, die Einträge im Backlog zu pflegen, zu priorisieren und sicherzustellen, dass sie gut verständlich und umsetzbar sind.
Aufbau des Product Backlogs
Ein Product Backlog enthält nicht nur einfache To-Do-Listen, sondern umfasst eine Vielzahl von verschiedenen Arten von Einträgen. Dazu gehören:
- User Stories: Diese beschreiben Anforderungen aus der Perspektive des Nutzers und helfen dem Team, den Wert der Funktion für den Endanwender zu verstehen.
- Fehler und Bugs: Probleme oder Fehler, die im Laufe des Entwicklungsprozesses entdeckt werden, müssen dokumentiert und priorisiert werden.
- Funktionale Anforderungen: Hierunter fallen spezifische Funktionen, die das Produkt erfüllen soll, oft ohne den Endanwenderfokus der User Stories.
- Nicht-funktionale Anforderungen: Dazu gehören Anforderungen an die Performance, Sicherheit oder Skalierbarkeit des Produkts.
- Technische Aufgaben: Diese betreffen notwendige technische Arbeiten, wie die Verbesserung der Architektur, das Refactoring von Code oder die Implementierung technischer Grundlagen.
Die Einträge im Product Backlog sind nicht alle gleichwertig. Sie haben unterschiedliche Prioritäten und Relevanz, abhängig von dem Nutzen, den sie für das Produkt bringen. Der Product Owner ist dafür verantwortlich, diese Prioritäten klar festzulegen.
DEEP-Eigenschaften
Ein gut gepflegter Product Backlog weist die sogenannten DEEP-Eigenschaften auf, die sicherstellen, dass er effektiv genutzt werden kann:
D – Detailed appropriately
Die Einträge im Product Backlog sollten je nach ihrer Priorität und Nähe zur Umsetzung unterschiedlich detailliert sein. Die am höchsten priorisierten Aufgaben, die bald umgesetzt werden, sind detailliert beschrieben und klar verständlich. Weiter entfernte Einträge können weniger detailliert sein und werden nach und nach konkretisiert. Dadurch bleibt der Backlog übersichtlich und flexibel.
E – Estimated
Jede Anforderung im Product Backlog sollte geschätzt sein. Dies ermöglicht dem Team, den Aufwand und die Komplexität jeder Aufgabe einzuschätzen und eine realistische Planung zu machen. Diese Schätzungen helfen außerdem, Entscheidungen über Prioritäten zu treffen und Ressourcen effizient zu nutzen.
E – Emergent
Der Product Backlog ist ein lebendiges Dokument. Das bedeutet, dass es sich kontinuierlich weiterentwickelt, wenn neue Anforderungen oder Erkenntnisse hinzukommen. Der Backlog ist nicht statisch, sondern passt sich flexibel den veränderten Marktbedingungen, Nutzeranforderungen oder technischen Möglichkeiten an. Der emergente Charakter des Backlogs sorgt dafür, dass das Team immer an den wichtigsten und aktuellsten Aufgaben arbeitet.
P – Prioritized (or properly ordered)
Eine der wichtigsten Eigenschaften des Product Backlogs ist seine Priorisierung. Die Einträge im Backlog sind nach ihrer Wichtigkeit und ihrem Wert für das Produkt geordnet. Der Product Owner sorgt dafür, dass das Team an den Aufgaben arbeitet, die den größten Nutzen für das Produkt und die Stakeholder liefern. Diese Priorisierung ermöglicht es dem Team, sich auf das Wesentliche zu konzentrieren und effizient zu arbeiten.
Durch die Anwendung der DEEP-Eigenschaften wird der Product Backlog zu einem leistungsfähigen Werkzeug, das das Entwicklungsteam steuert und sicherstellt, dass die Arbeit kontinuierlich in die richtige Richtung gelenkt wird. Ein gut gepflegter Backlog trägt entscheidend dazu bei, dass das Produkt erfolgreich entwickelt und an die Bedürfnisse der Nutzer und des Marktes angepasst wird.
Product Backlog Refinement
Das Product Backlog Refinement ist ein wichtiger Prozess im Scrum-Framework, der dazu dient, den Product Backlog kontinuierlich zu aktualisieren und für den nächsten Sprint vorzubereiten. Es handelt sich um eine kollaborative Aktivität, bei der der Product Owner, das Entwicklungsteam, der Scrum Master und optional auch Fachexperten zusammenkommen, um sicherzustellen, dass die Einträge im Backlog klar definiert, priorisiert und in einer umsetzbaren Form vorliegen.
Ziel des Product Backlog Refinements
Das primäre Ziel des Product Backlog Refinements ist es, den Backlog so vorzubereiten, dass das Team im nächsten Sprint direkt mit der Arbeit beginnen kann. Hierzu werden die Einträge im Backlog überprüft, aufgeteilt und detailliert, sodass alle Beteiligten ein gemeinsames Verständnis der Aufgaben haben.
Dies erhöht die Effizienz und sorgt dafür, dass das Team fokussiert und ohne Verzögerungen arbeiten kann.
Teilnehmende
In der Regel nehmen folgende Personen am Product Backlog Refinement teil:
- Product Owner: Verantwortlich für die Priorisierung der Einträge und das Sicherstellen, dass die Anforderungen klar sind.
- Entwicklungsteam: Bringt technisches Know-how ein und gibt Feedback zu den Machbarkeiten der Anforderungen.
- Scrum Master: Moderiert das Refinement und stellt sicher, dass der Prozess effizient abläuft.
- Fachexperten (optional): Können bei Bedarf hinzugezogen werden, um spezifische Anforderungen oder Geschäftsprozesse zu klären.
Timebox und Terminierung
Das Product Backlog Refinement sollte nicht mehr als 10 % der Zeit eines Sprints in Anspruch nehmen. Es gibt keine feste Regel für den Zeitpunkt, wann das Refinement stattfinden sollte, aber es ist oft sinnvoll, es regelmäßig durchzuführen, um den Backlog stets aktuell zu halten.
Ein gängiger Ansatz ist es, den Refinement-Prozess in der Mitte der Woche zu terminieren, um vor dem nächsten Sprint genügend Zeit für die Vorbereitung zu haben.
Aktivitäten im Product Backlog Refinement
Während des Refinements werden verschiedene Aktivitäten durchgeführt, um die Einträge im Backlog verständlich und umsetzbar zu machen. Dazu gehören:
- Große Einträge splitten: Umfangreiche User Stories oder Epics werden in kleinere, handhabbare Einheiten aufgeteilt, sodass sie im Sprint bearbeitet werden können. Dies kann durch verschiedene Kriterien wie Geschäftsprozess-Schritte, Datenvariationen oder Regelvariationen geschehen.
- Akzeptanzkriterien definieren: Für jede User Story werden klare Akzeptanzkriterien festgelegt, die festlegen, wann die Aufgabe als erfolgreich umgesetzt gilt. Diese Kriterien sind wichtig, um Missverständnisse zu vermeiden und sicherzustellen, dass das Team die Anforderungen richtig umsetzt.
- Einträge schätzen: Das Entwicklungsteam schätzt den Aufwand für jede User Story, um eine realistische Sprintplanung zu ermöglichen.
- User Storys aufteilen: Komplexe oder große User Stories werden in kleinere, spezifischere Geschichten unterteilt, um sie handhabbarer zu machen. Dies kann beispielsweise nach verschiedenen Funktionen, Geschäftsprozess-Schritten oder auch nach der Datenverarbeitung geschehen.
Details zum Aufteilen von user Storys
Ein zentraler Teil des Refinements ist das Aufteilen großer User Stories in kleinere, umsetzbare Einheiten. Dabei können verschiedene Kriterien berücksichtigt werden:
- Schritte im Geschäftsprozess: Die Story wird nach den verschiedenen Schritten aufgeteilt, die in einem Geschäftsprozess identifiziert werden können.
- Variationen der Daten: Unterschiedliche Datensätze oder Datenvarianten, die von der User Story verwendet werden, können zu separaten Aufgaben führen.
- Regelvariationen: Verschiedene Regeln oder Szenarien, die während des Prozesses auftreten, bieten ebenfalls eine Möglichkeit zur Aufteilung.
- Einfache vs. komplexe Aspekte: Teile der User Story, die besonders komplex sind, werden herausgenommen, um sie gesondert zu behandeln.
- Methoden zur Datenein- und -ausgabe: Betrachtung, wie Daten in das System gelangen und wieder ausgegeben werden, bietet ebenfalls eine Möglichkeit zur strukturierten Aufteilung.
- Performance und Qualität: Berücksichtigung der Performance oder Qualitätsanforderungen, die später im Prozess relevant werden, kann als Kriterium für eine Aufteilung herangezogen werden.
Sprint Planning
Das Sprint Planning ist ein Ereignis im Scrum-Prozess, bei dem das gesamte Scrum-Team zusammenkommt, um den nächsten Sprint zu planen. Das Ziel des Sprint Plannings besteht darin, sicherzustellen, dass allen Beteiligten klar ist, was im kommenden Sprint entwickelt werden soll und wie das Team dies erreichen will. Es legt den Grundstein für einen erfolgreichen Sprint, indem das Team gemeinsam die Prioritäten und Aufgaben festlegt.
Ziel des Sprint Plannings
Der Hauptzweck des Sprint Plannings ist es, ein gemeinsames Verständnis darüber zu schaffen, welche Aufgaben aus dem Product Backlog in den nächsten Sprint übernommen werden und welches Sprintziel erreicht werden soll. Dabei wird festgelegt, welche spezifischen Anforderungen in Form von Backlog-Items umgesetzt werden und wie das Team diese Aufgaben technisch angehen will.
Teilnehmende
Am Sprint Planning nimmt das gesamte Scrum-Team teil, das aus dem Product Owner, dem Entwicklungsteam und dem Scrum Master besteht. Der Product Owner bringt die priorisierten Einträge aus dem Product Backlog ein, während das Entwicklungsteam die technische Machbarkeit und den Umfang der Aufgaben bewertet. Der Scrum Master moderiert das Meeting und sorgt dafür, dass die Timebox eingehalten wird und das Team sich auf die Planung konzentriert.
Timebox
Das Sprint Planning ist auf eine maximale Dauer von 8 Stunden begrenzt, unabhängig davon, wie lange der Sprint selbst dauert. Bei kürzeren Sprints kann auch die Planungszeit deutlich kürzer sein. Diese Timebox stellt sicher, dass die Planungsphase effizient abläuft und das Team sich nicht in zu vielen Details verliert.
Aktivitäten während des Sprint Plannings
Während des Sprint Plannings zieht das Entwicklungsteam nach und nach Backlog-Items aus dem Product Backlog in den Sprint, basierend auf der Priorisierung durch den Product Owner und den Kapazitäten des Teams. Dieser „Pull“-Prozess dauert so lange an, bis das Team sicher ist, dass es die Aufgaben innerhalb des Sprints bewältigen kann. Das Team schätzt, wie viel Arbeit es im Sprint erledigen kann, und bricht große Anforderungen in handhabbare Aufgaben herunter.
Ergebnis des Sprint Plannings
Am Ende des Sprint Plannings sollten mehrere wichtige Ergebnisse vorliegen:
- Ein Sprint Backlog, der die spezifischen Anforderungen und Aufgaben enthält, die im kommenden Sprint bearbeitet werden.
- Ein klares Sprintziel, das das übergeordnete Ziel des Sprints beschreibt. Das Sprintziel gibt dem Team eine klare Richtung und hilft, den Fokus auf den wichtigsten Aspekt der Entwicklung zu legen.
Das Sprintziel ist dabei mehr als eine einfache Liste von Aufgaben. Es stellt eine übergeordnete Beschreibung des Ziels dar, das das Team während des Sprints erreichen möchte. Es hilft dabei, den Sprint auf ein gemeinsames Ziel zu fokussieren und gibt allen Beteiligten ein klares Bild davon, was am Ende des Sprints erreicht werden soll.
Terminierung im Sprint Kalender
Das Sprint Planning findet immer zu Beginn eines jeden Sprints statt und markiert den offiziellen Startpunkt des neuen Entwicklungszyklus. Die Terminierung erfolgt in der Regel direkt nach dem Abschluss des vorherigen Sprints, um nahtlos in den neuen Sprint überzugehen.
Sprint Review
Das Sprint Review ist ein Ereignis im Scrum-Prozess, bei dem das Scrum-Team zusammen mit den Stakeholdern das Ergebnis des Sprints überprüft. Das Ziel dieses Meetings ist es, Feedback zur entwickelten Funktionalität einzuholen und das Produkt auf Basis dieses Feedbacks kontinuierlich zu verbessern.
Es handelt sich um eine Gelegenheit, das Produktinkrement vorzustellen und gemeinsam mit den Stakeholdern über den weiteren Fortschritt zu diskutieren.
Ziel des Sprint Reviews
Der Hauptzweck des Sprint Reviews ist es, den aktuellen Stand des Produkts zu bewerten und direktes Feedback von den Stakeholdern zu sammeln.
Durch diese Rückmeldungen kann das Scrum-Team sicherstellen, dass das Produkt die Erwartungen der Stakeholder erfüllt und auf Kurs bleibt, um den größtmöglichen Nutzen zu liefern. Zusätzlich gibt es die Möglichkeit, neu aufgetretene Erkenntnisse in den weiteren Entwicklungsprozess einfließen zu lassen.
Teilnehmende
Am Sprint Review nehmen alle wichtigen Beteiligten teil, einschließlich des gesamten Scrum-Teams (Product Owner, Entwicklungsteam und Scrum Master) sowie der Stakeholder. Dies bietet eine direkte Schnittstelle zwischen dem Team, das das Produkt entwickelt, und denjenigen, die es letztlich nutzen oder finanzieren. Die Stakeholder bringen wertvolles Feedback ein und können Fragen zum aktuellen Stand der Entwicklung stellen.
Timebox
Das Sprint Review ist auf eine maximale Dauer von 4 Stunden begrenzt, wobei die Länge in der Regel von der Sprintdauer abhängt. Bei kürzeren Sprints kann das Meeting entsprechend kürzer sein. Die Timebox sorgt dafür, dass das Review effizient bleibt und sich auf die wesentlichen Punkte konzentriert.
Aktivitäten im Sprint Review
Im Mittelpunkt des Sprint Reviews steht die Vorstellung des Produktinkrements. Das Scrum-Team präsentiert die Ergebnisse des Sprints – also die neuen oder verbesserten Features, die in diesem Sprint entwickelt wurden. Dieses Inkrement sollte potenziell auslieferbar sein, sodass die Stakeholder einen realen Eindruck von den Fortschritten gewinnen können.
Neben der Präsentation liegt ein starker Fokus auf dem Sammeln von Feedback. Die Stakeholder haben die Möglichkeit, ihre Eindrücke und Meinungen zur bisherigen Entwicklung zu äußern. Diese Rückmeldungen sind für das Scrum-Team wertvoll, um das Produkt weiter zu verbessern und den Backlog entsprechend anzupassen.
Ergebnis des Sprint Reviews
Das wichtigste Ergebnis des Sprint Reviews ist ein angepasster Product Backlog. Das Feedback aus dem Review wird in den Backlog eingearbeitet, indem neue Anforderungen hinzugefügt oder bestehende Einträge umpriorisiert werden. Auch neue Erkenntnisse, die während des Sprints gewonnen wurden, können berücksichtigt werden.
Dadurch bleibt der Product Backlog stets aktuell und reflektiert die Wünsche der Stakeholder sowie die Lernfortschritte des Teams.
Herausforderungen im Sprint Review
Eine der größten Herausforderungen für den Product Owner im Rahmen des Sprint Reviews ist es, ein ausgewogenes Verhältnis zwischen der Durchsetzung von Prioritäten und dem Wahrnehmen der Stakeholder-Interessen zu finden. Hier sind einige wichtige Aspekte:
„Nein“ sagen ohne langfristiges Abschrecken und Demotivieren: Es ist oft notwendig, Anfragen oder Vorschläge von Stakeholdern abzulehnen, um den Fokus des Teams zu bewahren und Überlastung zu vermeiden. Dies erfordert diplomatisches Geschick, damit die Beteiligten weiterhin motiviert bleiben und sich nicht ausgeschlossen fühlen. Ein klares „Nein“ muss stets gut begründet sein und auf den Wert des Produkts fokussiert bleiben.
Als Team wirken und nur notwendige Diskussionen führen: Im Sprint Review sollte das Scrum-Team als Einheit auftreten. Überflüssige oder detailverliebte Diskussionen sollten vermieden werden, um das Meeting fokussiert und zielführend zu gestalten. Gleichzeitig muss jedoch genug Raum für wichtige Rückmeldungen und Fragen gelassen werden.
Sprint-Ergebnis vorab abnehmen: Falls es erforderlich ist, dass der Product Owner das Sprint-Ergebnis abnimmt, sollte diese Abnahme vor dem Review-Meeting mit den Stakeholdern stattfinden. So wird vermieden, dass mögliche Kritik oder Unklarheiten das Review dominieren. Im Sprint Review selbst sollten die Stakeholder nur das fertige Produktinkrement zu sehen bekommen, um gezieltes Feedback zu geben
Feedbackformate
Um das Feedback im Sprint Review effektiv zu gestalten, gibt es verschiedene Formate, die sich je nach Ziel, Gruppengröße und Dynamik variieren lassen.
Perfection Game
Bei diesem Format bewerten die Stakeholder das Produkt auf einer Skala von 0 bis 10, wie perfekt es ihrer Meinung nach ist. Anschließend wird jeder gebeten, zu skizzieren, was fehlt, um das Produkt um einen Punkt besser zu machen.
Vorteile:
- Jeder Stakeholder gibt greifbares Feedback, das sich auf die Verbesserung konzentriert.
- Auch in größeren Gruppen gut anwendbar, da die Skala klar ist.
- Individuelles Feedback hilft, dass auch stille Personen sich trauen, ihre Meinung zu äußern.
Moderierte Feedback-Frage
In diesem Format werden die Stakeholder einzeln gefragt: „Was fehlt, um das gewünschte Ergebnis zu erzielen?“ Das Feedback wird gesammelt und geordnet.
Vorteile:
- Der Product Owner kann durch gezielte Moderation sicherstellen, dass Schlüsselpersonen und deren Meinungen nicht untergehen.
- Diese Methode strukturiert das Feedback und ermöglicht dem Product Owner, Prioritäten zu setzen und gezielt auf wichtige Rückmeldungen einzugehen.
Breakout-Feedback-Runden
Hierbei werden kleinere Gruppen gebildet, in denen die Beteiligten reihum Feedback geben können. Das Feedback wird anschließend im Plenum zusammengetragen.
Vorteile:
- In kleineren Gruppen geben auch zurückhaltende Personen eher Feedback.
- Es gibt mehr Raum, um Feedback zu erläutern und detailliert zu diskutieren.
- Diese Methode eignet sich besonders gut für große Gruppen, da das Feedback in kleineren Einheiten gesammelt und effizienter verarbeitet werden kann.
Variieren von Feedback-Formaten
Um Abwechslung in den Sprint Reviews zu gewährleisten und den verschiedenen Bedürfnissen der Stakeholder gerecht zu werden, kann es sinnvoll sein, die Feedback-Formate regelmäßig zu variieren.
Vorteile:
- Verschiedene Formate können passend zum jeweiligen Sprintziel gewählt werden.
- Die Gruppengröße und Dynamik werden berücksichtigt, sodass das Feedback sowohl effizient als auch effektiv ist.
Stakeholder-Management
Ziel des Stakeholder-Managements
Das primäre Ziel des Stakeholder Managements ist es, die unterschiedlichen Bedürfnisse, Interessen und Einflussfaktoren der Stakeholder zu verstehen und zu berücksichtigen. Dazu gehört es, die relevanten Personen oder Gruppen zu identifizieren und die Zusammenarbeit so zu steuern, dass das Produkt am Ende den größtmöglichen Nutzen liefert. Dies erfordert regelmäßige Kommunikation, aktives Einholen von Feedback und das Setzen realistischer Erwartungen.
Die Stakeholder-Matrix
Eine nützliche Methode zur Strukturierung des Stakeholder Managements ist die Stakeholder-Matrix, die auch in deinem hochgeladenen Bild dargestellt wird. Diese Matrix hilft, Stakeholder basierend auf ihrem Einfluss und ihrem Interesse am Produkt zu kategorisieren. Die Hauptachsen sind dabei „Einfluss“ und „Interesse“. Je nachdem, in welche Kategorie ein Stakeholder fällt, kann die Art der Interaktion und Kommunikation angepasst werden:
Hoher Einfluss, hohes Interesse (Pflichtteilnehmer): Diese Stakeholder, wie Schlüsselanwender oder das Management, sollten eng in den Entwicklungsprozess eingebunden werden. Sie spielen eine zentrale Rolle in den Reviews und wichtigen Meetings, da sie stark in den Erfolg des Produkts involviert sind.
Hoher Einfluss, geringes Interesse (Separate Meetings): Stakeholder wie die Rechtsabteilung oder Compliance-Teams haben möglicherweise viel Einfluss, sind jedoch weniger in die täglichen Details involviert. Hier sind separate Meetings sinnvoll, um gezielt über ihre Anforderungen zu sprechen, ohne sie mit zu vielen Details zu belasten.
Geringer Einfluss, hohes Interesse (Optionale Teilnehmer): Diese Gruppe, zu der beispielsweise das Marketing oder der Support gehören könnte, ist interessiert am Produkt, hat jedoch weniger direkte Macht. Sie können an optionalen Besprechungen teilnehmen und sollten regelmäßig informiert werden.
Geringer Einfluss, geringes Interesse (Informieren im Nachhinein): Stakeholder mit geringem Einfluss und Interesse, wie einige periphere Abteilungen, können über große Meilensteine und Fortschritte im Nachhinein per E-Mail oder Bericht informiert werden. Hier reicht eine passive Kommunikation.
Effektive Strategien für die Zusammenarbeit
Für ein erfolgreiches Stakeholder Management empfiehlt es sich, eine klare Kommunikationsstrategie zu entwickeln. Dies beinhaltet, wann, wie und in welchem Format Stakeholder informiert oder einbezogen werden. Es ist ebenso wichtig, die Erwartungen der Stakeholder frühzeitig zu managen, indem man klare Ziele und realistische Zeitpläne kommuniziert und regelmäßig Updates gibt.
Zusätzlich sollten Product Owner aktive Zuhörstrategien anwenden, um sicherzustellen, dass die Anliegen der Stakeholder gehört und verstanden werden. Dies fördert Vertrauen und hilft, Konflikte rechtzeitig zu identifizieren und zu lösen.
Empirische Prozesskontrolle
Empirische Prozesskontrolle ist ein grundlegendes Prinzip agiler Methoden wie Scrum. Es basiert darauf, Entscheidungen durch Erfahrung und Beobachtung zu treffen. Der Prozess wird durch drei Säulen unterstützt: Transparenz, Inspektion und Anpassung.
Das Ziel ist es, durch kontinuierliches Feedback den Prozess und das Produkt schrittweise zu optimieren.
Komplexitätslandkarte - Welche Methode ist wann sinnvoll?
Die Komplexitätslandkarte (auch bekannt als Cynefin-Framework) ist ein hilfreiches Modell zur Entscheidungsfindung, das verschiedenen Arten von Situationen oder Systemen je nach ihrer Komplexität und Unsicherheit unterschiedliche Herangehensweisen zuweist.
Das Ziel ist es, herauszufinden, welche Methodik – beispielsweise agiles Arbeiten, Expertenwissen oder Krisenmanagement – in welchem Kontext am besten geeignet ist. Das von dir hochgeladene Bild zeigt diese Landkarte grafisch.
Achsen und Dimensionen der Komplexitätslandkarte
- Vertikale Achse: Diese zeigt den Grad der Anforderungsunsicherheit, also wie klar oder unklar die Anforderungen und deren Zusammenhang mit der Lösung sind.
- Horizontale Achse: Sie beschreibt die Umsetzbarkeit, also wie beherrschbar oder unbeherrschbar die Situation oder Lösung ist.
Je nachdem, in welchem Bereich sich eine Situation auf dieser Karte befindet, bietet sich ein spezifischer Ansatz zur Problemlösung an.
Vier Kategorien der Komplexitätslandkarte
- Einfach:
In einfachen Situationen ist die Beziehung zwischen Ursache und Wirkung klar erkennbar. Die Anforderungen sind eindeutig und es gibt bewährte Best Practices. Hier wird der Ansatz „sense – categorize – respond“ (erkennen, kategorisieren, reagieren) angewendet. Dies ist der Fall, wenn Lösungen routiniert und problemlos gefunden werden können. Traditionelle Methoden, Standards und vorgegebene Prozesse funktionieren hier gut.Beispiel: Standardisierte IT-Supportprozesse, bei denen einfache Anfragen anhand von vordefinierten Lösungsschritten bearbeitet werden.
Kompliziert:
Komplizierte Situationen erfordern mehr Expertise. Die Ursache-Wirkungs-Beziehung ist nicht sofort offensichtlich, kann aber durch Analyse und das Hinzuziehen von Fachwissen verstanden werden. Hier kommt der Ansatz „sense – analyze – respond“ (erkennen, analysieren, reagieren) zum Einsatz. Expertenwissen und detaillierte Analysen sind notwendig, um Lösungen zu entwickeln, die funktionieren.Beispiel: Ingenieurwissenschaften, bei denen komplexe Berechnungen und Expertenanalysen notwendig sind, um optimale Ergebnisse zu erzielen.
- Komplex:
In komplexen Systemen sind Ursache und Wirkung oft nur im Nachhinein nachvollziehbar. Diese Situationen erfordern experimentelle und iterative Ansätze. Der Fokus liegt darauf, neue Lösungen auszuprobieren und anhand der Ergebnisse Rückschlüsse zu ziehen („probe – sense – respond“ – testen, erkennen, reagieren). Hier passen agile Methoden wie Scrum besonders gut, da sie auf Flexibilität, kontinuierliches Feedback und iterative Anpassungen setzen.Beispiel: Produktentwicklung unter unsicheren Marktbedingungen, bei denen sich Anforderungen dynamisch ändern und kontinuierliches Feedback notwendig ist.
- Chaotisch:
In chaotischen Kontexten gibt es keine klaren Ursache-Wirkung-Beziehungen. In solchen Situationen muss schnell gehandelt werden, um Stabilität zu schaffen. Der Ansatz lautet hier „act – sense – respond“ (handeln, erkennen, reagieren). Es geht darum, schnell zu handeln, das Chaos zu ordnen und die Situation in einen der anderen Bereiche zu überführen.Beispiel: Krisenmanagement bei Naturkatastrophen, wo schnelle Entscheidungen erforderlich sind, um die Situation zu stabilisieren.
Bedeutung für Scrum und Agile Methoden
Scrum und agile Methoden sind in der komplexen Zone der Komplexitätslandkarte angesiedelt. Hier sind die Anforderungen unklar, und es wird ein iterativer Ansatz benötigt, um durch Ausprobieren herauszufinden, was funktioniert. Agilität ermöglicht es Teams, flexibel auf Änderungen zu reagieren, was in diesem unsicheren und sich ständig verändernden Umfeld entscheidend ist.
Priorisierungstechniken
Priorisierung ist der Schlüssel, um sicherzustellen, dass die richtigen Aufgaben zur richtigen Zeit in Angriff genommen werden.
Ohne eine klare Priorisierung besteht die Gefahr, dass wertvolle Ressourcen auf weniger wichtige Aufgaben verschwendet werden, während kritische Themen unbeachtet bleiben. Durch die Priorisierung wird der Fokus auf jene Aktivitäten gelenkt, die den größten Mehrwert für das Produkt oder das Unternehmen bieten. Sie sorgt zudem dafür, dass das Team effizient arbeitet und sich auf die wichtigsten Ziele konzentriert.
Letztlich ermöglicht eine gut durchdachte Priorisierung auch eine bessere Kommunikation mit Stakeholdern, da klar ist, worauf der Fokus liegt und warum bestimmte Aufgaben Vorrang haben.
Die MoSCoW-Methode
Die MoSCoW-Methode ist eine weit verbreitete Priorisierungstechnik, die hilft, Anforderungen in verschiedenen Dringlichkeitsstufen zu klassifizieren. Der Name MoSCoW steht für die vier Kategorien „Must have“, „Should have“, „Could have“ und „Won’t have“ (in manchen Versionen auch „Would like to have“). Diese Kategorien ermöglichen es, Anforderungen klar zu differenzieren und sicherzustellen, dass die wichtigsten Aspekte zuerst umgesetzt werden.
- Must have: Diese Anforderungen sind kritisch für den aktuellen Lieferzyklus. Ohne diese Features kann das Projekt nicht erfolgreich abgeschlossen werden. Sie stellen die grundlegenden Funktionen dar, die das System oder Produkt erfüllen muss.
- Should have: Diese Funktionen sind wichtig, aber nicht absolut notwendig für die unmittelbare Lieferung. Wenn sie fehlen, könnte das System eingeschränkt funktionieren, aber der grundlegende Zweck wäre immer noch erfüllt. Sie haben eine etwas niedrigere Priorität als „Must have“.
- Could have: Diese Anforderungen sind wünschenswert, aber nicht entscheidend. Sie haben eine geringere Priorität und werden nur umgesetzt, wenn genug Zeit und Ressourcen vorhanden sind. Diese Features tragen zwar zum Mehrwert bei, sind jedoch nicht notwendig für den Erfolg des Projekts.
- Won’t have: Diese Kategorie umfasst Anforderungen, die in diesem Lieferzyklus nicht umgesetzt werden. Sie können jedoch für zukünftige Releases in Betracht gezogen werden. Diese Entscheidung trägt dazu bei, den aktuellen Fokus zu bewahren und Überladung zu vermeiden.
Durch die Einteilung in diese Kategorien hilft die MoSCoW-Methode, den Fokus auf das Wesentliche zu richten, während gleichzeitig Raum für Flexibilität und Anpassungen bleibt. Sie stellt sicher, dass Teams ihre Ressourcen auf die wichtigsten Aufgaben konzentrieren und dennoch eine klare Roadmap für weniger kritische Funktionen haben.
Die Eisenhower-Matrix
Die Eisenhower-Matrix, auch bekannt als Urgent-Important-Matrix, ist eine bewährte Methode im Zeitmanagement, die Aufgaben nach ihrer Dringlichkeit und Wichtigkeit kategorisiert. Sie hilft dabei, den Fokus auf die wirklich relevanten Aufgaben zu legen und unnötige Ablenkungen zu vermeiden. Die Matrix teilt Aufgaben in vier Quadranten ein:
- Wichtig und dringend: Diese Aufgaben erfordern sofortiges Handeln. Sie sind von hoher Bedeutung und zeitkritisch. Hierzu zählen Krisen, Deadlines oder dringende Probleme, die ohne schnelles Handeln negative Konsequenzen haben könnten. Diese Aufgaben sollten sofort erledigt werden.
- Wichtig, aber nicht dringend: Diese Aufgaben sind entscheidend für langfristige Ziele, aber nicht zeitkritisch. Oft handelt es sich um strategische Planungen, persönliche Entwicklung oder wichtige Projekte, die gut geplant werden sollten. Diese Aufgaben sollten in den Kalender eingeplant werden, um sicherzustellen, dass sie nicht durch dringende Aufgaben verdrängt werden.
- Nicht wichtig, aber dringend: Diese Aufgaben erscheinen zeitkritisch, tragen aber wenig zum Erreichen von Zielen bei. Hierbei handelt es sich oft um Unterbrechungen, Anfragen oder Aufgaben, die von anderen delegiert wurden. Solche Aufgaben können häufig delegiert oder an andere Personen weitergegeben werden.
- Nicht wichtig und nicht dringend: Diese Aufgaben bringen weder sofortigen noch langfristigen Mehrwert und sollten, wenn möglich, eliminiert oder ignoriert werden. Sie sind reine Zeitfresser, wie z.B. unnötige Meetings oder überflüssige E-Mails.
Die Eisenhower-Matrix hilft dabei, zwischen Aufgaben zu unterscheiden, die wirklich wichtig für die Erreichung von Zielen sind, und denen, die nur oberflächlich dringlich erscheinen. Durch das strukturierte Vorgehen, das auch mithilfe von Eisenhower-Matrix-Tools verwendet werden kann, kann Zeit effizienter genutzt und der Fokus auf wirklich entscheidende Aufgaben gelegt werden.
Die 100 Point-Methode
Die 100 Point-Methode ist eine einfache, aber effektive Technik zur Priorisierung von Aufgaben oder Features innerhalb eines Teams. Dabei erhält jedes Teammitglied eine festgelegte Anzahl von Punkten, in der Regel 100, die es nach eigenem Ermessen auf eine Liste von Funktionen oder Aufgaben verteilt. Die Verteilung der Punkte erfolgt basierend auf der Wichtigkeit und dem Wert, den das jeweilige Feature oder die Aufgabe für das Projekt oder den Nutzer hat.
Jedes Teammitglied hat also die Möglichkeit, durch seine Punktverteilung anzuzeigen, welche Aufgaben oder Funktionen es für am wichtigsten hält. Die Summe aller vergebenen Punkte liefert einen klaren Überblick darüber, welche Features aus Sicht des Teams den höchsten Stellenwert haben. Diese Methode hilft dabei, unterschiedliche subjektive Meinungen im Team zu objektivieren und eine gemeinsame Entscheidungsgrundlage für die Priorisierung zu schaffen.
Ein weiterer Vorteil der 100 Point-Methode ist die Transparenz: Da die Verteilung der Punkte visuell und leicht verständlich ist, wird schnell ersichtlich, wo die Präferenzen und Prioritäten der Teammitglieder oder Stakeholder liegen. Auf diese Weise kann das Team leichter einen Konsens darüber erzielen, welche Aufgaben mit höherer Priorität behandelt werden sollten.
Insgesamt bietet die Methode eine unkomplizierte Möglichkeit, Feedback einzuholen und Entscheidungen auf Basis kollektiver Meinungen zu treffen.
Priorisierung nach Wert / Business-Value
Die Priorisierung nach Wert (Business-Value) ist eine Methode, bei der Aufgaben oder Features basierend auf ihrem geschätzten Beitrag zu den Geschäftszielen eingestuft werden. Der Business-Value bezieht sich auf den potenziellen Mehrwert, den eine Funktion oder ein Projekt für das Unternehmen generiert, und kann verschiedene Aspekte umfassen:
- Umsatzsteigerung: Features, die das Potenzial haben, direkt den Umsatz zu steigern, etwa durch neue Funktionen, die zusätzliche Käufe ermöglichen.
- Kundenbindung: Features, die die Zufriedenheit und Loyalität der bestehenden Kunden erhöhen und damit den langfristigen Geschäftserfolg sichern.
- Marktdurchdringung: Funktionen, die es dem Unternehmen ermöglichen, neue Märkte zu erschließen oder bestehende Märkte weiter zu durchdringen.
- Strategische Bedeutung: Features, die wichtig für die längerfristige strategische Ausrichtung des Unternehmens sind.
Bei dieser Methode erhalten die Aufgaben oder Funktionen mit dem höchsten geschäftlichen Wert die höchste Priorität. Der Vorteil dieser Methode ist, dass das Team sicherstellt, dass seine Ressourcen auf die Bereiche konzentriert werden, die den größten Einfluss auf die Geschäftsziele haben. Dadurch wird verhindert, dass Zeit und Energie in weniger wertvolle oder weniger strategische Aufgaben investiert werden.
Die Business-Value-Priorisierung bietet eine klare Ausrichtung auf den Erfolg des Unternehmens und fördert die Fokussierung auf jene Features, die den größten Return on Investment (ROI) versprechen.
Priorisierung nach Komplexität
Priorisierung nach Aufwandsschätzung
Die Priorisierung nach Aufwandsschätzungen ordnet Aufgaben oder Features basierend auf dem geschätzten Arbeitsaufwand, der für ihre Umsetzung erforderlich ist. Diese Methode nutzt Schätzungen darüber, wie viel Zeit, Ressourcen und Energie eine Aufgabe in Anspruch nehmen wird, um sie entsprechend zu priorisieren.
Zwei Ansätze werden bei dieser Methode oft verfolgt:
Aufgaben mit geringem Aufwand priorisieren: Hierbei werden kleinere, weniger aufwändige Aufgaben bevorzugt. Diese lassen sich schnell umsetzen, was kurzfristig sichtbare Erfolge und Fortschritte ermöglicht. Dies kann das Team motivieren und die Effizienz steigern, da kleine Ergebnisse schneller erreicht werden.
Aufwändige, aber wichtige Aufgaben priorisieren: Alternativ kann es sinnvoll sein, sich zuerst auf größere und komplexere Aufgaben zu konzentrieren, um sicherzustellen, dass für diese genügend Zeit und Ressourcen zur Verfügung stehen. Dies minimiert das Risiko, dass wesentliche Funktionen oder Projekte am Ende vernachlässigt werden, weil der Aufwand falsch eingeschätzt wurde.
Diese Priorisierungsmethode hilft dabei, sowohl kurzfristige Erfolge zu erzielen als auch sicherzustellen, dass genug Ressourcen für die wichtigen und aufwändigen Aufgaben eingeplant werden. Durch die Bewertung des Aufwands erhält das Team eine bessere Übersicht darüber, wie es seine Zeit und Energie am effizientesten einsetzen kann.
Priorisierung nach Cost of Delay (CoD)
Die Priorisierung nach Cost of Delay (CoD) ist eine wirtschaftlich orientierte Technik, bei der der finanzielle Verlust oder entgangene Gewinn berücksichtigt wird, der durch eine Verzögerung bei der Umsetzung eines Features oder Projekts entsteht. Mit dieser Methode wird der ökonomische Einfluss einer Verzögerung quantifiziert, um herauszufinden, welche Features den höchsten wirtschaftlichen Schaden verursachen würden, wenn sie nicht zeitnah umgesetzt werden.
Dabei gibt es zwei Hauptüberlegungen:
Zeitkritische Features: Einige Features oder Projekte haben einen hohen zeitlichen Wert, da eine Verzögerung ihre Bedeutung drastisch verringern kann. Ein klassisches Beispiel sind saisonale Features, die nur zu bestimmten Zeitpunkten relevant sind. Eine Verzögerung würde hier einen massiven Gewinnverlust bedeuten.
Wichtige Geschäftsziele: Die Priorisierung richtet sich auch nach den langfristigen Auswirkungen auf das Unternehmen. Features, die einen hohen strategischen Wert oder eine starke Marktauswirkung haben, werden höher priorisiert, da die Verzögerung den Wettbewerbsvorteil kosten könnte.
Die Berechnung des Cost of Delay hilft dabei, die Ressourcen auf diejenigen Aufgaben zu konzentrieren, die den größten wirtschaftlichen Mehrwert bieten, indem sie verhindern, dass finanzielle Verluste durch Verzögerungen entstehen. Diese Methode ist besonders nützlich, um Entscheidungen unter Zeitdruck zu treffen und sicherzustellen, dass die wertvollsten Features zuerst umgesetzt werden.
Priorisierungsmatrix
Die Priorisierungsmatrix dient als visuelles Werkzeug, um den Wert eines Items im Verhältnis zu den Kosten zu bewerten. Das von dir hochgeladene Bild zeigt eine Matrix, in der verschiedene Objekte, wie ein Haus, ein Auto, Geld, ein Flugzeug oder ein Bier, auf einer Skala von hohem bis niedrigem Wert und Kosten eingeteilt werden. Diese Matrix hilft dabei, den relativen Nutzen oder den Aufwand für die Umsetzung eines Projekts oder Features besser zu verstehen.
Die Matrix bewertet jedes Item nach zwei wesentlichen Kriterien:
Wert: Wie viel Nutzen oder Mehrwert bringt das Item oder Feature? Zum Beispiel könnte ein Feature, das signifikanten Umsatz generiert oder die Kundenbindung stärkt, als wertvoller eingestuft werden.
Kosten: Welche Ressourcen werden benötigt, um das Item oder Feature zu realisieren? Hierbei werden sowohl finanzielle als auch zeitliche oder personelle Ressourcen berücksichtigt.
Die Matrix ordnet diese Kriterien in Quadranten, die visuell aufzeigen, wie Items im Verhältnis zueinander stehen. Ein Haus beispielsweise symbolisiert in der Matrix ein Item mit hohem Wert und hohen Kosten, während ein Bier für ein Item mit niedrigem Wert und geringen Kosten steht.
Beispiel für die Anwendung
In der Praxis kann eine Priorisierungsmatrix helfen, Teams dabei zu unterstützen, Entscheidungen darüber zu treffen, welche Features oder Projekte zuerst umgesetzt werden sollten. Features mit hohem Wert und geringen Kosten haben eine hohe Priorität, während Projekte mit hohen Kosten und geringem Wert möglicherweise verschoben oder eliminiert werden.
Durch die Visualisierung der Wert-Kosten-Relation kann das Team effizienter planen und Ressourcen optimal nutzen, um maximale Wirkung zu erzielen.
Bewertung von Backlog-Items
Um den Wert eines Backlog-Items zu bewerten, gibt es verschiedene Ansätze, die sowohl auf Daten als auch auf strategischen Überlegungen basieren. Hier sind einige Methoden, um den Wert eines Items zu ermitteln:
Datenbasierte Ansätze
Ermitteln der möglichen Umsatzsteigerung: Hierbei wird analysiert, wie stark das Feature oder Item den Umsatz des Produkts oder der Dienstleistung steigern kann. Es geht um konkrete Prognosen, wie sich das Item auf das Geschäftsergebnis auswirkt.
Ermitteln des Potenzials zur Kundenbindung: Es wird bewertet, inwiefern das Backlog-Item die Loyalität bestehender Kunden stärkt oder die Wahrscheinlichkeit erhöht, dass Kunden weiterhin Produkte oder Dienstleistungen nutzen. Ein Feature, das die Nutzererfahrung verbessert, könnte beispielsweise langfristige Kundenbindung fördern.
Strategiebasierte Ansätze
Bewertung der strategischen Bedeutung: Hier wird geschaut, wie gut das Item zur übergeordneten Strategie des Unternehmens passt. Beispielsweise könnten Features, die das Unternehmen in neuen Märkten positionieren oder Wettbewerbsvorteile schaffen, einen höheren Wert haben.
Langfristige Marktpositionierung: Manche Features sind entscheidend für die langfristige Marktstrategie, auch wenn sie kurzfristig keinen direkten Umsatz bringen. Diese strategische Relevanz wird bei der Bewertung des Werts berücksichtigt.
Stakeholder-Befragung
Persönliche Bewertung der Items durch Stakeholder: Stakeholder können direkt befragt werden, welche Items sie für besonders wertvoll halten. Diese subjektiven Einschätzungen geben Einblick in die Präferenzen und Prioritäten der Stakeholder.
Nutzung von Techniken wie Value Poker: Mit dieser Technik, ähnlich wie Planning Poker, können Stakeholder und das Team gemeinsam den Wert eines Items diskutieren und basierend auf ihren Einschätzungen Punkte vergeben. Dies hilft, einen Konsens über den Wert zu finden und gleichzeitig verschiedene Perspektiven einzubeziehen.
Diese Ansätze bieten eine flexible Möglichkeit, den Wert eines Backlog-Items zu bewerten, indem sie sowohl quantitative Daten als auch qualitative Einschätzungen kombinieren.
Forecasting
Für einen Product Owner spielt Forecasting eine zentrale Rolle, um verschiedene Stakeholder rechtzeitig und zuverlässig über den Fortschritt und die voraussichtlichen Lieferzeiten zu informieren. Die Fähigkeit, realistische Prognosen zu treffen, ist entscheidend, um Planungen zu erleichtern, Abhängigkeiten zu klären und Vertrauen in den Entwicklungsprozess zu stärken.
Warum Forecasting?
Verschiedene Interessengruppen haben unterschiedliche Bedürfnisse, die mit einem soliden Forecast unterstützt werden können:
- Auftraggeber: Auftraggeber benötigen genaue Vorhersagen, um Abhängigkeiten in der eigenen Arbeitsplanung zu berücksichtigen. Sie müssen wissen, wann bestimmte Features oder Produkte lieferbereit sind, um ihre eigenen Projekte zu koordinieren.
- Kunden: Kunden möchten Anwenderschulungen planen, die rechtzeitig zur Produktveröffentlichung stattfinden müssen. Ein verlässliches Forecasting gibt ihnen die Sicherheit, ihre Ressourcen entsprechend einzusetzen.
- Tribe-Lead: Im agilen Kontext, z.B. in einer größeren Organisation mit Tribes, benötigt der Tribe-Lead den Forecast zur Abrechnung der Entwicklung und zur Ressourcenplanung.
- Vertrieb und Marketing: Für Vertrieb und Marketingteams ist das Forecasting entscheidend, um Abhängigkeiten in ihrer eigenen Arbeitsplanung zu berücksichtigen. Sie müssen wissen, wann sie Werbemaßnahmen, Produkteinführungen und Kampagnen planen können.
- Förderungsbehörden: In einigen Fällen sind Unternehmen auf staatliche Fördermittel angewiesen, die von einem rechtzeitigen Fortschritt abhängen. Forecasting unterstützt die Kommunikation mit Förderungsbehörden und beeinflusst, ob Finanzmittel zugesagt oder abgesagt werden.
- Eigenes Team: Auch das Entwicklungsteam selbst muss wissen, wo es steht. Ein gutes Forecasting hilft dem Team, den Fortschritt zu bewerten und besser zu planen, welche Aufgaben wann abgeschlossen werden können.
- Entwicklungsleiter: Die Planung neuer Projektvorhaben erfordert eine genaue Einschätzung, wann bestehende Projekte abgeschlossen sind. Der Entwicklungsleiter kann auf Basis der Forecasts die nächsten Schritte und Ressourcen einplanen.
- Benutzer/Konsument: Endnutzer oder Kunden, die auf das Produkt warten, benötigen ebenfalls Forecasts, um ihre eigene Verwendungsplanung zu gestalten. Sie möchten wissen, wann sie mit neuen Funktionen oder Updates rechnen können.
- Externe Dienstleister: Auch externe Dienstleister sind oft abhängig von den Lieferzeiten und benötigen Forecasts, um ihre eigenen Abhängigkeiten in der Arbeitsplanung zu berücksichtigen. Verzögerungen können zu Kosten und ineffizienter Ressourcenplanung führen.
- Operations-/Deployment-Teams: Für den operativen Betrieb und das Deployment müssen Teams wissen, wann die Entwicklung abgeschlossen ist, um ihre eigenen Deployment-Pläne zu organisieren und sicherzustellen, dass alle technischen Anforderungen rechtzeitig erfüllt sind.
- Andere Teams: In größeren Unternehmen arbeiten oft mehrere Teams parallel, und Abhängigkeiten zwischen den Teams können das Projekt beeinflussen. Ein verlässlicher Forecast hilft diesen Teams, ihre eigenen Abhängigkeiten in der Planung zu koordinieren.
Forecasting stellt sicher, dass alle Beteiligten mit den richtigen Informationen ausgestattet sind, um ihre jeweiligen Pläne entsprechend zu justieren. Dies schafft Transparenz und hilft, Engpässe oder Verzögerungen frühzeitig zu identifizieren und entsprechend gegenzusteuern.
Wie funktioniert Forecasting?
Ein verlässliches Forecasting als Product Owner basiert auf der Velocity des Teams, also der Menge an Story Points, die in einem Sprint abgeschlossen wird. Die durchschnittliche Velocity der vergangenen Sprints gibt einen guten Anhaltspunkt dafür, wie viel Arbeit in den kommenden Sprints voraussichtlich erledigt werden kann. Dies ermöglicht es, eine zeitliche Schätzung zu erstellen, indem die Backlog-Items auf Grundlage der Priorität auf die Sprints verteilt werden.
Ansatz zur zeitlichen Schätzung
- Was kannst du mir in 10 Wochen liefern?
Hier wird basierend auf der bisherigen Velocity ermittelt, welche Backlog-Items in 10 Wochen abgeschlossen sein könnten. Dazu zieht man die durchschnittliche Velocity heran und prüft, wie viele Story Points in den nächsten Sprints bewältigt werden können. - Wann kannst du alles liefern?
In diesem Fall wird berechnet, wie lange es dauert, um alle offenen Backlog-Items zu erledigen. Hierzu teilt man die Gesamtsumme der Story Points im Backlog durch die durchschnittliche Velocity pro Sprint, um den erforderlichen Zeitraum zu bestimmen.
Herausforderung mit der Verwendung der durchschnittlichen Velocity
Ein Problem bei der Nutzung der durchschnittlichen Velocity ist, dass Varianzen in der Teamleistung nicht ausreichend berücksichtigt werden, insbesondere wenn die Berechnung nur auf wenigen Sprints basiert. Daher gilt: Je mehr Sprints in die Berechnung der Velocity einfließen, desto genauer wird die Vorhersage. Ein grober Richtwert besagt, dass etwa 8 Sprints zur Berechnung der durchschnittlichen Velocity einbezogen werden sollten, um eine zuverlässige Schätzung zu erhalten.
Verbesserter Ansatz: Worst Case, Average, Best Case
Anstelle der ausschließlichen Nutzung des Durchschnittswerts der Velocity kann es hilfreich sein, mit verschiedenen Szenarien zu arbeiten:
- Worst Case: Nutzung der niedrigsten Velocity der letzten Sprints.
- Average Case: Durchschnittliche Velocity über mehrere Sprints.
- Best Case: Nutzung der besten Velocity, um die maximale Leistung des Teams zu berücksichtigen.
Diese Methode gibt ein breiteres Spektrum an möglichen Lieferzeiten und berücksichtigt sowohl Optimismus als auch Risiken besser.
Unsicherheit bei der Aufwandsschätzung
Trotz aller Berechnungen bleibt eine gewisse Unsicherheit bestehen, vor allem durch die Aufwandsschätzungen für zukünftige Storys. Hier kann es hilfreich sein, Storys aus vergangenen Sprints als Vergleich heranzuziehen, um eine realistischere Einschätzung zu erhalten. Dies hilft, extreme Abweichungen in der Schätzung zu vermeiden und gibt einen besseren Anhaltspunkt für zukünftige Forecasts.
Warum Storypoints und nicht Personenstunden/-tage?
- Story Points bieten eine abstrakte Gewichtung und berücksichtigen sowohl den Schwierigkeitsgrad als auch die Unsicherheit und Komplexität einer Aufgabe, ohne direkt die Zeit einzubeziehen.
- Die Abarbeitungsgeschwindigkeit eines Teams kann sich über die Zeit ändern, z.B. durch externe Faktoren, Teamdynamik oder unvorhergesehene Hindernisse. Story Points helfen, diese Schwankungen von der Aufwandsschätzung zu trennen.
- Schätzungen in Personenstunden oder -tagen sind oft fehleranfällig, da Menschen dazu neigen, die benötigte Zeit zu unterschätzen und Faktoren wie Unvorhergesehenes oder Pausen nicht ausreichend zu berücksichtigen.
- Story Points erlauben es dem Team, Aufgaben im relativen Aufwand zueinander zu bewerten, anstatt auf exakte Zeitschätzungen angewiesen zu sein, die variieren können.
- Mit Story Points ist die Velocity eines Teams leichter zu berechnen, was zukünftiges Forecasting ermöglicht, ohne dass man ständig die Zeit neu bewerten muss.
- Scrum lässt die Wahl zwischen zeitbasierten Schätzungen und Story Points offen, aber Story Points fokussieren mehr auf den tatsächlichen Wert und Umfang der Arbeit, unabhängig von der individuellen Leistung einzelner Teammitglieder.
- Sie schaffen Transparenz im Team und sorgen für realistischere Erwartungen bei der Sprintplanung.
Release Burn Up Chart
Das Release Burn Up Chart ist ein visuelles Werkzeug, das beim Forecasting im agilen Entwicklungsprozess hilft. Es zeigt den Fortschritt eines Projekts in Bezug auf die Gesamtmenge der zu erledigenden Arbeit und gibt dabei eine klare Darstellung der bereits abgeschlossenen Aufgaben im Vergleich zu den noch verbleibenden.
Aufbau und Funktion des Charts
- Vertikale Achse (Anzahl der Items): Auf dieser Achse wird die Anzahl der zu erledigenden Items, wie User Stories oder Features, dargestellt.
- Horizontale Achse (Zeit): Die Zeitachse repräsentiert die Dauer des Projekts, von Beginn bis zur geplanten Fertigstellung.
- Linie für gelieferte Items: Diese Linie zeigt den kumulierten Fortschritt der erledigten Arbeit über die Zeit. Mit jedem Sprint oder Arbeitszyklus steigt die Anzahl der abgeschlossenen Items.
- Linie für Gesamtsumme der Items: Diese horizontale Linie zeigt die Gesamtzahl der Items, die für den Release geplant sind. Sie dient als Zielwert für das Projekt.
Visualisierung des Forecastings
Das Chart visualisiert, wie viel Arbeit bereits erledigt wurde und wie viel noch aussteht. Dies macht es besonders nützlich für Stakeholder, die den Fortschritt des Projekts leicht nachvollziehen möchten. Es hilft dabei, zu zeigen, ob das Team auf Kurs ist, um die gesetzten Ziele zu erreichen, oder ob es zu Verzögerungen kommen könnte.
Punkte für Vorhersagen (dotted lines): Oft werden mögliche Szenarien durch gestrichelte Linien dargestellt, die basierend auf der bisherigen Geschwindigkeit (Velocity) des Teams zukünftige Fortschritte visualisieren. Diese Szenarien könnten den Best Case, den Average Case und den Worst Case abbilden und zeigen so, in welchen Zeiträumen die Fertigstellung realistisch erwartet werden kann.
Vorteile des Release Burn Up Charts
Das Chart ist besonders nützlich, weil es leicht verständlich ist, auch für Personen außerhalb des Entwicklungsteams. Es macht den Fortschritt und mögliche Engpässe oder Verzögerungen auf einen Blick sichtbar und hilft, Abhängigkeiten zu erkennen. Dadurch können externe Stakeholder besser planen und verstehen, wie nah das Team der Fertigstellung eines Projekts ist.
Forecasting ohne Erfahrungswerte
Das Forecasting ohne Erfahrungswerte stellt eine besondere Herausforderung dar, da keine verlässlichen Daten aus früheren Sprints oder Projekten vorliegen, auf die man sich stützen kann. Für Stakeholder, die auf genaue Prognosen angewiesen sind, reicht es oft nicht, zu sagen, dass diese Daten fehlen. Es gibt jedoch einige Ansätze, um ein grobes Forecasting auch in dieser Situation zu ermöglichen.
Kommunikation des Problems
Zunächst ist es wichtig, transparent zu kommunizieren, dass dem Team Erfahrungswerte für eine genaue Prognose fehlen. Dies kann verständlicherweise zu Frustration bei den Stakeholdern führen, die eine klare Einschätzung der Projektzeitpläne erwarten. Dennoch schafft eine ehrliche Kommunikation Vertrauen und zeigt, dass das Team sich der Unsicherheiten bewusst ist.
Schätzwert als erster Ansatz
Eine Möglichkeit, trotz fehlender Daten zu starten, besteht darin, einen einfachen Schätzwert basierend auf dem Umfang der Arbeit und der bisherigen Teamleistung zu verwenden. Dieser initiale Wert kann im Laufe des Projekts angepasst werden, sobald mehr Daten und Erfahrungen zur Verfügung stehen. Dies bietet eine Grundlage für Gespräche, auch wenn dieser Schätzwert möglicherweise ungenau ist.
Problem: Ungenauigkeit –> Der Nachteil dieser Methode ist, dass der Wert schnell falsch sein kann, da keine genauen Daten vorliegen. Wenn der Schätzwert zu optimistisch oder zu pessimistisch ist, kann dies zu Missverständnissen und Planungsproblemen führen.
Mögliche Lösung: Frühere Erfahrungswerte nutzen
Eine Lösung besteht darin, die Erfahrungswerte früherer Projekte der Teammitglieder einzubeziehen. Wenn Teammitglieder bereits ähnliche Projekte durchgeführt haben, können diese Informationen genutzt werden, um die aktuelle Planung besser zu schätzen. Dies gibt zumindest eine grobe Vorstellung davon, wie schnell das Team arbeiten kann, bis valide Velocity-Daten aus dem aktuellen Projekt gesammelt werden.
Product Vision
Eine Produktvision beschreibt das langfristige Ziel und den Zweck eines Produkts und gibt eine klare Vorstellung davon, welchen Mehrwert es für die Nutzer und das Unternehmen schaffen soll. Sie dient als Richtlinie für das gesamte Team, indem sie die Richtung für die Entwicklung vorgibt und dabei hilft, Entscheidungen zu treffen, die mit dem übergeordneten Ziel übereinstimmen. Die Produktvision sorgt außerdem dafür, dass alle Beteiligten, von Entwicklern bis zu Stakeholdern, ein gemeinsames Verständnis des Produkts und seiner Zielsetzung haben.
Was ist überhaupt ein Produkt?
Was genau ein Produkt ist, lässt sich am besten mit dem obigen Bild von einem Venn-Diagramm zeigen, das versucht zu erklären, was ein Produkt ist, indem drei Hauptbereiche dargestellt werden:
Wirtschaftlich: Produkte müssen wirtschaftlich sein, d.h. sie müssen Einnahmen oder finanzielle Vorteile für das Unternehmen generieren. Wenn ein Produkt nur wirtschaftlich ist, aber keine Bedürfnisse erfüllt oder nicht umsetzbar ist, kann es als „Betrug“ betrachtet werden.
Machbar: Ein Produkt muss technisch und praktisch realisierbar sein. Produkte, die machbar, aber nicht wirtschaftlich oder nützlich für den Kunden sind, können zu Fehlschlägen führen. In dieser Kombination entstehen Illusionen oder Innovationen, die möglicherweise keine Marktnachfrage haben.
Kundenbedürfnisse: Ein Produkt muss auf reale Kundenbedürfnisse eingehen. Wenn das Produkt den Kundenbedürfnissen entspricht, aber weder wirtschaftlich ist noch machbar umgesetzt werden kann, bleibt es ebenfalls nur eine Illusion.
Das Zentrum des Diagramms, wo alle drei Bereiche (wirtschaftlich, machbar und kundenorientiert) zusammenkommen, zeigt ein erfolgreiches Produkt, das sich nicht nur um Gewinn dreht, sondern auch um Kundenbindung, Innovation und Non-Profit-Ziele.
Dieses Modell verdeutlicht, dass ein gutes Produkt stets das Gleichgewicht zwischen den Bereichen Kundenbedürfnis, Machbarkeit und Wirtschaftlichkeit finden muss, um wirklich erfolgreich zu sein.
Was macht eine Gute Produktvision aus?
Das Product Vision Board
Der Elevator-Pitch
User Story Mapping
Hauptkomponenten einer User Story Map
Wirkungsschnitte
Vorteile von Story Mapping
- Verbesserte Nutzerzentrierung: Durch die Visualisierung der gesamten Nutzerreise stellt User Story Mapping sicher, dass die Perspektive der Nutzer während des gesamten Entwicklungsprozesses im Zentrum steht. Jede User Story wird im Kontext dessen betrachtet, wie sie zur Gesamterfahrung des Nutzers beiträgt. Dies trägt dazu bei, Produkte zu schaffen, die echte Nutzerprobleme lösen und einen tatsächlichen Wert bieten.
- Erleichterung der Priorisierung: User Story Maps helfen dabei, die wichtigsten Aspekte eines Produktes hervorzuheben. Teams können leicht erkennen, welche Funktionen für die Erreichung der Kernziele des Nutzers unerlässlich sind und welche Features nur nett zu haben sind. Diese Klarheit unterstützt das Team dabei, Ressourcen auf die wichtigsten Aufgaben zu konzentrieren und so einen effizienten Entwicklungsprozess zu fördern.
- Förderung des Teamverständnisses und der Zusammenarbeit: Da User Story Maps eine übersichtliche und gemeinsam genutzte Darstellung des Projektplans ermöglichen, erleichtern sie die Kommunikation im Team und mit Stakeholdern. Sie schaffen ein gemeinsames Verständnis dafür, was entwickelt wird und warum, was zu einer besseren Zusammenarbeit und weniger Missverständnissen führt.
- Identifizierung von Lücken und Überschneidungen: Durch das Mapping können Teams Lücken in der Nutzerreise entdecken, die ohne eine visuelle Darstellung möglicherweise übersehen worden wären. Gleichzeitig können redundante oder sich überschneidende Funktionen identifiziert und bereinigt werden, was die Effizienz und Kohärenz des Endprodukts verbessert.
- Flexibilität in der Planung: User Story Maps sind dynamisch und können während des Projekts angepasst werden, um Veränderungen im Verständnis oder in den Anforderungen der Nutzer zu reflektieren. Dies macht sie zu einem idealen Werkzeug für agile Teams, die schnell auf Feedback reagieren und iterative Verbesserungen vornehmen müssen.
- Unterstützung iterativer Entwicklung: Die Aufteilung der Geschichte in kleinere, handhabbare User Stories ermöglicht es Teams, in iterativen Zyklen zu arbeiten. Das bedeutet, dass Teams einen schrittweisen Ansatz für die Entwicklung verfolgen können, bei dem regelmäßig überprüfbare Fortschritte erzielt werden.
- Effiziente Release-Planung: Mit der Möglichkeit, User Stories in geplante Releases zu gruppieren, können Teams effektivere Roadmaps erstellen und den Stakeholdern klare Erwartungen setzen. Die Release-Planung wird durch das direkte Mapping von Stories zu den jeweiligen Releases erleichtert und macht den Fortschritt sowie die Abhängigkeiten transparent.
Definition of Ready und Definition of Done
Definition of Ready (DoR)
Die „Definition of Ready“ legt fest, wann ein Backlog-Item, wie beispielsweise eine User Story, bereit für die Aufnahme in einen Sprint ist. Es ist ein Checklistenansatz, der sicherstellt, dass alle notwendigen Voraussetzungen erfüllt sind, damit das Team mit der Arbeit an dem Item beginnen kann. Die DoR hilft dabei, Missverständnisse zu vermeiden und sorgt für eine effiziente und effektive Umsetzung der Arbeit, indem sie klarstellt, dass das Item gut verstanden, durchführbar und testbar ist.
Beispiel einer guten Definition of Ready:
- Die User Story ist klar und verständlich formuliert.
- Akzeptanzkriterien sind definiert und von Product Owner und Team abgestimmt.
- Alle Abhängigkeiten und Schnittstellen sind identifiziert und geklärt.
- Die notwendigen Design-, UX- und technischen Informationen sind verfügbar.
- Das Item ist vom Team hinsichtlich seiner Machbarkeit bewertet worden.
- Die Story ist in Aufgaben von einer Größe geschätzt, die innerhalb eines Sprints umsetzbar ist.
Definition of Done (DoD)
Die „Definition of Done“ ist eine formale Vereinbarung darüber, was es bedeutet, wenn ein Team sagt, dass eine Arbeit „fertig“ ist. Dies kann sich auf Features, User Stories, Sprints oder Releases beziehen. DoD ist ein entscheidender Faktor für die Transparenz und Qualität im Entwicklungsprozess und stellt sicher, dass alle wissen, wann ein Item wirklich fertiggestellt ist und keine weiteren Arbeiten oder Nachbesserungen notwendig sind.
Beispiel einer guten Definition of Done:
- Code ist geschrieben und entspricht den Coding Standards.
- Code Reviews sind abgeschlossen und alle Feedbackpunkte umgesetzt.
- Alle definierten Unit-Tests sind geschrieben und erfolgreich durchgeführt.
- Integrationstests sind abgeschlossen und erfolgreich.
- Die Dokumentation ist aktualisiert und überprüft.
- Das Feature ist auf der Staging-Umgebung bereitgestellt und von der QA abgenommen.
- Alle Akzeptanzkriterien der User Story sind erfüllt.
Entwicklung einer Definition of Done
- Perfekte Definition zusammenstellen: Zu Beginn wird eine umfassende und ideale Definition of Done erarbeitet, die alle Anforderungen und Qualitätsstandards beinhaltet, um ein perfektes Endergebnis sicherzustellen.
- Heute lebbare Definition of Done extrahieren: Aus der idealen Version wird eine pragmatische und umsetzbare Definition abgeleitet, die dem aktuellen Entwicklungsstand und den Ressourcen des Teams entspricht und sofort anwendbar ist.
- Teamentwicklungspfad vereinbaren: Das Team entwickelt gemeinsam einen schrittweisen Plan, um die DoD kontinuierlich in Richtung der idealen Definition zu erweitern und zu verbessern, um langfristig höhere Qualitätsstandards zu erreichen.
Definition of Done vs. Akzeptanzkriterien
Zur Gegenüberstellung der Definition of Done und Akzeptanzkriterien können wir uns das folgende Diagramm ansehen:
Der obere Teil des Bildes die unterschiedlichen Defintionen und die Abgrenzung zwischen der DoD und Akzeptanzkriterien.
- Definition of Done (DoD): Dies ist eine allgemeingültige und für das gesamte Team einheitliche Beschreibung, die festlegt, wann ein Backlog-Item als fertig betrachtet werden kann. Die DoD gilt für alle Backlog-Items und umfasst oft Aspekte wie Dokumentation, Tests, Code-Reviews oder technische Anforderungen, die immer erfüllt sein müssen, bevor etwas als „done“ markiert wird.
- Akzeptanzkriterien: Diese sind spezifisch für jedes einzelne Backlog-Item. Sie legen fest, welche spezifischen Anforderungen oder Bedingungen erfüllt sein müssen, damit das Item als fertig angesehen wird. Diese Kriterien variieren je nach Item und sind individuell an die Funktionalität oder den Use Case angepasst.
Der untere Teil des Diagramms zeigt den Unterschied zwischen einem klassischen Wasserfall-Ansatz und dem Scrum-Modell.
- Klassisch: Im klassischen Modell wird die Arbeit kontinuierlich aufgestaut, bis zum Zeitpunkt eines großen Releases. Die Linie zeigt, wie unerledigte Arbeit während des Projekts ansteigt und erst am Ende mit einem Release abgeschlossen wird. In diesem Modell besteht das Risiko, dass am Ende des Projekts viele unvorhergesehene Arbeiten oder Fehler auftauchen, die noch erledigt werden müssen.
- Scrum: Im Scrum-Modell wird in Sprints gearbeitet, wobei am Ende jedes Sprints ein potenziell lieferbares Produktinkrement bereitsteht. Diese inkrementelle Lieferung von fertigen Aufgaben (in blauen Sprints dargestellt) führt dazu, dass die unerledigte Arbeit deutlich geringer bleibt und kontinuierlich bearbeitet wird, sodass es keine große Ansammlung an Arbeit bis zum Release gibt.
Wie wird man Product Owner?
Wenn du Product Owner werden möchtest, gibt es einige wichtige Schritte, die du befolgen solltest. Zunächst ist es hilfreich, Erfahrung in der Produktentwicklung oder im Projektmanagement zu sammeln, idealerweise in einem agilen Umfeld wie Scrum. Du musst lernen, wie man Anforderungen verwaltet, Prioritäten setzt und effektiv mit Stakeholdern kommuniziert, da der Product Owner die Brücke zwischen dem Entwicklungsteam und den Stakeholdern darstellt.
Ein nächster Schritt wäre, dich in den agilen Methoden weiterzubilden und eventuell eine Zertifizierung wie den Certified Scrum Product Owner (CSPO) zu machen. Diese Zertifizierung vermittelt dir die wichtigsten Prinzipien von Scrum und den spezifischen Aufgaben, die du als Product Owner übernimmst.
Wichtig ist auch, dass du deine Kommunikations- und Entscheidungsfähigkeiten weiterentwickelst, da du regelmäßig zwischen unterschiedlichen Interessen vermitteln musst. Du wirst auch mit User Stories, Backlog-Management und agilen Tools wie Jira oder Trello arbeiten, also wäre es sinnvoll, dich mit diesen Tools vertraut zu machen.
Du kannst auch als Scrum Master oder in einer anderen Rolle im Produktmanagement beginnen, um erste Erfahrungen im agilen Umfeld zu sammeln und deine Fähigkeiten Schritt für Schritt zu erweitern.
Ergänzung: Ein Scrum-Überblick
Warum Agile?
- Schnelle Reaktion auf Kundenbedürfnisse: Agile Methoden ermöglichen es, kontinuierlich auf Kundenfeedback einzugehen und Produkte oder Dienstleistungen gezielt an deren Wünsche anzupassen.
- Flexibilität bei Anpassungen: In einem agilen Umfeld können Veränderungen in Projekten flexibel und zeitnah umgesetzt werden, ohne den gesamten Ablauf zu stören.
- Verkürzte Time-to-Market: Durch die iterative Arbeitsweise in kurzen Entwicklungszyklen können Produkte schneller auf den Markt gebracht und frühzeitig auf ihre Markttauglichkeit geprüft werden.
- Effiziente Reaktion auf Änderungen: Agile Teams sind darauf ausgelegt, unerwartete Änderungen frühzeitig zu erkennen und diese effizient in den Prozess zu integrieren, was die Anpassungsfähigkeit gegenüber dynamischen Anforderungen steigert.
Verantwortlichkeiten
- Product Owner: Verantwortlich für die Maximierung des Wertes des Produktes und die Verwaltung des Product Backlogs.
- Scrum Master: Unterstützt das Scrum Team, indem er hilft, Scrum-Praktiken zu verstehen und umzusetzen, und arbeitet daran, Hindernisse zu beseitigen.
- Entwickler: Sie bilden das Team, das die Arbeit erledigt, um die Sprintziele zu erreichen, indem sie inkrementelle Produktverbesserungen während jedes Sprints liefern.
Aktivitäten
- Sprint: Eine zeitlich begrenzte Iteration von in der Regel 2-4 Wochen, in dem ein nutzbares und potenziell auslieferbares Produktinkrement erstellt wird.
- Sprint Planning: Ein Meeting zu Beginn jedes Sprints, in der das Team plant, was im kommenden Sprint erreicht werden kann, und wie diese Arbeit umgesetzt wird.
- Daily Scrum: Ein tägliches kurzes Treffen für das Entwicklungsteam, um Fortschritte zu teilen, den nächsten Tag zu planen und Hindernisse zu identifizieren.
- Sprint Review: Eine Sitzung am Ende des Sprints, um das fertige Produktinkrement zu überprüfen und Feedback zu sammeln, um das nächste Sprint Planning zu informieren.
- Sprint Retrospektive: Ein Treffen nach dem Sprint Review, um zu diskutieren, was gut lief, was verbessert werden könnte und wie man in den nächsten Sprint Verbesserungen umsetzen kann.
- Product Backlog Refinement: Der Prozess der Überarbeitung des Product Backlogs, um sicherzustellen, dass es klar, detailliert und verstanden ist.
Artefakte
- Product Backlog: Eine geordnete Liste aller Dinge, die für das Produkt benötigt werden, und eine lebendige Quelle der Anforderungen für alle Änderungen am Produkt.
- Sprint Backlog: Eine Liste von Aufgaben, die das Team im aktuellen Sprint abschließen will, ausgewählt aus dem Product Backlog.
- Auslieferbares Produktinkrement: Ein konkretes Ergebnis eines Sprints, das in einem stabilen, nutzbaren Zustand ist und dem Endbenutzer Wert bietet.
Commitments
- Produktziel: Ein langfristiges Ziel für das Produkt, das dem Scrum Team Richtung und Zweck gibt.
- Sprintziel: Ein konkretes Ziel für den Sprint, auf das sich das Team verpflichtet, was eine klare Richtung und Fokus bietet.
- Definition of Done: Eine vereinbarte Liste von Kriterien, die erfüllt sein müssen, damit eine Aufgabe oder ein Produktinkrement als abgeschlossen betrachtet werden kann.
Werte
- Commitment: Das Engagement des Teams, die gesteckten Ziele zu erreichen und zur kontinuierlichen Verbesserung beizutragen.
- Respekt: Jedes Teammitglied respektiert sich gegenseitig, ihre verschiedenen Fähigkeiten und Standpunkte.
- Offenheit: Das Team ist offen für Veränderungen, Feedback und Diskussionen über Herausforderungen.
- Fokus: Das Team konzentriert sich auf die Sprintziele und die Aufgaben, die vor ihnen liegen.
- Mut: Das Team hat den Mut, Herausforderungen anzugehen, schwierige Entscheidungen zu treffen und Innovationen voranzutreiben.
Letzte Aktualisierung am 25.08.2026 / Affiliate Links / Bilder von der Amazon Product Advertising API
