Kartenstapel

, um von den Schwächen im eigenen System abzulenken.

Ein Feindbild schafft ein gemeinsames Ziel und täuscht darüber hinweg, dass es keine echten, erreichbaren internen Ziele gibt.

Potentially Shippable Product Increment

▪ einem Product Owner (zur Erinnerung: Es gibt nur ein Product Backlog.).

▪ einem Scrum Master (mindestens einer aus den teilnehmenden Teams).

Der Nexus Scrum Master ist für Coaching, die Moderation der Kommunikation und die Unterstützung der Nexus-Ergebnisse zuständig (durchführungsverantwortlich) – genau wie in einem Sprint.

▪ den Mitgliedern des Nexus Integration Teams, die die teilnehmenden Teams repräsentieren.

Der Fokus eines Nexus Teams liegt mehr auf Abhängigkeiten, Interoperabilität, Geschäftsergebnissen und dem Wert, den es schöpft. Das NIT stellt sicher (ergebnisverantwortlich), dass in jeder Iteration ein integriertes Inkrement erzeugt wird. Die Scrum Teams entwickeln Inkremente, die in der Summe das Nexus-Ziel erfüllen.

User Stories beschreiben (eher in Form einer Geschichte) was der Nutzer will. „Keep it short and simple“, leichtverständlich auch für Fachfremde. Sie gelten als Versprechen, dass man über die Inhalte weiter spricht.

Als ein <Rolle (Art von Benutzer)> möchte ich, dass <das

was der Anforderung (ein Ziel)>, damit ich

<das WARUM der Anforderung (Begründung)>

Epic‘s sind sehr große, noch unklare User Stories, die meist nur als grobformulierte

Anforderung vorliegen. Sie werden nach und nach verfeinert und dann in mehrere

kleinere User Stories zerlegt.

Themes sind eine Sammlung zusammenhängender

User Stories. Sie zeigen auf, dass mehrere User Stories

etwas gemeinsam haben, sie bilden einen Überbegriff.

▪ Nutze ein agiles Vorgehen (hier: Scrum), wenn

das Unbekannte das Bekannte überwiegt.

▪ Nutze ein klassisch sequenzielles Vorgehen

(Wasserfall), wenn das Bekannte das Unbekannte

überwiegt.

Die 9 Prinzipien sind:

1. Der Kunde wird aktiv in die Arbeit des Teams einbezogen.

2. Die Entscheidungsgewalt liegt (zumindest in großen Teilen) beim Team.

3. Der Fokus liegt auf der häufigen Lieferung von Produkten

4. Jede (Teil-)Lieferung muss einen Geschäftswert für den Anwender darstellen,

was auch das relevante Abnahmekriterium (Business-Value-Driven) darstellt.

5. Eine iterativ inkrementelle Entwicklung ist notwendig, um eine adäquate Lösung zu erzielen.

6. Alle Änderungen während der Entwicklung sind zurücknehm-/ oder umkehrbar.

7. Anforderungen werden auf einem relativ hohen Niveau festgeschrieben.

8. Testen ist integraler Bestandteil des gesamten Prozesses.

9. Die kooperative Zusammenarbeit aller Projektbeteiligten ist überaus wichtig.

1. Laufende Arbeit (WIP): WIP steht für die Menge der Arbeit, die begonnen wurde, aber bislang nicht fertiggestellt ist. Die Gründe für die Nichtfertigstellung sind unwichtig.

Wichtig ist, dass andere Aufgaben nicht abgeschlossen oder gar nicht begonnen werden können, bevor die laufende Arbeit fertiggestellt ist, entweder weil sie von laufenden Arbeitselementen abhängig sind oder weil die Entwickler schon an der laufenden Arbeit arbeiten.

2. Zykluszeit: die Zeitspanne zwischen Beginn und Abschluss eines Arbeitseintrags.

3. Alter des Arbeitseintrags: die Zeitspanne zwischen Beginn eines Arbeitseintrags und der aktuellen Zeit. Das Alter gilt nur für Einträge mit noch laufender Arbeit.

4. Durchsatz: die Zahl der pro Zeiteinheit fertiggestellten Arbeitseinträge.

5. Service Level Erwartung (SLE): Eine SLE prognostiziert, wie lange ein bestimmter Artikel braucht, um den gesamten Arbeitsfluss des Scrum Teams von Anfang bis Ende zu durchlaufen.

Viele Teammitglieder werden benötigt. Daher arbeiten mehrere Teams parallel, das nennt sich „Scaled Scrum“.

• Nexus™

• Scrum@Scale™

• LeSS™

• SAFe™

▪ Für eine spezifische Entwicklung sind mehrere Teams erforderlich.

▪ Mehrere Teams arbeiten zusammen an einem gemeinsamen Ziel.

▪ Mehrere Teams arbeiten gleichzeitig an einem Produkt oder Service.

Erfüllt Ihr Projekt diese Anforderungen nicht, ist es besser, die Standardvariante von Scrum zu verwenden.

1. Ein größenskaliertes Scrum.

2. Transparenz: Hauptergebnisse sind für alle sichtbar.

3. More with Less (Weniger ist mehr): Komplexität beseitigen, einfache Problemlösungen.

4. Focus auf das ganze Produkt: Einzelteile des Produktes haben keinen Wert, erst wenn sie zum Endprodukt zusammengefügt werden.

5. Kundenzentrierung: PO ist Bindeglied zwischen Kunden/Benutzern und Team.

6. Kontinuierliche Verbesserung in Richtung Perfektion: Veränderung findet kontinuierlich statt.

7. Lean-Mindset: Respekt vor den Menschen und kontinuierliche

Verbesserung sind zentrale Konzepte von Lean.

8. Systemdenken: Langfristige, dauerhafte Systemveränderungen sind über

Quick-Fix-Lösungen vorzuziehen.

9. Empirische Prozesskontrolle: Zyklus →Transparency, Inspection and Adaption.

10. Warteschlangentheorie: Ziel ist es große Arbeitschargen zu bewältigen.

1. Einnehmen einer wirtschaftlichen Sichtweise.

2. Systemdenken anwenden.

3. Variabilität annehmen, Alternativen/Optionen beibehalten oder offen halten.

4. Inkrementelle Vorgehensweise mit schnellen, integrierten Lebenszyklen.

5. Meilensteine auf Basis objektiver Auswertung funktionierender Systeme setzen.

6. Visualisiere und begrenzen die laufenden Arbeiten (WIP), reduzieren die Batch-Größen

und verwalten die Länge der Warteschlangen.

7. Halte einen Rhythmus ein, (Timing) anwenden und mit der domänenübergreifenden Planung synchronisieren.

8. Erschließe die wesentliche Motivation von Wissensarbeitern.

9. Entscheidungsfindung dezentralisieren.

1. Wert: Identifiziere und spezifiziere den Wert deines Produktes aus Sicht des Kunden.

2. Wertstrom: Erkenne und Verstehe den Wertstrom und eliminiere Verschwendung. Value Stream Mapping (VSM)

3. Flow: Erzeuge einen Wertstromfluss ohne Unterbrechungen. Dies führt zu einer Verbesserung des Cashfows (optimierte Lagerhaltung).

4. Pull: Lasse den Kunden den Takt der Bearbeitung bestimmen, d.h. lass ihn abrufen was er braucht und liefere genau zum richtigen Zeitpunkt (Pullprinzip).

5. Perfektion: Verbessere die Dinge kontinuierlich, strebe nach Perfektion (Kaizen).

Ziele:

▪ Maximieren des Business Value für den Kunden.

▪ Kontinuierliches optimieren der Prozesse, was zu höherer Qualität und kürzeren Lieferzeiten führt.

▪ Verbessern des finanziellen Nutzens durch das Reduzieren von Verschwendung (Waste).

Die Scrum Master Rolle:

Sie muss nicht Vollzeit besetzt werden. Eine einzelne Person kann der Scrum Master mehrerer

Teams sein (ist in der Praxis üblich).

Die Product Owner Rolle:

Hierzu gibt es zwei unterschiedliche Ansätze in den Frameworks:

1. Es gibt nur einen Product Owner für alle Teams. Dadurch soll zum einen die

Einheitlichkeit der PBIs und deren Priorisierung im Product Backlog sichergestellt werden.

Zum anderen gibt es damit eine klare Verantwortung für das Product Backlog.

2. Es gibt einen Product Owner je Team (ein Product Owner kann mehrere Teams betreuen).

Alle Teams werden übergreifend durch einen Chief Product Owner begleitet, der die

Einheitlichkeit im Backlog sicherstellt.

Die kontinuierliche Pflege und Weiterentwicklung des Product Backlogs wird als Backlog Refinement (oder alternativ Backlog Estimation oder Backlog Grooming*) bezeichnet. Es ist ein regelmäßiger Prozess, bei dem Product Owner und Entwickler das Backlog auf den aktuellen Stand bringen. Typische Tätigkeiten im Backlog Refinement sind:

• Aufnahme von neuen User Storys, Features und Epics in das Backlog

• Verfeinerung von vorhandenen Epics, Features und User Storys und gegebenenfalls Aufteilung in mehrere kleine Backlog Items

• Zusammenfassen von User Storys

• Diskussion der Akzeptanzkriterien, Annahmen und Einschränkungen

• Identifikation von Abhängigkeiten

• Korrektur von Aufwandsschätzung aufgrund neuer Erkenntnisse

• Veränderung der Priorisierung aufgrund neuer Erkenntnisse

• Entfernen von irrelevanten User Storys, Features oder Epics aus dem Backlog

• Beseitigung von Unklarheiten durch gemeinsame Diskussion, wobei es um das “was” und nicht das “wie” geht

Bei der Affinity Estimation werden die Anforderungen (meist in Form von User-Stories) ihrem Umfang folgend geordnet. Zu Beginn wird dem gesamten Team jede User Story vorgelesen.

User-Stories mit geringem Umsetzungsaufwand werden links angeordnet, solche mit größerem rechts.

Für jede User-Story wird bestimmt, ob sie größer, kleiner oder gleich umfangreich wie jede andere ist, wodurch sich eine nach dem Umsetzungsaufwand sortierte Folge ergibt.

Diese Stories werden anschließend noch gruppiert und den Elementen jeder Gruppe die jeweils gleiche Anzahl an Story Points zugeordnet.

„Ein konkretes Etappenziel auf dem Weg

zum Produkt-Ziel, wobei jedes Inkrement

additiv zu allen vorherigen Inkrementen

ist und gründlich verifiziert wird, um

sicherzustellen, dass alle Inkremente

zusammenwirken.

Um einen tatsächlichen Wert darzustellen,

muss das Inkrement nutzbar sein“.

Das Inkrement ist ein Scrum Artefakt.

Die Adaption ist das Herzstück aller agilen Systeme.

Transparenz

Überprüfung

Anpassung

Umfang

Zeit

Kosten

Qualität

DSDM schreibt daher Zeit, Kosten und Qualität fest und verändert den Umfang

dynamisch.

https://www.agilebusiness.org/page/

ProjectFramework_03_PhilosophyFundamentals

Must-Have: Ein Must-Have-Feature muss im Endprodukt enthalten sein, da das

Produkt ohne dieses Feature nutzlos wäre (z. B. Bremsen in einem Auto).

• Should-Have: Ein Should-Have-Feature ist für das Endprodukt sehr wichtig. Fehlt dieses Feature werden Probleme auftreten. Die Probleme lassen sich allerdings umgehen und das Produkt kann auch ohne das Feature genutzt werden (z. B. eine Klimaanlage in einem Auto).

• Could-Have: Ein Could-Have-Feature ist ein hilfreiches Feature, das wir gerne in

unserer Lösung hätten. Sollte das Feature in unserem Produkt jedoch fehlen, so ist

dies auch kein Problem (z. B. eine Rückfahrkamera in einem Auto).

• Won‘t-Have-This-Time: Ein Won‘t-Have-Feature ist zwar möglicherweise

interessant, aber zum aktuellen Zeitpunkt werden wir nicht in dieses Feature

investieren.

Ein abnahmefähiges Produkt muss mindestens alle Must-Have-Features enthalten.

• Das Produkt, das wir erwarten, enthält alle Must-Have- und alle Should-Have-

Features.

• Das ideale Produkt enthält alle Must-Have-, Should-Have- und Could-Have-Features.

Die Regel lautet, dass höchstens 60% aller Einträge Must-Have- und mindestens

20% aller Einträge Could-Have-Einträge sein sollten. Dies dient als Orientierung zum Verständnis der Logik, die dieser Methode zugrunde liegt.

1. Arbeit sollte visualisiert werden.

2. Laufende Arbeit (WIP) sollte begrenzt werden.

3. Die Arbeit sollte vom Team in das System gezogen (Pull) nicht von außen in das

System geschoben (Push) werden

Kommunikation

Einfachheit

Feedback

Mut

Respekt

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen.

Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Fachexperten und -expertinnen sowie Entwickler:innen müssen während des Projekts täglich zusammenarbeiten

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht

Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

Die besten Architekturen, Anforderungen und Entwürfe entstehen

durch selbstorganisierte Teams

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber,

Entwickler:innen und User (Benutzer und Benutzerinnen) sollten

ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können

Ständiges Augenmerk auf technische Exzellenz und gutes Design

fördert Agilität

Stellen Sie sich vor, ein:e Entwickler:in verlässt das Gebäude, wird bedauerlicherweise

von einem Bus überfahren und stirbt. Legt dieses Unglück nun das gesamte Projekt

lahm, weil es Aspekte gibt, die kein anderes Projektmitglied versteht, so hat das Projekt

einen Busfaktor von 1. Sind für den Worst Case, d. h. um das Projekt zu blockieren, zwei

Busunfälle erforderlich, so spricht man von einem Busfaktor von 2 usw. Ein niedriger

Busfaktor ist also immer risikobehaftet

Eine weitere Rolle ist die des Doomsayers oder des Schwarzmalers bzw. der Schwarzmalerin. Er oder sie bestärkt die anderen Teammitglieder darin, auch an die Risiken und Probleme zu denken. Danach arbeitet das gesamte Team zusammen und prüft, wie es diese Risiken und Probleme beherrschen oder bewältigen kann

Deshalb beschäftigt man sich bei XP manchmal mit Spiking anstatt die eigentliche Arbeit zu erledigen. Beim Spiking programmieren Sie einfach drauf los, ohne die Praktiken zu befolgen. Sie schreiben schnell einen Code, um eine Idee oder eine Technologie auszuprobieren. In der Regel sollten Sie diesen Code nicht behalten. Wenn Sie mit dem Ausprobieren fertig sind und wissen, was Sie wissen wollten, löschen Sie den Code und arbeiten wieder nach den festgelegten Standards und Praktiken.

Independent (unabhängig):

Die Einträge dürfen untereinander keine Abhängigkeiten aufweisen, damit wir sie auf der Basis ihrer Wichtigkeit und ihres Werts entwickeln können und uns nicht über eventuelle Abhängigkeiten sorgen müssen.

• Negotiable (verhandelbar):

Product Backlog-Einträge (Product Backlog Items, PBI) sind gleichzeitig auch Kommunikationswerkzeuge und sollten daher verhandelbar sein.

• Valuable (wertvoll):

Jeder Eintrag leistet einen Wertbeitrag. Dieser bestimmt in der Regel die Reihenfolge der Entwicklung.

• Estimateable (schätzbar):

Wir brauchen für jeden Eintrag eine einfache Schätzung der Größe; erscheint ein Eintrag nicht schätzbar, so ist er möglicherweise nicht korrekt ausgearbeitet.

• Small (klein):

Nur die Einträge, die im Product Backlog ganz oben angeordnet sind, müssen klein sein; die anderen dürfen groß und können sogar unklar sein.

• Testable (testbar):

Erscheint es unmöglich, einen Eintrag zu demonstrieren oder zu testen, dann ist der Eintrag nicht korrekt ausgearbeitet

Als {Rolle} möchte ich {etwas tun}, [um {Zweck}]

Dauer

Die Sprint Retrospective dauert bei einem Sprint mit einer Länge von 1 Monat maximal 3 Stunden. Bei kürzeren Sprints ist sie in der Regel kürzer. In der Regel ist die Sprint

Retrospective zeitlich begrenzt (timeboxed) und die festgelegte Dauer gilt für alle

Sprint Retrospectives bis wir uns entschließen, diese Dauer zu ändern.

Dauer

Das Sprint Review dauert bei einem Sprint mit einer Länge von 1 Monat maximal 4

Stunden. Bei kürzeren Sprints ist das Review in der Regel kürzer. Das Review ist zeitlich begrenzt (timeboxed). In der Regel legen wir die Timebox einmal fest und nutzen diese dann für jedes Review, es sei denn wir entscheiden uns ausgehend von den aus dem Projekt gewonnenen Erkenntnisse dafür, die Dauer zu ändern

Die Messung des Projektfortschritts insgesamt erfolgt durch den Product Owner, weil diese:r die Einträge im Product Backlog und die künftigen Möglichkeiten am besten kennt.

Nur zur Erinnerung: Die Messung des Sprintfortschritts ist Aufgabe der Entwickler:innen.

Nur zur Erinnerung: Die Messung des Sprintfortschritts ist Aufgabe der Entwickler:innen.

Genau wie beim Sprintfortschritt kommt auch hier häufig ein Burn-Down-Chart zur

Visualisierung des Projektfortschritts zum Einsatz.

Verpflichtend ist dies aber nicht

Die Sprint Retrospective ist eine strukturierte Methode zur Prozessverbesserung. Für uns stellt die Sprint Retrospective jedoch nur eine Mindestanforderung dar. Unsere Bemühungen hinsichtlich der Prozessverbesserung gehen weit darüber hinaus. Verbesserungen können jederzeit stattfinden.

Bei adaptiven Systemen geht es darum, das Produkt an seine Umgebung anzupassen.

Das Sprint Review ist dabei eines der wichtigsten Events. Daneben müssen wir jedoch auch unsere Arbeitsweise entsprechend an die Umgebung anpassen. Letzteres beschränkt sich allerdings nicht auf adaptive Projekte, sondern ist stets notwendig.

Agile Projekte nehmen dies jedoch ernster und halten in der Regel am Ende einer

Iteration reflexive Besprechungen ab mit dem Ziel, die Arbeitsweise zu verbessern.

Dieses Meeting wird bei Scrum als Sprint Retrospective bezeichnet

Bei Scrum gibt es drei Artefakte:

1. Das Inkrement: Dieses ist die neueste Version des Produkts, die wir für den Kunden erstellt haben.

2. Das Product Backlog: Das Product Backlog ist unser Gesamtprojektplan. Es umfasst das Produktziel und eine geordnete Liste an Einträgen (wie z. B. Features), die wir unserem Produkt hinzufügen möchten.

3. Das Sprint Backlog: Unser kurzfristiger Projektplan, der in einem einzigen Sprint

umgesetzt wird. Das Sprint Backlog umfasst das Sprintziel, eine Liste mit Product-

Backlog-Einträgen (Product Backlog Item, PBIs) und eine Reihe von Aufgaben, die

durch Zerlegen der Einträge erstellt wurden

• Das Commitment für das Inkrement ist die Definition of Done (DoD), die klar macht, was wir meinen, wenn wir sagen, etwas sei fertig.

Das Commitment für das Product Backlog ist das Produktziel. Es verdeutlicht, was

mit der Entwicklung der Einträge (Items) erreicht werden soll.

Das Produktziel ist unsere Produktvision oder leitet sich von dieser ab

Das Commitment für das Sprint Backlog ist das Sprintziel. Es verdeutlicht, was wir

im Sprint durch die Entwicklung der PBI erreichen wollen. Für jeden Sprint gibt es

ein eigenes Sprint Backlog und Sprintziel.

• Beschreibung: Hierbei handelt es sich um eine kurze Beschreibung des Eintrags

(Items). Versuchen Sie nicht alle Einzelheiten des Eintrags abzudecken, da diese

teilweise erst während der Arbeit zutage treten. Die Meinung, die Einträge seien nur eine Ausrede dafür, vollständige Spezifikationen durch Unterhaltungen zu ersetzen, ist weitverbreitet.

• Größe: Der Umfang der einzelnen Einträge muss für mehrere Zwecke bekannt sein: (Darauf gehen wir in Kürze noch näher ein.)

• Reihenfolge: Die Reihenfolge der einzelnen Einträge ergibt sich aus ihrer Position

im Product Backlog

die Abhängigkeiten und andere Elemente. Damit würde der Wert alleine ausreichen, um die Einträge in eine Reihenfolge zu bringen.

Da die Fachliteratur zu Scrum die beiden Definitionen von „Wert” jedoch vermischt, wird in der Regel vorgeschlagen, die Einträge im Backlog nach Wert, Größe, Risiken, Abhängigkeiten etc. zu ordnen.

• Nexus™: Ein Framework von Scrum.org, das sich durch eine einfache und klare

Struktur auszeichnet.

• Scrum@Scale™: Ein Framwork von Scrum Inc.

• LeSS™: Eine leichte und übersichtliche Skalierungsmethode, die tendenziell auch

die Ebene des Programmmanagements abdeckt.

• SAFe™: Eine durchaus komplizierte, von vielen großen Organisationen (z. B. Banken)

bevorzugte Methode, die zwar nicht mit allen Agilen Konzepten kompatibel ist, aber

die allgemeinen Erwartungen von Managern in großen Organisationen erfüllt.

Eine Möglichkeit, die Menge der fertiggestellten Arbeit zu visualisieren, besteht darin, die Summe der geschätzten Größen der vollständig fertiggestellten Einträge im Verhältnis zur Zeit darzustellen

Ergänzen oder entfernen wir Einträge im Product Backlog bewegt sich das Ziel nach oben und unten.

Bei der Betrachtung eines solchen Diagramms denken die meisten Menschen automatisch an die Entwicklungsgeschwindigkeit und stellen sich vor, wann das Ziel erreicht sein wird (möglicher Fertigstellungstermin). Damit dies für alle einfacher wird, können wir im Diagramm eine Trendlinie ergänzen

Dieses Diagramm zeigt nicht die fertiggestellte, sondern die Menge der noch

verbleibenden Arbeit. Da die Kurve im Laufe der Zeit nach unten geht, spricht man von einem Burn-Down-Chart.

Burn-Down-Charts sind in Scrum-Projekten populär und trotz ihrer großen Schwächen nach wie vor die beliebteste Methode zur Darstellung des Projektfortschritts. Sie sind so weit verbreitet, dass die Agile Community, ein normales Diagramm (wie im vorherigen Abschnitt beschrieben) als Burn-Up-Chart bezeichnet, weil es die umgekehrte Form eines Burn-Down-Charts hat

Während Burn-Down-Charts bei Sprints mehr oder weniger gut funktionieren, da

es festgelegte Ziele gibt, sind sie bei Gesamtprojekten problematisch, weil sich das Product Backlog ständig verändert.

Erstens ist es schwierig, die Y-Achse ständig anzupassen und zweitens wird die Geschwindigkeit der Veränderung selbst dann nicht aus dem Diagramm ersichtlich. Eine mögliche Lösung besteht darin, Anpassungen unten am Diagramm vorzunehmen, indem wir Balken hinzufügen, die die Menge der verbleibenden Arbeit anzeigen

Der Grund hierfür ist, dass

es bei Projekten um Produkte und bei Programmen um Ergebnisse geht.

zur Planung des bevorstehenden Sprints durch Erstellen eines

Sprint Backlogs

zur Bewertung der jüngsten Inkremente und der Informationen

zum Projektfortschritt sowie zum Einholen von Feedback

zur Bewertung der Arbeitsweise und Planung von Verbesse-

rungen im nächsten Sprint

Er oder sie ist dafür verantwortlich, den Wert des Produkts zu maximieren und das Produktziel zu erreichen. Dies geschieht in erster Linie durch die Erstellung und Pflege des Product Backlogs.

Der Product Owner …

▪ ist eine Person, Business-orientiert

▪ entwickelt das Produkt-Ziel als langfristige Zielsetzung für das Scrum Team.

▪ kommuniziert das Produkt-Ziel umfassend, verständlich und macht es sichtbar.

▪ achtet auf festgelegte Ziele und finanzielle Vorgaben.

▪ erstellt, pflegt und priorisiert die Product Backlog-Einträge und kommuniziert diese klar und verständlich und managt damit den Produktlebenszyklus.

▪ erstellt die Produkt Roadmap und den Releaseplan.

▪ steuert durch die Verfolgung und Prognose des Fortschritts.

▪ kann die oben genannten Aufgaben delegieren, bleibt jedoch weiterhin

rechenschaftspflichtig (accountable).

▪ ist vom Unternehmensmanagement dazu bevollmächtigt Entscheidungen bezüglich Anforderungen und Funktionsumfang zu treffen.

Er oder sie sorgt für die vollständige und korrekte Einhaltung des

Scrum Frameworks. Dies erfordert Coaching, Schulungen und Problemlösung

Der Scrum Master ist ergebnisverantwortlich für die Einführung von Scrum (gemäß Scrum Guide) und die Effektivität („die richtigen Dinge tun“) des Scrum Teams.

Er ist …

▪ eine Person, eine echte Führungskraft, für das Scrum Team und die Gesamtorganisation.

▪ verantwortlich dafür, dass die Scrum Theorie, Praktiken und Regeln verstanden und eingehalten werden.

▪ Coach, Unterstützer, Vermittler, Moderator und Prozessbegleiter bei der Zielerreichung.

▪ jemand, der Hindernisse beseitigt und die Zusammenarbeit fördert, indem er eine vertrauensvolle, offene Arbeitsatmosphäre fördert.

▪ Feedback-Geber und bei Bedarf spricht er unproduktives Verhalten an.

▪ kein Vorgesetzter mit Weisungsbefugnis und Entscheidungsgewalt.

▪ der Unterstützter des Teams und hilft ihnen die „beste Version“ von sich selbst zu sein.

▪ langfristig gesehen darauf aus sich selbst „abzuschaffen“.

unter anderem durch das …

▪ Coachen der Entwickler hin zu Selbstmanagement und funktionsübergreifender Teamarbeit.

▪ Unterstützen der Entwickler bei der Schaffung hochwertiger Produkte, die der Definition of Done entsprechen.

▪ Beseitigen von Hindernissen, die das Scrum Team aufhalten.

▪ Sicherstellen, dass alle Scrum Events stattfinden, produktiv sind und innerhalb der Timebox bleiben.

▪ Unterstützen bei der Durchführung von Scrum Events bei Bedarf oder auf Anfrage.

▪ besondere Unterstützen der Entwickler in Organisationen, in denen Scrum noch nicht vollständig angenommen und verstanden wird.

unter anderem durch das…

▪ Suchen nach Techniken zur effektiven Definition des Produkt-Ziels.

▪ Vermitteln von Kenntnisse, wie eine gute Anordnung der Product Backlog Items dabei hilft den größtmöglichen Wert zu erzeugen. Dadurch wird eine effektive Verwaltung des Produkt Backlogs ermöglicht.

▪ Vermitteln eines Verständnisses für die Notwendigkeit klarer, prägnanter

Product Backlog Einträge im Scrum Team.

▪ Sicherstellen, dass Ziele, Umfang und Produktdomäne von allen im Scrum Team, so gut wie möglich, verstanden werden.

▪ Schaffen eines Verständnisses für eine Produktplanung in einem empirischen Arbeitsumfeld.

▪ Vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung.

▪ Unterstützen bei der Durchführung von Scrum Events bei Bedarf oder auf Anfrage.

unter anderem durch das …

▪ Leiten, Schulen und Coachen der Organisation bei der Einführung von Scrum.

▪ Planen und Empfehlen der Scrum Implementierung innerhalb der Organisation.

▪ Unterstützen von Kollegen und Stakeholdern, damit sie Scrum und die empirische Produktentwicklung verstehen und umsetzen können.

▪ Auslösen von Veränderungen zur Produktivitätssteigerung des Teams.

▪ Zusammenarbeiten mit anderen Scrum Mastern, um die Effektivität von Scrum

Implementierungen innerhalb der Organisation zu verbessern.

▪ Beseitigen von Barrieren zwischen Stakeholdern und dem Scrum Team.

▪ einen Plan für den Sprint zu erstellen, das Sprint Backlog.

▪ die Qualität durch die Einhaltung einer Definition of Done einzubringen.

▪ täglich ihren Plan zur Erreichung des Sprint‐Ziels anzupassen.

▪ sich wechselseitig als Experten zur Verantwortung zu ziehen.

▪ Es gibt keine spezifischen Titel.

▪ Es gibt keine Sub-Teams.

▪ Das Team ist interdisziplinär, das heißt im Team sind alle Fähigkeiten enthalten, um das Inkrement zu erstellen.

▪ Das Team ist Cross-funktional (Designer, Tester, Vertriebler, Marketingmitarbeiter,…).

▪ Einzelne Mitglieder können spezialisierte Fähigkeiten oder Spezialgebiete haben,

aber die Rechenschaftspflicht obliegt allen als Ganzes.

▪ Ein Stabiles Team, Full-Time im Einsatz, wird empfohlen.

▪ Größe: bis 8 Personen

Die Scrum Artefakte und ihre Commitments

▪ Product Backlog → Produktziel

▪ Sprint Backlog → Sprintziel

▪ Inkrement → Definition of Done

Dies sind die technischen Experten und Expertinnen, die das

Produkt entwickeln

in Scrum Team umfasst in der Regel höchstens 10

Mitarbeiter.

Ein Setup mit mehreren Teams nennt man Skaliertes Scrum

Selbstmanagement

Ein Scrum-Team muss befugt sein, selbständig Entscheidungen bezüglich des Projekts treffen zu können. In den früheren Versionen des Scrum Guides wurde dies als Selbstorganisation bezeichnet. Der Scrum Guide aus dem Jahr 2020 nennt es nun Selbstmanagement. Mit anderen Worten, es handelt sich schlicht um zwei verschiedene Bezeichnungen für ein- und denselben Begriff.

Zuständigkeit bedeutet, dass man etwas tun soll. Hat man dagegen die Verantwortung, so ist man für das Ergebnis verantwortlich. Mit anderen Worten, wenn Sie die Verantwortung tragen, die Zuständigkeit aber lieber delegieren, werden Sie die Arbeit dennoch überwachen, um sicherzugehen, dass sie ordnungsgemäß erledigt wird.

Der Product Owner nutzt diese

Informationen zur Verwaltung des Product Backlogs und um:

• neue Einträge (Items) für das Backlog zu erstellen,

• die vorhandenen Einträge genau zu beschreiben und

• die Einträge in die entsprechende Reihenfolge zu bringen.

Um schnellstmöglich einen größtmöglichen Wert zu erzielen, ordnet der Product Owner die Einträge so an, dass Einträge, die am ehesten zum Wert des Produkts beitragen, im Product Backlog ganz oben stehen und zuerst entwickelt werden. Dies ist eine der wichtigsten Methoden, mit denen der Product Owner für Wertmaximierung sorgt

– Wie viele Product Owner gibt es?

Diese Rolle wird stets nur von einer Person ausgeführt, ganz gleich, wie groß Ihr Projekt

ist. Der Grund hierfür ist, dass es bei mehreren Personen eventuell zu Ungereimtheiten

im Product Backlog oder in den Informationen kommen könnte, die den Entwicklern

und Entwicklerinnen bereitgestellt werden

Der Product Owner ist für die Ermittlung des Projektfortschritts zuständig.

Diese Tätigkeit fällt in die Zuständigkeit des Product Owners, weil es einen hohen Grad an Verständnis für den gesamten Arbeitsumfang und alle damit verbundenen Möglichkeiten erfordert und niemand über mehr Informationen in diesem Bereich verfügt als der Product Owner. Die Entwickler:innen konzentrieren sich auf die Arbeit in den Sprints und die technischen Aspekte des Projekts und der Scrum Master befasst sich eher mit dem Kontext als dem Inhalt.

Der Product Owner ist für das Product Backlog verantwortlich, d. h. er oder sie trägt die Ergebnisverantwortung. Veränderungen am Product Backlog dürfen nur vom Product Owner oder allenfalls von Mitarbeitern und Mitarbeiter:innen durchgeführt werden, denen vom Product Owner bestimmte Zuständigkeiten (Durchführungsverantwortung) übertragen und die entsprechend autorisiert wurden

Product Owner dürfen manche Zuständigkeiten (Durchführungsverantwortungen)

an andere (in der Regel die Entwickler:innen) delegieren. Beispielsweise ist es nicht ungewöhnlich, dass der Product Owner die Entwickler:innen bittet, die Zuständigkeit (Durchführungsverantwortung) für die Erstellung der technischen Product-Backlog- Einträge (Product Backlog Items, PBI) zu übernehmen. In der Regel ist es jedoch am besten, wenn der Product Owner die Zuständigkeiten (Durchführungsverantwortung) selbst behält.

Scrum Master sind Scrum-Experten, die beim Verständnis und der Anwendung von Scrum behilflich sind. Darüber hinaus helfen sie, ein für das Team angenehmes Arbeitsumfeld sicherzustellen.

– Coaching und Training

Der Scrum Master coacht und schult das Team bezüglich der Anwendung von Scrum und, was noch wichtiger ist, er oder sie schult und coacht möglicherweise den Kunden und die Managementebenen der Organisation darin, wie man mit einem Scrum Team arbeitet.

Bitte beachten Sie stets, dass Scrum Master den Teammitgliedern nichts vorschreiben können, sie können lediglich Überzeugungsarbeit leisten.