Scrum Guide Testfragen

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospektive

• Product Owner
• Entwicklungsteam
• Scrum Master

selbstorganisierend (entscheiden selber wie die Arbeit zu erledigen wird)

interdisziplinär (alle Kompetenzen um die Arbeit zu erledigen ohne Personen ausserhalb des Entwicklerteams)

Teams wurden konzipiert um: flexibel, kreativ, und  Produktiv zu sein

Sie liefern Produkte iterativ, inkrementell und maximieren die Gelegenheit für Feedback

inkrementelle Auslieferung vom fertigen "Done" Produkt = potentiell nützliche Version steht zur Verfügung

Ist für die Wertmaximierung des Produkts veratnwortlich

ist für die Arbeit des Enwicklungsteams verantwortlich

ist für das Management des Product Backlog als EINZIGSTER verantwortlich

Das Product Backlog Management: (kann vom PO erfolgen oder Entwicklungsteam, PO bleibt jedoch immer accountable, rechenschaftspflichtig

Einzelperson, kein Komitee, kann Prio im Product Backlog anpassen

Product Backlog Einträge klar zu formulieren

Die Einträge im Backlog zu zu sortieren das Ziele und Missionen optimal erreicht werden

Den Wert der Arbeit zu optimieren, das Ziele und Missionen optimal erreicht werden

Den Wert der Arbeit zu optimieren, die das Entwicklungsteam erledigt

Sicherstellen, dass das Broduct Backlog sicher, transparent und klar zeigt woran das Scrum Team arbeiten wird

Sicherstellen, dass das Enwicklungsteam die Product Backlog Einträge versteht

Kann nur erfolgreich sein, wenn er respektiert wird. Entscheidungen im Product Backlog sichtbar

Nieman darf vom Entwicklungsteam verlangen andere Anforderungen zu bearbeiten. Entwicklungsteam darf ausschliesslich nur nach Angaben eines Product Owners arbeiten

Entwicklungsteam=Profis ide am Ende eines jeden Sprints ein fertiges Inkrements übergeben

Entwicklungsteam strukturieren, organisieren und managen selbst Ihre Arbeit.

Synergie optimiert die Gesamteffizens und Effektivität des Entwicklungsteams

Selbstorganisierend (Niemand, nicht mal der Scrum Master sagt dem Entwicklungsteam wie man aus dem Backlog 

auslieferbare Funktionalität machen soll!

Sie sind interdisziplinär. Erstellen den Product Inkrement

Scrum kennt keine Titel ausser Entwickler für Mitglieder des Enwicklungsteams

Scrum kennt keine weiteren Unterteilungen innerhalb des Enwicklungsteamsm ungeachtet von bestimmten zu adressierenden Domänen wie Test oder Analyse. Es gibt keine Ausnahmen

INdividuelle Mitglieder des Entwciklungsteams können spezifizierte Fähigkeiten oder Spezialgebiete haben, aber Rechenschaftspflich obliegt dem Team als Ganzem

klein genug um flink zu bleiben und gross genug um bedeutende Arbeit innerhalb eines Sprints erledigen zu können

weniger als 3 Mitglieder reduzieren die Interaktion und führen zu geringeren Produktionssteigerungen als bei grösseren Teams. 

kleinere Teams können eventuell kein auslieferbares Produkt-Inkrement liefern, da Sie nicht über alle Fähigkeiten verfügen

Mehr als 9 Mitglieder erfordern zu viel Koordination

Grosse Entwicklungsteams erzeugen eine zu hohe Komplexität um durch einen empirischen Prozess gemanagt werden zu können.

Product Owner und Scrum Master zählen nicht dazu 

Der Scrum Master ist für das Verständnis und die Durchführung von Scrum verantwortlich

Er sorgt dafür, dass das Scrum Team die Theorie, Praktiken und Regeln einhält.

Der Scrum Master ist ein Servant Leader und hilft denen die kein Teil des Scrum Teams sind, zu verstehen, welche Interaktion mit dem Team sich hilfreich auswirken und welche nicht

Der Scrum Master hilft die Zusammenarbeit zu optimieren und den vom Scrum Team generierten Wert zu maximieren

Der Scrum Master dient dem Product Owner beim:

Vermittlung von Techniken für die Verwaltung des Backlog

Vermitteln des Verständnisses für die Produktplanung in einem empirischen Arbeitsumfeld

Sicherstellen, dass der Product Owner weiss, wie er das Product Backlog anordnetm dass es einen grösseren Wert  erzeugt

Vermitteln des richtigen Verständnisses von Agilität und Ihrer Anwendung

Unterstützung bei Bedarf oder auf Anfrage bei der Durchführung von Scrum Ereignissen

Dienst des Scrum Master für das Entwicklungsteam

Coachen des Entwicklungsteams hin zur Selbstorganisation und funktionsübergreifender Teamarbeit

Unterstützen des Entwicklungsteams bei der Erschaffung hochwertiger Produkte

Beseitigen von Hindernissen, die das Entwicklungsteam aufhalten

Unterstützung bei Bedarf oder auf Anfrage bei der Duchführung von Scrum Erreignissen

Coachen des Entwicklungsteam in Organisationen, in denen Scrum noch nicht vollständig angenommen und verstanden wird

Dienst des Scrum Masters an der Organisation

Leiten und Coachen der Organisation bei der Einführung von Scrum

Planen von Scrum Implementierung innerhaln der Organisation

Unterstützung von Kollegen und Stakeholdern, Scrum und empirische Produktentwicklung zu verstehen und umzusetzen

Auslösen von Veränderungen zu Produktivitätssteigerung des Teams

Zusammenarbeit mit anderen Scrum Mastern, um die Effektivität von Scrum Implementierunen innerhalb der Organisation zu verbessern

Sprintbeginn und dessen Dauer steht fest - keine Kürzung oder Verlängerung!

Das Weglassen eines Ereignisses führt zu verringerter Transparenz und ist eine verpasste Gelegenheit den Ist-Stand zu erfassen und darauf zu reagieren (Inspect & Adapt)

Ein Sprint hat eine Timebox von maximal einem Monat und innerhalb wird ein fertiges "Done" bzw. ein nutzbares und potentiell auslieferbares Produkt-Inkrement hergestellt

Alle Sprints innerhalb eines Entwicklungsvorhabens sollten die gleiche Dauer haben.

Der neue Sprint statet sofort nach dem Abschluss des vorherigen Sprints

Ein Sprint beeinhaltet das Sprint Planning, Daily Scrums, Entwicklungsarbeit, das Sprint Review und die Sprint Retrospektive

Während des Sprints:

-werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden

-wird der Qualitätsanspruch nicht geschmälert

-der Anforderungsumfang kann zwischen Product Owner und Entwicklungsteam geklärt und neu ausgehandelt werden, wenn sich neue Erkenntnisse ergeben haben

Jeder Sprint hat einen Zeithorizont von max. einem Monat

(wird er zu gross gewählt, kann sich die Definition des Ergebnisses ändern, die Komplexität ansteigen, sich das Risiko erhöhen)

Jeder Sprint hat einen definierten Leistungsumfang, einen Entwurf, einen flexiblen Plan

Ein Sprint kann vorzeitig abgebrochen werden.

Dazu ist nur der Product Owner berechtigt! (auch wenn es auf Anraten der Stakeholder, des Entwicklungsteeam oder des Scrum Master ist). Aufgrund der kurzen Dauer eines Sprints, macht ein Abbruch aber keinen Sinn und ist eher unüblich

Das Scrum Team plant die kommenden Sprints

Das Sprint Planning hat eine Timebox von max. 8 Stunden für einen einmonatigen Sprint

Bei kürzeren Sprints wendet man normalerweise weniger Zeit auf

Der Scrum Master sorgt dafür das die Plannung stattfindet und die Teilnehmer den Zweck verstehen

Er bringt dem Scrum Team bei das Ereignis innerhalb der Timebox abzuschliessen

Folgendes wird in der Sprint Planning beantwortet:

Was ist in dem Produkt-Inkrement des kommenden Sprints enthalten?

Wie wird die für die Lieferung des Produkt Inkrements erforderliche Arbeit erreicht?

Sprint Inhalt:

Das Entwicklungsteam erstellt eine Prognose über die Funktionalitäten die im Sprint entwickelt werden sollen

Der Product Owner beschreibt das Ziel das im Sprint erreicht werden soll und die Product Backlog Einträge

(Wenn diese abgeschlossen sind, ist das Ziel erfüllt)

Das ganze Scrum Team erarbeitet die Arbeitsinhalte des Sprints

Als Grundlage für das Sprint Planungsmeeting dient das Product Backlog, das neuste Product Inkrement, die veranschlagte Kapzität sowie die bisherige Leistung

Das Entwicklungsteam bestimmt die Anzahl der ausgewählten Product Backlog Einträge.

Das Sprint Ziel bildet die Grundlage für die Implementierung der Backlog Einträge

Es entscheidet wie das Produkt Inkrement erstellt wird.

Es organisiert selbst, wie es die Arbeiten im Sprint Backlog eingeht

Die geplanten Arbeiten werden in kleine Einheiten von einem Tag oder weniger für den Sprint zerlegt.

Der Product Owner kann helfen Backlog Einträge zu klären

Das Entwicklungsteam kann die Produkt Backlog Einträge mit dem Product Owner neu ausverhandeln, (bei zuviel oder zu wenig Arbeit)

Am Ende des Sprint Planning ist das Entwicklungsteam in der Lage dem Oroduct Owner und Scrum Master zu beschreiben, wie es das gewünscht Product Increment erreichen möchte

Sprint Ziel:

Entwicklungsteam hat gewisse Flexibilität zur Implementierung der Funktionalitäten

Daily Scrum: 

Timbox von 15 Minuten zur Syncronisierung  der Aktivitäten (für die nächsten 24 Stunden) innerhalb des Entwciklungsteams. Überprüfung der Arbeiten seit dem letzen Daily Scrum, Prognose der Arbeitsergebnisse bis zum nächsten Daily Scrum

Um die Komplexität zu reduzieren, wird das Daily Scrum an jedem Tag zur gleichen Uhrzeit am gleichen Ort abgehalten. 

Während des Meeting schildern die Mitglieder:

Was habe ich gestern erreicht um das Sprint Ziel zu erreichen

Was werde ich heute erledigen

Sehe ich irgendwelche Hindernisse

Das Daily Scrum erhöht die Wahrscheinlichkeit dass das Entwicklungsteam sein Sprint Ziel erreicht.

Der Scrum Master sorgt für die Durchführung und Einhaltung der Regeln

Daily Scrum verbessert die Kommunikation, macht andere Meeting überflüssig, identifiziert Hindernisse, focusiert auf schnelle Entscheidungsfindung und erhöht den Wissenstand des Enwiclungsteams