2Cycles Model

Im Folgenden erfolgt eine strukturierte Übersicht von möglichen Chunks. Natürlich ist keine Liste jemals vollständig und es bleibt immer ein gewisser Interpretationsspielraum, ob man Elemente nochmals feiner zerlegen könnte. Aber es ist eine fundierte Grundlage, um sich einzelne Bausteine aus unterschiedlichen agilen Ansätzen herauszupicken und nach Bedarf zu kombinieren.

Daily Scrum (Daily Stand-up)

Kurzmeeting (max. 15 Min.), in dem jedes Teammitglied den aktuellen Stand, Hindernisse und geplante Arbeit teilt.
Wann: In Scrum-Teams oder vergleichbaren Umgebungen, bei denen tägliche Synchronisation notwendig ist.
Warum: Um den aktuellen Stand, Hindernisse und geplante Arbeit innerhalb des Teams effizient auszutauschen. Voraussetzungen - Cross-funktionales Team: Alle relevanten Teammitglieder sollten anwesend sein, die aktiv an der Sprint-Arbeit beteiligt sind. - Definition des Ziels: Klarheit über das Sprint-Ziel, damit das Meeting zielgerichtet bleibt. - Timeboxing: Strikte Einhaltung der maximalen Dauer (15 Minuten).

Wie erkennt man, dass es nicht passt? - Overhead: Wenn der Daily Scrum länger als 15 Minuten dauert, deutet das auf mangelnde Vorbereitung oder irrelevante Diskussionen hin. - Fehlender Fokus: Wird das Meeting als Statusbericht für den Manager statt als Team-Synchronisation genutzt, passt es nicht mehr in den agilen Kontext. - Routine ohne Mehrwert: Wenn Teammitglieder den Eindruck haben, das Meeting bringt keine neuen Erkenntnisse, ist die Struktur zu hinterfragen.

Sprint Planning

Gemeinsames Planungsmeeting zu Beginn eines Sprints, in dem das Team sich auf die Inhalte und Ziele (Sprint-Ziel) einigt.
Wann: Zu Beginn jedes Sprints, um die Arbeit für den kommenden Sprint zu planen. Warum: Es hilft dem Team, sich auf ein klar definiertes Sprint-Ziel zu fokussieren und sicherzustellen, dass die ausgewählten Backlog-Einträge machbar sind. Voraussetzungen - Klar priorisierter Product Backlog: Der Product Owner muss die Einträge priorisiert und ausreichend vorbereitet haben (Definition of Ready sollte erfüllt sein). - Klarheit über das Sprint-Ziel: Das Team muss verstehen, welchen Mehrwert der Sprint liefern soll. - Kapazitätsplanung: Das Team sollte seine verfügbare Kapazität und eventuelle Einschränkungen (z. B. Urlaub) kennen. Wie erkennt man, dass es nicht passt? - Unvorbereitete Backlog-Einträge: Wenn das Team viel Zeit mit dem Klären von Anforderungen verbringt, sollte ein stärkerer Fokus auf Backlog Refinement gelegt werden. - Keine realistische Planung: Wenn der Plan regelmäßig nicht eingehalten wird, ist die Abschätzung (z. B. Story Points) oder die Berücksichtigung der Team-Kapazität zu überarbeiten. - Fehlende Beteiligung: Wenn nur der Product Owner oder der Scrum Master spricht und das Team passiv bleibt, ist das Prinzip der Teamverantwortung gefährdet.

Sprint Review

Meeting zum Ende eines Sprints, um das Inkrement (fertige Arbeit) gemeinsam zu begutachten und Feedback von Stakeholdern einzuholen.
Wann: Am Ende jedes Sprints, um das erreichte Inkrement zu präsentieren und Feedback von Stakeholdern einzuholen. Warum: Es fördert Transparenz, bindet Stakeholder in die Entwicklung ein und ermöglicht iterative Anpassungen basierend auf aktuellem Feedback. Voraussetzungen - Ein fertiges Inkrement: Die Arbeit im Sprint muss gemäß der Definition of Done abgeschlossen sein und präsentierbar sein. - Stakeholder-Beteiligung: Relevante Stakeholder müssen eingeladen werden, um Feedback zu geben. - Klare Struktur: Ein klarer Ablaufplan für die Präsentation und Diskussion, um den Fokus auf das Inkrement und dessen Nutzen zu lenken. Wie erkennt man, dass es nicht passt? - Kein fertiges Inkrement: Wenn die Arbeit unvollständig ist, verliert das Meeting seinen Zweck. - Geringe Stakeholder-Beteiligung: Wenn kaum Feedback von Stakeholdern kommt, sollten Einladung, Moderation oder Präsentation überprüft werden. - Reine Statusberichte: Wenn das Review nur als Bericht dient und keine Diskussion oder Interaktion stattfindet, fehlt der iterative Ansatz.

Retrospektive

Regelmäßige Reflexion, wie Zusammenarbeit und Prozesse verbessert werden können. Wann: Nach jedem Sprint, um die Zusammenarbeit, Prozesse und Methoden des Teams zu reflektieren und Verbesserungen zu identifizieren. Warum: Fördert kontinuierliche Verbesserung, stärkt die Teamdynamik und hilft, Hindernisse systematisch zu beseitigen. Voraussetzungen - Psychologische Sicherheit: Teammitglieder müssen offen über Probleme und Herausforderungen sprechen können. - Moderation: Der Scrum Master oder ein erfahrener Moderator sorgt für einen strukturierten Ablauf und vermeidet, dass die Diskussion aus dem Ruder läuft. - Vorbereitung: Daten oder Beobachtungen (z. B. aus Sprint Burndown Charts) sollten verfügbar sein, um eine fundierte Reflexion zu ermöglichen. Wie erkennt man, dass es nicht passt? - Wiederholte Diskussion ohne Fortschritt: Wenn dieselben Probleme immer wieder auftauchen, ohne dass Maßnahmen umgesetzt werden. - Fehlende Beteiligung: Wenn Teammitglieder sich nicht aktiv einbringen, sollte die Ursache (z. B. fehlende Sicherheit, Unklarheit über den Zweck) hinterfragt werden. - Keine Aktionen: Wenn keine konkreten Maßnahmen definiert oder verfolgt werden, verliert die Retrospektive an Relevanz.

Product Backlog

Priorisierte Liste von Anforderungen, User Stories oder Ideen, die vom Product Owner verantwortet wird. Wann: Als zentrale Planungsgrundlage in agilen Projekten, insbesondere bei Scrum. Es wird kontinuierlich gepflegt, um sicherzustellen, dass das Team immer an den wichtigsten und klar definierten Aufgaben arbeitet. Warum: Es hilft, die Arbeit zu priorisieren und die Produktentwicklung an den Bedürfnissen der Stakeholder auszurichten. Voraussetzungen - Product Owner: Eine klare Verantwortlichkeit für die Pflege und Priorisierung des Backlogs. - Definition of Ready: Backlog-Einträge müssen so vorbereitet sein, dass das Team sie problemlos in einem Sprint bearbeiten kann. - Regelmäßiges Refinement: Das Backlog muss kontinuierlich aktualisiert und angepasst werden, um den aktuellen Anforderungen zu entsprechen. Wie erkennt man, dass es nicht passt? - Überfülltes Backlog: Wenn zu viele Einträge enthalten sind, die nie bearbeitet werden, verliert es an Übersichtlichkeit und Nutzen. - Mangelnde Priorisierung: Wenn das Team an weniger wichtigen Aufgaben arbeitet, weil die Prioritäten nicht klar sind. - Unklare Einträge: Wenn Backlog-Einträge nicht ausreichend beschrieben sind, entstehen während der Umsetzung unnötige Verzögerungen.

Sprint Backlog

Auswahl von Product-Backlog-Einträgen, die das Team im laufenden Sprint umsetzen möchte, inklusive Aufgaben. Wann: Während eines Sprints als operative Planungsgrundlage. Es enthält die Backlog-Einträge, die das Team im aktuellen Sprint umsetzen möchte, sowie die dazugehörigen Aufgaben. Warum: Es bietet Transparenz über den Fortschritt innerhalb des Sprints und hilft dem Team, sich auf die Sprint-Ziele zu konzentrieren. Voraussetzungen - Klar priorisierte Backlog-Einträge: Die Einträge müssen gut vorbereitet und durch das Team im Sprint Planning ausgewählt worden sein. - Definition of Done: Das Team muss wissen, wann ein Item als fertig gilt. - Team-Einverständnis: Alle Teammitglieder sollten dem Inhalt des Sprint Backlogs zustimmen und Verantwortung für die Umsetzung übernehmen. Wie erkennt man, dass es nicht passt? - Überladung: Wenn das Backlog mehr Arbeit enthält, als das Team realistischerweise umsetzen kann, deutet das auf unzureichende Kapazitätsplanung hin. - Mangelnde Transparenz: Wenn Aufgaben fehlen oder nicht aktualisiert werden, verliert das Sprint Backlog seinen Zweck. - Unklare Aufgaben: Wenn die Aufgaben zu grob beschrieben sind, entstehen Missverständnisse oder Verzögerungen.

Product Owner

Rolle, die Vision, Priorisierung und wirtschaftlichen Erfolg des Produkts verantwortet. Wann: In Scrum oder ähnlichen Frameworks, um die Vision und Priorisierung des Produkts sicherzustellen. Warum: Der Product Owner sorgt dafür, dass das Team an den wertvollsten Aufgaben arbeitet und die Anforderungen der Stakeholder klar sind. Voraussetzungen - Klare Verantwortlichkeiten: Der Product Owner ist allein für das Management des Product Backlogs verantwortlich. - Enge Zusammenarbeit: Es muss eine regelmäßige Abstimmung mit Stakeholdern und dem Team geben. - Fachliche Kompetenz: Der Product Owner sollte die Marktanforderungen und die Kundenbedürfnisse verstehen.

Wie erkennt man, dass es nicht passt? - Fehlende Entscheidungen: Wenn der Product Owner nicht in der Lage ist, klare Prioritäten zu setzen, entstehen Verzögerungen. - Überforderung: Wenn der Product Owner zu viele Verantwortlichkeiten übernimmt und keine Delegation stattfindet, leidet die Effektivität. - Unzureichende Einbindung: Wenn der Product Owner dem Team keine kontinuierliche Unterstützung bietet, fehlt die Orientierung. -

Scrum Master

Rolle, die das Team in der Anwendung von Scrum unterstützt und Impediments beseitigt. Wann: In Scrum oder ähnlichen agilen Frameworks, um das Team bei der Anwendung von Scrum zu unterstützen und Hindernisse zu beseitigen. Warum: Der Scrum Master hilft, agile Prinzipien und Praktiken effektiv umzusetzen und sorgt für einen reibungslosen Ablauf im Team. Voraussetzungen - Klare Rollendefinition: Der Scrum Master muss als Servant Leader agieren und sollte keine disziplinarische Macht über das Team haben. - Team-Bedarf: Die Rolle ist besonders wertvoll in Teams, die Unterstützung beim Verständnis und der Anwendung agiler Methoden benötigen. - Organisatorische Unterstützung: Der Scrum Master sollte die Freiheit haben, systemische Hindernisse anzusprechen und zu lösen. Wie erkennt man, dass es nicht passt? - Micromanagement: Wenn der Scrum Master das Team kontrolliert, anstatt es zu coachen, wird die Selbstorganisation untergraben. - Passivität: Wenn der Scrum Master Hindernisse nicht aktiv adressiert, leidet die Effektivität des Teams. - Fehlender Fokus: Wenn der Scrum Master andere Verantwortlichkeiten übernimmt (z. B. als Entwickler), kann die Unterstützung des Teams leiden.

Cross-funktionales Dev-Team

Team aus allen nötigen Disziplinen, das selbstorganisiert arbeitet und gemeinsam für das Produktinkrement verantwortlich ist. Wann: In agilen Frameworks wie Scrum, wenn das Team alle notwendigen Fähigkeiten vereinen muss, um ein Produktinkrement eigenständig liefern zu können. Warum: Ein cross-funktionales Team fördert Selbstorganisation, reduziert Abhängigkeiten und ermöglicht eine höhere Geschwindigkeit bei der Lieferung von Inkrementen. Voraussetzungen - Diversität der Fähigkeiten: Das Team muss alle erforderlichen Kompetenzen (z. B. Entwicklung, Testing, Design) abdecken. - Selbstorganisation: Das Team sollte in der Lage sein, Entscheidungen eigenständig zu treffen. - Gemeinsame Ziele: Alle Teammitglieder sollten auf das gleiche Sprint-Ziel hinarbeiten. Wie erkennt man, dass es nicht passt? - Fachliche Lücken: Wenn das Team nicht alle notwendigen Fähigkeiten hat, entstehen Abhängigkeiten zu externen Ressourcen. - Hierarchien: Wenn es innerhalb des Teams klare Hierarchien gibt, wird die Selbstorganisation erschwert. - Mangelnde Zusammenarbeit: Wenn Teammitglieder isoliert arbeiten, gehen Synergien verloren, und die Teamleistung leidet.

Timeboxing

Konsequente Begrenzung von Meetings, Sprints oder Aktivitäten auf festgelegte Zeiträume. Wann: In agilen Frameworks für Meetings, Aktivitäten oder Iterationen, um sicherzustellen, dass Aufgaben in einem definierten Zeitrahmen abgeschlossen werden. Warum: Timeboxing hilft, Fokus zu bewahren, Entscheidungen zu beschleunigen und das Risiko von endlosen Diskussionen zu minimieren. Voraussetzungen - Klare Ziele: Die Aktivität muss ein definiertes Ziel haben, das innerhalb des Zeitrahmens erreicht werden soll. - Disziplin im Team: Das Team muss bereit sein, den Zeitrahmen strikt einzuhalten und den Fokus zu bewahren. - Moderation: Ein Moderator oder Verantwortlicher sollte darauf achten, dass der Zeitrahmen nicht überschritten wird. Wie erkennt man, dass es nicht passt? - Fehlender Fokus: Wenn die Beteiligten den Zeitrahmen nicht sinnvoll nutzen, bleibt das Ergebnis unklar. - Unrealistische Zeitfenster: Wenn der gesetzte Rahmen nicht ausreicht, um sinnvolle Ergebnisse zu erzielen, entsteht Frustration. - Keine Konsequenzen: Wenn Timeboxing nicht konsequent eingehalten wird, verliert es seine Wirkung.

Definition of Done

Gemeinsame Kriterien, wann eine Aufgabe oder ein Feature wirklich „fertig“ ist. Wann: In agilen Projekten, um klar zu definieren, wann eine Aufgabe, ein Feature oder ein Inkrement als „fertig“ gilt. Warum: Es schafft Transparenz, verhindert Missverständnisse und stellt sicher, dass Qualitätssicherungsstandards eingehalten werden. Voraussetzungen - Klare Kriterien: Die DoD muss spezifische, messbare Anforderungen enthalten (z. B. „Code ist getestet und dokumentiert“). - Team-Akzeptanz: Die DoD sollte vom gesamten Team erarbeitet oder zumindest akzeptiert worden sein. - Stakeholder-Transparenz: Alle Stakeholder müssen verstehen, was „fertig“ bedeutet. Wie erkennt man, dass es nicht passt? - Unklare oder zu vage Kriterien: Wenn die Definition zu allgemein ist, entstehen Diskussionen darüber, ob etwas wirklich abgeschlossen ist. - Fehlende Aktualisierung: Wenn die DoD nicht regelmäßig überprüft wird, kann sie veralten und nicht mehr den aktuellen Standards entsprechen. - Inkonsistente Anwendung: Wenn das Team die DoD nur sporadisch anwendet, verliert sie an Verbindlichkeit und Nutzen.

Backlog Refinement (Grooming)

Regelmäßige Überarbeitung und Detaillierung des Product Backlogs, um sicherzustellen, dass es stets aktuell, gut verständlich und priorisiert ist. Wann: Regelmäßig während eines Sprints, um sicherzustellen, dass das Product Backlog aktuell, priorisiert und verständlich ist. Warum: Es hilft dem Team, sich auf kommende Aufgaben vorzubereiten und mögliche Hindernisse frühzeitig zu identifizieren. Voraussetzungen - Regelmäßige Zeitfenster: Refinement sollte als fester Bestandteil des Sprint-Rhythmus etabliert sein. - Beteiligung des Teams: Das Team muss aktiv an der Detaillierung der Einträge beteiligt sein, um ein gemeinsames Verständnis zu gewährleisten. - Vorbereitung durch den Product Owner: Der Product Owner sollte priorisierte Einträge und erste Details bereitstellen. Wie erkennt man, dass es nicht passt? - Unklare Einträge bleiben bestehen: Wenn Refinement keine Klärung bringt, verliert es seinen Zweck. - Übermäßiger Zeitaufwand: Wenn zu viel Zeit auf Refinement verwendet wird, leidet die eigentliche Entwicklungsarbeit. - Keine Teambeteiligung: Wenn der Product Owner oder andere Rollen die Aufgabe allein übernehmen, entsteht ein Mangel an Teamverständnis.

Definition of Ready (DoR)

Gemeinsame Kriterien, wann ein Backlog-Item so klar formuliert und abgestimmt ist, dass das Team es im Sprint bearbeiten kann. Ergänzt die „Definition of Done“ und stellt sicher, dass Storys im richtigen Reifegrad in den Sprint gehen. Wann: Bei der Planung und Pflege des Product Backlogs, um sicherzustellen, dass Einträge so formuliert sind, dass das Team sie bearbeiten kann. Warum: Die DoR minimiert Missverständnisse, vermeidet Verzögerungen während der Sprint-Arbeit und stellt sicher, dass Backlog-Einträge einen klaren Reifegrad haben. Voraussetzungen - Gemeinsame Definition: Die DoR sollte vom Team und dem Product Owner gemeinsam erstellt und regelmäßig überprüft werden. - Klare Kriterien: Sie muss spezifisch und überprüfbar sein (z. B. „Akzeptanzkriterien sind definiert“, „Eintrag ist priorisiert“). - Regelmäßiges Refinement: Die DoR sollte integraler Bestandteil des Backlog Refinements sein. Wie erkennt man, dass es nicht passt? - Unklare Anforderungen: Wenn Einträge trotz DoR immer wieder im Sprint diskutiert und angepasst werden müssen, ist die Definition unzureichend. - Zu strenge Kriterien: Wenn die DoR zu kompliziert ist, kann sie die Flexibilität und den Fluss der Arbeit behindern. - Keine Aktualisierung: Wenn die DoR nicht an veränderte Bedingungen oder neue Erkenntnisse angepasst wird, verliert sie ihre Relevanz.

Sprint Goal

Ein kurzes, fokussierendes Ziel, das dem Team die Richtung für den Sprint gibt und den Wert für Stakeholder verdeutlicht. Wann: Während des Sprint Plannings, um ein klares, gemeinsames Ziel für den Sprint zu definieren. Warum: Es gibt dem Team eine Orientierung, fokussiert die Arbeit und schafft Transparenz für die Stakeholder. Voraussetzungen - Klare Prioritäten: Der Product Owner muss die wichtigsten Backlog-Einträge priorisiert haben, die zum Sprint Goal beitragen. - Team-Einbindung: Das Team sollte aktiv an der Definition des Sprint Goals beteiligt sein, um sicherzustellen, dass es realistisch und erreichbar ist. - Eindeutigkeit: Das Sprint Goal muss prägnant und verständlich formuliert sein. Wie erkennt man, dass es nicht passt? - Zu allgemeine Ziele: Wenn das Sprint Goal vage ist, fehlt dem Team die klare Orientierung. - Keine Relevanz: Wenn das Sprint Goal keinen Mehrwert für die Stakeholder bietet, wird es bedeutungslos. - Ignorierung während des Sprints: Wenn das Team das Ziel aus den Augen verliert und sich auf andere Aufgaben konzentriert, ist das Sprint Goal ineffektiv.

Sprint Burndown / Burnup Charts

Grafische Darstellung, wie sich die abgearbeitete Arbeit entwickelt. Hilft, Trends früh zu erkennen. Wann: Während eines Sprints zur Visualisierung des Fortschritts und zur Früherkennung von Problemen. Warum: Es ermöglicht dem Team, Trends zu erkennen, Transparenz zu schaffen und frühzeitig Anpassungen vorzunehmen. Voraussetzungen - Korrekte Datenerfassung: Alle abgeschlossenen Aufgaben müssen zeitnah aktualisiert werden. - Team-Disziplin: Das Team muss die Fortschrittsanzeige ernst nehmen und regelmäßig reflektieren. - Einheitliche Definitionen: Klare Abgrenzung, wann Aufgaben als „abgeschlossen“ gelten, basierend auf der Definition of Done. Wie erkennt man, dass es nicht passt? - Unregelmäßige Updates: Wenn Aufgaben nicht zeitnah aktualisiert werden, verlieren die Charts an Aussagekraft. - Missinterpretation: Wenn Trends falsch gedeutet werden (z. B. ein Plateau wird als Fehler gewertet statt als komplexe Aufgabe), entsteht unnötiger Druck. - Fehlende Nutzung: Wenn die Charts ignoriert werden oder keine Reflexion anstoßen, erfüllen sie ihren Zweck nicht.

Velocity Tracking

Beobachtung, wie viel „Arbeit“ (Story Points / Items) pro Sprint geschafft wird, um die langfristige Vorhersagbarkeit zu verbessern. Wann: Über mehrere Sprints hinweg, um die Menge an Arbeit zu messen, die ein Team konsistent abschließen kann. Warum: Es dient der Vorhersagbarkeit zukünftiger Arbeit und hilft, realistische Planungen zu erstellen. Voraussetzungen - Konstante Rahmenbedingungen: Das Team sollte in stabilen Bedingungen arbeiten (gleiche Teamgröße, keine externen Störungen), um eine aussagekräftige Velocity zu erhalten. - Gleiche Schätzmethodik: Story Points oder ähnliche Schätzgrößen müssen konsistent genutzt werden. - Längere Beobachtung: Velocity wird erst nach mehreren Sprints aussagekräftig.

Wie erkennt man, dass es nicht passt? - Überbetonung der Velocity: Wenn die Velocity als Leistungsmessung genutzt wird, kann das Team unter Druck geraten und Qualitätseinbußen riskieren. - Inkonsistente Rahmenbedingungen: Häufige Änderungen im Team oder Umfeld machen Velocity-Tracking ungenau. - Ignorieren qualitativer Aspekte: Wenn nur die Menge der Arbeit zählt und nicht deren Wert, wird das Ziel von agilen Methoden verfehlt.

Planning Poker / Estimation

Eine häufig genutzte Methode, um Stories gemeinsam (z. B. mithilfe von Karten) zu schätzen und ein gemeinsames Verständnis herzustellen. Wann: Während des Backlog Refinements oder Sprint Plannings, um den Aufwand von Aufgaben gemeinsam im Team zu schätzen. Warum: Es fördert ein gemeinsames Verständnis der Anforderungen und ermöglicht eine bessere Planung der Teamkapazität. Voraussetzungen - Gemeinsame Schätzskala: Das Team sollte eine einheitliche Methode verwenden, z. B. Fibonacci-Zahlen oder T-Shirt-Größen. - Klare Anforderungen: Die zu schätzenden Backlog-Einträge müssen ausreichend beschrieben sein. - Aktive Beteiligung: Alle Teammitglieder sollten an der Schätzung teilnehmen, um diverse Perspektiven einzubeziehen. Wie erkennt man, dass es nicht passt? - Unklare Einträge: Wenn Anforderungen unklar sind, werden die Schätzungen ungenau und können das Team irreführen. - Dominanz einzelner Mitglieder: Wenn einige Stimmen die Schätzung dominieren, verliert das Team den Vorteil kollektiver Intelligenz. - Zeitintensive Diskussionen: Wenn das Schätzen zu lange dauert, sollten die Anforderungen vorab besser vorbereitet oder andere Methoden ausprobiert werden.

Story Points

Relative Schätzeinheit, um den Aufwand von User Stories oder Tasks einzuschätzen, ohne sich zu sehr an reiner Stundenplanung zu orientieren. Wann: In agilen Teams zur relativen Einschätzung des Aufwands von Backlog-Einträgen. Warum: Story Points bieten eine flexible Methode, den Aufwand und die Komplexität von Aufgaben unabhängig von Zeitabschätzungen zu bewerten. Voraussetzungen - Klare Definition von Story Points: Das Team sollte ein gemeinsames Verständnis für die Bedeutung von Story Points haben (z. B. Kombination aus Aufwand, Risiko und Komplexität). - Vergleichbare Referenzaufgaben: Es sollte Referenzstories geben, um die Einschätzungen konsistent zu halten. - Erfahrung mit der Methode: Das Team benötigt etwas Übung, um realistische Schätzungen zu erstellen. Wie erkennt man, dass es nicht passt? - Unklare Bezugspunkte: Ohne gemeinsame Referenzpunkte werden die Schätzungen inkonsistent. - Fokus auf Velocity statt Wert: Wenn Story Points primär zur Leistungsmessung und nicht zur Planung genutzt werden, kann dies kontraproduktiv sein. - Ungeeignete Aufgaben: Für sehr kleine oder sehr große Aufgaben kann die Nutzung von Story Points weniger sinnvoll sein.

Release Planning

Ein (optionaler) Blick über den Sprint hinaus, um Meilensteine zu definieren und die Roadmap grob zu verfeinern. Wann: Am Anfang eines Projekts oder während der Entwicklung, um Meilensteine und Zeitrahmen für die Lieferung von Inkrementen festzulegen. Warum: Es bietet eine strategische Sicht auf die Produktentwicklung, schafft Transparenz für Stakeholder und hilft bei der Abstimmung von Erwartungen. Voraussetzungen - Priorisiertes Product Backlog: Klare Prioritäten helfen, realistische Ziele für Releases zu setzen. - Überblick über Kapazitäten: Das Team sollte eine Vorstellung von seiner Velocity und den verfügbaren Ressourcen haben. - Stakeholder-Abstimmung: Alle Beteiligten müssen sich über Ziele, Abhängigkeiten und zeitliche Einschränkungen einig sein. Wie erkennt man, dass es nicht passt? - Unrealistische Erwartungen: Wenn Releases ohne Berücksichtigung der Teamkapazität oder Komplexität geplant werden, entstehen Verzögerungen. - Fehlende Flexibilität: Wenn Pläne zu starr sind, kann das Team nicht angemessen auf Veränderungen reagieren. - Mangelnde Beteiligung: Wenn das Team nicht in die Planung eingebunden ist, fehlen wichtige Perspektiven und das Commitment.

Inkrement

Ein in sich geschlossenes, fertiges Ergebnis (Produkt oder Outcome), dass potenziell auslieferbar ist Wann: Nach jedem Sprint, wenn ein neues Stück des Produkts fertiggestellt ist und genutzt oder vorgestellt werden kann. Warum: Das Inkrement zeigt den Fortschritt des Teams und schafft einen sichtbaren Mehrwert, der Feedback und Anpassung ermöglicht. Voraussetzungen - Definition of Done (DoD): Das Team muss sich darauf einigen, wann ein Inkrement als „fertig“ gilt. - Funktionalität: Das Inkrement sollte potenziell auslieferbar sein, auch wenn es nicht sofort an Kunden übergeben wird. - Qualitätsstandards: Alle Anforderungen hinsichtlich Qualität und Funktionalität müssen erfüllt sein.

Wie erkennt man, dass es nicht passt? - Unvollständige Arbeit: Wenn das Inkrement nicht den Qualitäts- und Fertigkeitsstandards entspricht, ist es nicht bereit, gezeigt oder genutzt zu werden. - Kein sichtbarer Mehrwert: Wenn das Inkrement keinen erkennbaren Nutzen für die Stakeholder bringt, könnte das Sprint-Ziel zu unscharf gewesen sein. - Mangelnde Integration: Wenn das Inkrement nicht nahtlos mit vorherigen Ergebnissen funktioniert, müssen die Prozesse zur kontinuierlichen Integration überprüft werden.