Scrum Training
Scrum ist ein agiles Projektmanagement Framework
das agile Manifest Individuen & Interaktionen funktionsfähige Produkte Zusammenarbeit mit dem Kunden das Eingehen auf Änderungen haben Vorrang vor Prozessen & Werkzeugen ausgedehnter Dokumentation Vertragsverhandlungen strikter Planverfolgung Wir Schätzen auch die Punkte auf der rechten Seite, die auf der linken Seite wertschätzen wir jedoch mehr! www.agilemanifesto.org
Leichtgewichtig So wenig Formalismen wie irgendwie möglich Nur so viele Vorgaben wie unbedingt nötig
Die Magie hinter Scrum
Arbeiten in Iterationen In Scrum heißen Iterationen Sprints Jeder Sprint beinhaltet alle Projektphasen Jeder Sprint erzeugt ein Produktinkrement
Die Rollen in Scrum
Der Ablauf eines Sprints
Das Team besteht aus allen Personen, die fortwährend zur Erstellung des Produktes benötigt werden, wie z.b. Entwickler, Tester, Designer, Architekten Größe: 3 9 Personen
Der Product Owner Fachlich Verantwortlich für das Produkt Entscheidet: Welche Anforderungen werden im Produkt berücksichtigt In welcher Reihenfolge werden die Anforderungen eingeplant (Priorisierung) Hat idealerweiser Budgetverantwortung Pflegt das Product Backlog Ist kein Vorgesetzter des Teams Ein Product Owner betreut idealerweise ein Team (offiziell sind mehr erlaubt) Jedes Team hat einen Product Owner Die Rolle Product Owner ist ein Vollzeitjob!
Der Scrum Master verantwortlich für den Scrum Prozess ist kein Vorgesetzter kann nur überzeugen, nicht vorschreiben Lehrer und Coach für Team und Product Owner jedes Team hat einen Scrum Master ein Scrum Master kann mehrere Teams betreuen Pflegt das Impediments Log Beseitigt Hindernisse des Teams ist nicht Teil des Teams Moderiert die Meetings
Die Stakeholder Alle Personen, Gruppen oder Organisationen, die Einfluss auf das Projektergebnis nehmen wollen, wie z.b.: Kunden Fachabteilungen Anwender Geschäftsführung Vertrieb Betrieb Gesetzgeber etc.
Als Sachbearbeiter möchte ich in einer Suchmaske Kundennummer, Vorname und/oder Nachname zu Kunden eingeben können und als Ergebnis eine Liste aller Kunden mit Kundennummer, Vorname, Nachname und Gesamtumsatz des letzten Jahres am Bildschirm sehen, die die Suchkriterien erfüllen.
Akzeptanzkriterien konkrete Beschreibungen von Beispielfällen Woran würde ich merken, das die Anforderung erfüllt ist? helfen dem Product Owner bei der sinnvollen Beschreibung der Anforderung helfen dem Team bei der korrekten Umsetzung der Anforderung sind die Abnahmekriterien im Review Meeting
Jede Anforderung soll einen Businessmehrwert generieren soll möglichst unabhängig von anderen sein soll möglichst klein sein muss in einem Sprint umsetzbar sein
Product Backlog tabellarische Liste aller Anforderungen wird vom Product Owner gepflegt eindeutig priorisiert geschätzt lebendes Dokument (kein Einsendeschluss)
Prioritäten sehr wichtig wichtig normal wäre schön wird niemals gemacht das Product Backlog ist eindeutig priorisiert!
agiles Schätzen eine Schätzung ist eine Schätzung Anforderungen können mehrfach geschätzt werden geschätzt wird immer durch das Team Schätzungen sind ein Hilfsmittel und kein eigener Mehrwert den Aufwand für das Schätzen möglichst gering halten
Schätzeinheiten Ideale Tage Story Points
Story Points ein relatives Schätzmaß Aufwand/Dauer/Komplexität/Risiko einer Anforderung im Verhältnis zu anderen Anforderungen Teamindividuell
Fibunaccizahlen als Story Points
Story Points in Worten 0 = kein Aufwand 1 = sehr kleiner Aufwand 2 = kleiner Aufwand 3 = mittlerer Aufwand 5 = großer Aufwand 8 = sehr großer Aufwand 13 = riesiger Aufwand 20 = unfassbarer Aufwand 40 = gigantischer Aufwand 100 = unmöglich/ absolut keine Idee
Team Estimation Game schnelles Schätzen einer großen Anzahl von Anforderungen in kurzer Zeit gut geeignet zum Schätzen des initialen Product Backlogs Ablauf: Alle Anforderungen sind als Karten in einem Stapel vorhanden Jedes Teammitglied agiert nacheinander und hat dabei folgenden Optionen: Neue Karte ziehen: Karte vom PO erklären lassen und an der Wand einsortieren im Verhältnis zu anderen Karten. Oberhalb ist weniger Aufwand, unterhalb mehr Aufwand, rechts daneben genauso viel Aufwand. Entscheidung mit einem Satz begründen, der Rest der Gruppe kommentiert das nicht! Karte umhängen: Eine Karte an der Wand umhängen, Klebepunkt anbringen, kurz erklären, keine Diskussion! Passen: Diese Runde aussetzen. Passen alle Teammitglieder in der Runde, ist diese Phase des Team Estimation Game beendet Das Ganze solange bis alle Teammitglieder in einer Runde passen Anlegen der Metrik links neben die Gruppen, dabei Fragen, ob die oberste Gruppe wirklich kein Aufwand ist oder eher ein sehr kleiner Aufwand Weiterspielen und dabei im Verhältnis der Metrik evtl. Gruppen zusammenfassen oder Anforderungen umhängen. Solange bis Team vollständig damit einverstanden. Werte bei allen Anforderungen vermerken
Planning Poker Gut geeignet, um schnell weitere Anforderung für das Backlog schätzen zu können Jedes Teammitglied hat ein Kartenset bestehend aus allen verfügbaren Schätzwerten Ablauf pro Story: Product Owner liest Story vor und erklärt kurz Jedes Teammitglied schätz für sich den Aufwand und legt die entsprechende Karte verdeckt vor sich ab Wenn alle eine Schätzung abgelegt haben, decken alle gemeinsam auf Der mit dem niedrigsten und der mit dem höchsten Wert erklären kurz, warum dieser Wert. Die anderen diskutieren nicht mit! Danach neu schätzen Das ganze solange, bis ganze Gruppe einen gemeinsamen Wert hat. Ab dem dritten Durchlauf für eine Anforderung ist auch Handeln untereinander erlaubt
Planning Meeting Teilnehmer: Product Owner, Scrum Master, Team Ziel: Gefülltes Sprint Backlog für den nächsten Sprint Ablauf: Product Owner stellt den oberen Teil des Product Backlogs vor und welches Ziel er in dem Sprint gerne erreichen möchte. Team gibt ihm Feedback aus technischer Sicht zur Reihenfolge der Anforderungen Team bestimmt, wie viel Aufwand (z.b. in Story Points) es sich in diesem Sprint vornehmen möchte Product Owner stellt nun nacheinander die Stories im Detail vor Team bricht die jeweilige Story in Tasks (ToDos) runter Team entscheidet, ob die Story mit ihren Tasks noch in den Sprint passt Das Ganze solange, bis Team entscheidet, dass der Sprint voll ist Wenn Sprint voll, Commitment vom Team zu dem Sprintziel Product Owner entscheidet über die Reihenfolge der Stories! Team entscheidet, wie viele Stories in den Sprint kommen!
Scrum Wand
Daily Scrum Teilnehmer: Product Owner, Scrum Master, Team, weitere Personen (nur als Zuhörer) Jeden Tag am selben Ort und zur selben Uhrzeit Dauer maximal 15 Minuten! Jeder Teilnehmer beantwortet folgenden drei Fragen: Was habe ich seit dem letzten Daily Scrum gemacht? Was plane ich bis zu nächsten Daily Scrum zu machen? Was behindert mich? Es wird im Daily Scrum nicht diskutiert! Wer Diskussionsbedarf hat, klärt den im Anschluss mit den Betroffenen Scrum Master dokumentiert die Hindernisse im Impediment Backlog Im Anschluss an das Daily Scrum, die Scrum Wand und den Sprint Burndown Chart aktualisieren
Sprint Burndown Chart Idealkurve initial einzeichnen (blaue Linie Den im Sprint verbliebenen Restaufwand eintragen (rote Linie) Täglich (zum Daily Scrum) aktualisieren Kurve zeigt den Verlauf des Sprintfortschritts an
Review Meeting Teilnehmer: Product Owner, Scrum Master, Team, ausgewählte Stakeholder Ziel: Präsentation des Sprintergebnisses und fachliche Abnahme der neuen Features Vorbereitung: Bei einem Softwareprojekt erzeugt das Team einen aktuellen Build und deployed den auf einem Demonstrationsrechner. Außerdem werden Testdaten gemäß der Akzeptanzkriterien in der Datenbank bereit gestellt Team erklärt kurz, wie der Sprint verlaufen ist und lässt dann den Product Owner und die anwesenden Stakeholder den aktuellen Build ausprobieren Product Owner testet die im Sprint Backlog als Fertig vermerkten Stories gegen die Akzeptanzkriterien und nimmt diese dabei fachlich ab. Stories werden nur ganz oder gar nicht abgenommen! Das Review Meeting ist kein technischere Abnahmetest! Product Owner und Stakeholder geben dem Team Feedback zum aktuellen Entwicklungsstand des Produktes. Ggfs. Entstehen dabei neue Anforderungen Product Backlog Die Summe der Aufwände aller abgenommener Stories ergibt die Entwicklungsgeschwindigkeit des abgelaufenen Sprints Aktualisierung des Velocity Reports Aktualisierung des Release Burndown Charts Das Review Meeting dient der Optimierung des Produktes!
Retrospektive Teilnehmer: Product Owner, Scrum Master, Team, ggfs. weitere Personen Ziel: Maßnahmen zur Verbesserung des Prozesses Findet zum Abschluss jedes Sprints statt! Regeln: Offene und ehrliche Kommunikation Konstruktive Kritik Trennung von Person und Sache Gegenseitiger Respekt Moderation durch den Scrum Master, außer er ist aktuell Teil des Problems, dann externer Moderator Es ist nicht notwendig, in einer Retrospektive direkt alle Themen zum Prozess erschöpfend bearbeiten zu müssen. Fokussierung auf die zwei oder drei wichtigsten. Zum Abschluss des nächsten Sprints gibt es ja die nächste Retrospektive Kaizen Die Retrospektive dient der Optimierung des Prozesses!
Beispielablauf einer Retrospektive Check-In durch den Moderator (Begrüßung, Erläuterung von Ziel, Regeln und Ablauf, Stimmungsabfrage) Daten sammeln Alle Teilnehmer schreiben jeder für sich Punkte zum aktuellen Sprint auf Karten. Pro Karte ein Punkt. Klassifizierung der Punkte in positiv oder negativ. Dauer 5 10 Minuten Die Teilnehmer hängen nacheinander unsortiert ihre Karten an eine Metaplanwand. Pro Karte kurze Erklärung. Keine Diskussion! Wenn alle Karten hängen, dann gemeinsames Gruppieren der Karten in Themen. Solange bis ganze Gruppe damit zufrieden ist. Wenn gewünscht, Überschriften für Themen definieren Priorisierung der Themen durch Dot-Voting. Jeder Teilnehmer kann nach Belieben drei Klebepunkte auf die Themen verteilen. Die zwei oder drei Themen mit den meisten Klebepunkten werden in dieser Retrospektive bearbeitet Daten bearbeiten Pro Thema (höchsten drei in einer Retrospektive) feste Zeitbox vereinbaren Klären, was genau in diesem Sprint in diesem Thema passiert ist Gründe dafür analysieren Maßnahmen beschließen, mit denen das Thema ab dem nächsten Sprint geklärt werden kann Maßnahmen öffentlich aufhängen (Flipchartbogen oder Karteikarten an Wand im Teamraum) Metaretrospektive Wie ist die Retrospektive gelaufen und wie kann die nächste noch besser werden Check-Out durch den Moderator (Zusammenfassung der beschlossenen Maßnahmen, Bedanken für die gute Zusammenarbeit, Verabschiedung)
Dauer der Meetings Beispiel bei einem 4 Wochensprint (bei kürzeren Sprints entsprechend kürzer) Planning Meeting: 8 h Review Meeting: 4 h Retrospektive: 3 h Daily Scrum: maximal 15 min Schätzrunden: maximal 30 min (Ausnahme: Schätzen des initialen Product Backlog: 1-2 h) In der Retrospektive kann beschlossen werden, die Länge der Meetings anzupassen. Teams mit mehr Erfahrung werden nach und nach weniger lange für die Meetings benötigen
Zeitliche Organisation der Sprints Sprints nicht am Montag beginnen und am Freitag beenden! Beispiel für einen 4 Wochensprint: Donnerstag: Planning Meeting Sprint 1 Freitag: Start Entwicklungsphase / Sprintarbeit vier Wochen später Dienstag Nachmittag: Eincheckstop / Code freeze Mittwoch Vormittag: Vorbereitung Review Meeting / Durchführung Review Meeting Mittwoch Nachmittag: Retrospektive Donnerstag: Planning Meeting Sprint 2 Es gibt keine Zeit außerhalb des Sprints!
Testen & Qualität in Scrum Idealziel: Jeder Sprint erzeugt ein potentiell auslieferbares Produktinkrement! Es gibt keine separate Testphase, die Qualität wird bereits beim Erstellen des Produktes erzeugt/sichergestellt Das Team ist verantwortlich für die technische Qualität des Produktes Qualität ist nicht verhandelbar technische Schulden Maßnahmen: Definition von Akzeptanzkriterien als teil der Anforderungsdefinition Tester (technisch/fachlich sind Teil des Teams) Tester testen direkt nach der Erstellung eines Features Tester arbeiten schon bei der Erstellung eines Features zusammen mit dem Entwickler Pair Programming Test Driven Development (TDD) Testautomatisierung Continuous Integration Erstellung einer Definition of Done durch Team und Product Owner Das Review Meeting ist nicht der früheste sondern der späteste Zeitpunkt, an dem der Product Owner neue Features gezeigt bekommt (ist bereits wären der Entwicklungsphase äußerst erwünscht)
Wann testen?
Scrum Board mit Testphase
Featuresprint Sprintarten neue Produktfeatures (neue Business Values) werden erstellt Erzeugt idealerweise ein potentiell auslieferbares Produktinkrement Releasesprint Der aktuelle Produktstand wird releasefähig gemacht (testen, dokumentieren, etc.) Nur notwendig, wenn nicht innerhalb der Featuresprints ein potentiell auslieferbares Produktinkrement erzeugt werden kann Explorationssprint Technisches oder fachliches Wissen wird erzeugt, um Anorderungen schätzen und planen zu können Es werden keine Features erzeugt, dieser Sprint erzeugt nur Wissen!
Releasemanagement in Scrum Das Releasemanagement wird durch den Product Owner durchgeführt Geplant wird mit den Product Backlog Das Product Backlog ist ein offenes Dokument, d.h. es können jederzeit neue Anforderungen hinzukommen Der Velocity Report dokumentiert die Entwicklung der Entwicklungsgeschwindigkeit im Projekt und hilft bei der Einschätzung des zukünftigen Verlaufs Der Release Burndown Chart zeigt den aktuellen Projektfortschritt und die Entwicklung im Projekt. Er ermöglicht Prognosen über den Fertigstellungstermin
Velocity Report Entwicklungsgeschwindigkeit des Teams Dokumentation der realisierten Aufwandspunkte im jeweiligen Sprint (rote Linien) Aktuelle Durchschnittsgeschwindigkeit (blaue Linie) Instrument für die Prognose der zukünftigen Entwicklungsgeschwindigkeit
Release Burndown Chart Den im Release verbliebenen Restaufwand eintragen (rote Linie) Der Aufwand zu einer Story/einem Feature wird immer ganz oder gar nicht berücksichtigt nach jedem Sprint (Review Meeting) aktualisieren Kurve zeigt den Verlauf des Releasefortschritts an Durch Anlegen der aktuellen Entwicklungsgeschwindigkeit (aus dem Velocity Report) Prognose für den Fertigstellungstermin (blaue Linien)
Planen in Scrum Wir planen in Scrum! so viel, wie sinnvoll nötig so wenig, wie sinnvoll möglich Je weiter in der Zukunft eine geplante Tätigkeit liegt, umso größer die Wahrscheinlichkeit, dass sie nicht oder anders als geplant durchgeführt wird Verschwendung der Zeit, die für das Planen verwendet wurde
Cone of Uncertainty Quelle: Mike Cohn Agile Estimating and Planning
Skalierung in Scrum Organisation bei nur einem Team. Teamgröße maximal 9 Personen!
Skalierung in Scrum Organisation bei drei Teams. Teamgröße pro Team immer noch maximal 9 Personen!
Skalierung in Scrum Szenario: Projekt besteht aus drei Teilsystemen, die Anforderungen sind gut auf die Teilsysteme aufteilbar. Jedes Team betreut ein Teilsystem. Für jedes Teilsystem wird jeweils ein Product Backlog gepflegt.
Skalierung in Scrum Szenario: Projekt besteht aus einem großen System, die Anforderungen sind nicht auf Teilsysteme aufteilbar. Alle Team arbeiten parallel auf der gemeinsamen Code Basis, es wird nur ein Product Backlog gepflegt.
Scrum of Scrums Bei mehreren Scrum Teams im gleichen Projekt notwendig zur Abstimmung der Teams untereinander Vertreter aller Teams treffen sich zu einer Art Daily Scrum und beantworten für ihr Team folgende drei Fragen: Was haben wir seid dem letzten Scrum of Scrums gemacht? Was planen wir bis zum nächsten Scrum of Scrums zu machen? Was behindert uns derzeit? Keine Diskussion, wenn hier Abstimmungsbedarf festgestellt wird, beauftragen die Teamvertreter die jeweils Betroffenen in ihren Teams damit, sich mit den Betroffenen in den anderen Teams abzustimmen Findet alle ein bis drei Tage statt, je nachdem wie viel Abstimmungsaufwand in der Regel notwendig ist
Featureteam Arten von Teams Erstellt immer komplette Features durch alle Komponenten hindurch Durchstich Komponententeam Erstellt Funktionalität nur innerhalb einer Komponente. Keine kompletten vom Endbenutzer nutzbare Features
Kombination von Teamarten
Trivia Eine Einführung von Scrum betrifft alle Teile eines Unternehmens, die mit dem zu erstellenden Produkt zu tun haben Den größten Vorteil erzielt Scrum bei stabilen Teams mit längeren Projektlaufzeiten, da hier die Prozessverbesserungen besser zur Geltung kommen Da direkte Kommunikation ein Schlüsselfaktor von Scrum ist, ist räumliche Nähe sowohl innerhalb des Teams wie auch zwischen Team und Product Owner/Stakeholder von Vorteil
Bücher Weitere Quellen Scrum Agiles Projektmanagement erfolgreich einsetzen, Roman Pichler Agile Softwareentwicklung: Mit Scrum zum Erfolg!, Mike Cohn User Stories: für die agile Software-Entwicklung mit Scrum, XP u.a., Mike Cohn Agile Estimating and Planning, Mike Cohn PDFs Scrum and XP from the Trenches, Henrik Kniberg Podcasts http://www.infoq.com/minibooks/scrum-xp-from-the-trenches Scrumidable, Carsten Czeczine Videovortrag http://www.scrumidable.de Scrum Was ist das?, Carsten Czeczine http://rheinjug.de/videos/gse.lectures.app/talk.html#scrum