-
-
-
-
-
-
-
Scrum beschreibt Rollen, Rituale (Zeremonien und Meetings), und Artefakte die sich für eine iterative Entwicklung von (Software)-Produkten als nützlich erwiesen haben, und liefert somit dem Agile Manifest ein Rahmenwerk für die Zusammenarbeit der Beteiligten Personen.
Artefakte in Scrum
Scrum gibt im Rahmenwerk folgende Artefakte vor, mit denen die Verwaltung des Projekts organisiert wird:
Vision
Die Vision ist im Normalfall eine kurze Beschreibung was mit dem zu erstellenden Produkt erzielt werden soll. Für die Erstellung der Vision werden häufig folgende fünf Fragen gestellt (Frei übernommen von The Product Vision) :
- Wer wird dieses Produkt kaufen und wer sind die Zielkunden?
- Welche Kundennutzen wird das Produkt adressieren?
- Welche Produktattribute sind kritisch und müssen deshalb auf alle Fälle umgesetzt werden damit das Produkt erfolgreich sein kann?
- Wie ist das Produkt mit anderen Produkten vergleichbar? Was sind die Unique Selling Points dieses Produktes?
- Was ist der Zeitrahmen und das Budget in dem die Entwicklung und Auslieferung des Produktes erfolgen muss?
Die Vision muss von allen an der Produktentwicklung beteiligten Personen verstanden werden können.
User Story
Um die Vision realisieren zu können, müssen die einzelnen Komponenten, Prozessabläufe usw. beschrieben werden. Hierfür wird im Scrum Umfeld meistens User Stories verwendet.
Eine User Story besteht aus einem Titel, einer Beschreibung und den korrespondierenden Abnahmekriterien.
Die User Story muss von allen beteiligten Personen (Business und Entwicklung) verstanden werden können und dient als Vertrag zwischen den Parteien. Eine User Story muss ein Artefakt in der Form beschreiben, dass dies innerhalb eines kurzen Zeitraums umgesetzt und überprüft werden kann. Beispiel:
Titel
Kunden Login
Beschreibung
Als Kunde möchte ich mich am System mit meinem Usernamen und Passwort anmelden können, damit ich die erweiterten Funktionen nutzen kann.
Abnahmekriterien
- Dem System bekannter Kunde kann sich mit Username und Passwort anmelden und wird zu der Kunden-Startseite geführt
- Ein nicht bekannter Kunde kann sich nicht anmelden
- Falsch eingegebenes Passwort oder Username führt zu einer Fehlermeldung
- Nach drei falschen Eingaben wird der Account für 20 Minuten gesperrt
Epos
Um die Vision umsetzen zu können, müssen die einzelnen Themengebiete beschrieben werden. Ganze Funktionsgruppen sind dabei zu groß um diese innerhalb kurzer Zeiteinheiten umsetzen zu können. Die Beschreibung großer Zusammenhänge innerhalb des Produktes werden Epos (englisch Epic) genannt. Diese großen "Geschichten" werden während des Projekts in User Stories aufgebrochen und umgesetzt (Teile-Herrsche).
Beispiel für ein Epos:
Titel
Alle Kundenbewegungen müssen 10 Jahre historisiert und einsehbar sein.
Beschreibung
Als Auditor muss ich die Möglichkeit haben alle Kundenbewegungen innerhalb des Systems 10 Jahre lang nachvollziehen können damit ich den gesetzlichen Bestimmungen nachkommen kann und jederzeit Audits fahren kann.
Abnahmekriterien
- Jede Kundenbewegung (Beispiel Login, Suchen nach Artikel, Auswahl des Artikels, Bestellung des Artikels, Rechnung bezahlt am ...) wird registriert
- Pro Kunde können die Bewegungen selektiert werden
- Sinnvolle Reports werden dargestellt
- Die Bewegungen können nicht verändert werden (Verwendung von WORM Technologie)
Produkt Backlog
Im Produkt Backlog werden alle bisher erkannten User Stories (egal ob in Form von Epos oder schon klein genug als User Story) abgelegt und priorisiert (Siehe Backlog Grooming). Ein Produkt Backlog ist so angelegt, dass neue Erkenntnisse jederzeit als User Stories hinzugefügt werden können. Die im Produkt Backlog abgelegten User Stories (und Epos) sind mit der Vision abgestimmt und beinhalten nur Beschreibungen die zur Zielerreichung der Vision benötigt werden.
Optional Projekt Backlog
Bei größeren Produkten werden zu weilen mehrere Projekte (parallel oder sequentiell) gestartet um das Produkt zu entwickeln. Weiter können mehrere Produkte in entsprechenden Projekten erarbeitet werden. Hierfür können die im Produkt Backlog festgelegten Epos auf mehrere Projekt Backlogs aufgeteilt werden. Ein Beispiel für die Vision, das Produkt-Backlog und zwei Projekten:
Iterationsbacklog
Scrum ist eine iterative Entwicklungsvorgehensweise. Das bedeutet, dass in einem festgelegten Zeitraum, z.B. zwei Wochen, bestimmte Projektergebnisse vereinbart und umgesetzt werden. Die hierfür benötigten User Stories werden zwischen den Beteiligten verhandelt und in das Iterationsbacklog eingetragen. Im Folgenden findet sich ein Beispiel für zwei Projekte und zwei Projektteams die an der Umsetzung beteiligt sind.
In diesem fiktiven Beispiel soll in der aktuellen Iteration User Story 1, 2, 4, 5 und 7 umgesetzt werden. Damit werden bis auf User Story 3 die Epos 1 vollständig abgearbeitet. Epos 2 wird User Story 7 erarbeitet. Beide Epos sind noch nicht vollständig vorhanden.
Tasks
User Stories beschreiben zu realisierende Artefakte die von einem Team innerhalb einer Iteration umgesetzt werden können. Jede User Story wird vom Team in kleinere Schritte (Tasks ) zerlegt um die Realisierung durchführen zu können. Ein Task kann im Normalfall in einem Arbeitstag umgesetzt werden. Die folgende Skizze zeigt den Zusammenhang zwischen User Story und Task auf. Für User Story 1 werden zwei Tasks benötigt, für User Story 2 nur einer.
Rollen in Scrum
Innerhalb eines Projektes müssen unterschiedliche persönliche Eigenschaften verbunden werden um zielsicher und effizient Produkte entwickeln zu können (Siehe Teamrollen nach Belbin).
Für Scrum wurden folgende Rollen festgelegt:
Product Owner
Der Product Owner erstellt die Vision und verwaltet das Produkt Backlog. Diese Rolle kennt das Geschäftsumfeld und die Kunden. Häufig werden hier Businessvertreter eingesetzt. Die Rolle kann jedoch auch von mehreren Personen ausgefüllt werden. Beispiel: Ein technischer Produkt Owner der den operationellen Betrieb kennt, einen Architekten und Businessvertreter. Eine Person wird als "Master-Produktowner" ausgewählt. Diese Person entscheidet schlussendlich welche User Stories als nächstes umgesetzt werden.
Scrum Team
Das Team beinhaltet die Mitarbeiter, die für die Umsetzung der einzelnen User Stories notwendig sind. Alle notwendigen Skills sind innerhalb des Teams vorhanden um die Aufgaben zu erledigen. (Cross Functional Team) Die Teilnehmer des Teams werden idealerweise über einen längeren Zeitraum in gleicher Besetzung gehalten. Ein Team kann hiermit zusammenwachsen und die Velocity (Entwicklungs-Geschwindigkeit) erhöhen.
Scrum Master
Diese Rolle sorgt dafür, dass alle Beteiligten miteinander arbeiten können. Sie stellt dem Team eine Umgebung zur Verfügung in dem es optimale Arbeitsbedienungen vorfindet.
Experte
Häufig werden für kurze Zeiträume weitere Skills benötigt um User Stories abarbeiten zu können. Beispiele: Ein Rechtsanwalt muss für zwei Iterationen mitarbeiten um rechtliche Fragen zu beantworten. Diese Personen werden bei Bedarf zum Team hinzugefügt, sind Teil des Teams auf Zeit, und verlassen nach dem Einsatz wieder das Team.
Stakeholder
Alle Personen, die nicht direkt mit dem Projekt zu tun haben, werden hiermit abgebildet. Jeder darf einsehen was das Team arbeitet und wie der Projektfortschritt aussieht. Stakeholder dürfen jedoch nur observieren. Falls sie Einfluss auf die Arbeit nehmen wollen, müssen sie über den Product Owner und Scrum Master ihre Wünsche äußern. Ziel ist es, dass das Team sich auf die vereinbarten User Stories konzentrieren kann und nicht abgelenkt wird.
Der Scrum Lebenszyklus
Die Artefakte und Rollen verwenden in Scrum folgenden Lebenszyklus für die Realisierung des Produktes:
Rituale (Zeremonien und Meetings)
Im Scrum Lifecycle sind folgende Rituale beschrieben:
Produkt Backlog Grooming
Koordiniert durch: Produkt Owner
Owner: Produkt Owner
Während der Projektlaufzeit erstellt der Produkt Owner die zu realisierenden User Stories und fügt sie in das Produkt Backlog ein. Als Grundlage für die User Stories dient die Vision. Die Verfeinerung und Ausformulierung der einzelnen User Stories kann von anderen Personen als dem Produkt Owner durchgeführt werden. Owner ist jedoch der Produkt Owner.
Planungsmeeting 1
Koordiniert durch: Scrum Master
Teilnehmer: Produkt Owner, Team und Scrum Master.
Bei diesem Meeting erläutert der Produkt Owner dem Team welche User Stories in der nächsten Iteration abgearbeitet werden sollen. Das Team stellt Fragen und schätzt ab ob die User Stories in einer Iteration umgesetzt werden können. Am Ende des Meetings vereinbaren das Team und der Produkt Owner den Lieferumfang (die User Stories) die als nächstes umgesetzt werden. Nicht gut genug formulierte User Stories werden abgelehnt und zum Produkt Backlog Grooming zurückgeführt.
Planungsmeeting 2
Koordiniert durch: Scrum Master
Teilnehmer: Team, Scrum Master und Optional Produkt Owner
Das Team nimmt die vereinbarten User Stories und zerlegt die Aufgaben in Tasks die in einem Tag erledigt werden können.
Daily Stand-Up Meeting
Koordinator: Scrum Master
Teilnehmer: Team, Scrum Master, optional Produkt Owner und Stakeholders
Während die Iteration läuft werden Tasks abgearbeitet und Teile des Produktes (potentiell lieferbares Produktinkrements) erstellt.
Jeden Tag zur gleichen Zeit am gleichen Ort trifft sich das Team und jedes Team Mitglied beantwortet drei Fragen:
- Was habe ich gestern erarbeitet?
- Was werde ich heute erarbeiten?
- Welche Verhinderer (Impediments) habe ich (Was blockiert mich)?
Falls Impediments vorhanden sind, werden diese vermerkt und vom Scrum Master gelöst.
Review Meeting
Koordinator: Scrum Master
Teilnehmer: Team, Scrum Master, Produkt Owner und Optional Stakeholders
Beim Review Meeting wird das erstellte potentiell lieferbares Produktinkrement präsentiert und kontrolliert ob die in den User Stories festgelegten Abnahmekriterien erreicht wurden. Falls dem so ist, nimmt der Produkt Owner die User Stories ab. Falls Fehler vorhanden sind, oder User Stories nicht abgeschlossen wurden, wird die entsprechende User Story nicht akzeptiert und fließt wieder in das Produkt Backlog ein. Stakeholder können bei diesem Meeting einsehen wie der aktuelle Zustand der Entwicklung aussieht.
Retrospektive
Koordinator: Scrum Master
Teilnehmer: Team, optional Produkt Owner
In diesem Meeting analysiert das Team was innehalb der Iteration gut lief und was verbessert werden sollte. Das Team analysiert den aktuell im Einsatz befindlichen Prozess und versucht diesen zu optimieren um schneller und stabiler entwickeln zu können. Systemische Probleme, die das Team nicht lösen kann, wird vom Scrummaster aufgenommen und dem Management präsentiert. Aus der Retrospektive werden konkrete User Stories erstellt die eine Prozessverbesserung beinhalten. Diese User Stories werden beim nächsten Produkt Backlog Grooming berücksichtigt und aufgenommen. Damit wird ein kontinuierlicher Verbesserungsprozess erreicht.
- - - - -
- 5 Comments -
---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - -- -
-
-Damian Dessler
-Ein sehr ausführlicher und guter Beitrag, es war für mich nur Anfangs schwer herauszufinden, was der Inhalt hinter "Scrum Lebenszyklus" ist.
Des Weiteren weicht die Beschreibung doch vom Scrum Standard ab, was den ein oder anderen durchaus verwirren könnte.
Ich habe für den Bereich für eine bessere Übersicht ein Inhaltsverzeichnis eingebettet, um die Struktur zu verstehen. ich möchte an der Stelle aber auch nicht sofort was verändern, da vieles davon richtig ist bzw. es auch in den Grafiken eingebettet ist. Vielleicht können wir mal darüber reden und gemeisnam anpassen Roland Baldenhofer?
Viele Grüße,
Damian
--- Permalink
-
--- 07. May 2013
-
---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-- -
-
-Roland Baldenhofer
-Hallo Damian,
- --vielen Dank für das Inhaltsverzeichnis. Ich finde das toll!
-Wenn du etwas ergänzen willst, dann kannst du das gerne tun. Ich habe absichtlich nicht das Gleiche geschrieben wie im Scrum Standard, da ich Scrum mal von dieser Seite aus beleuchten wollte. Wenn du ergänzen willst, bist du natürlich herzlich dazu eingeladen.
-Grüsse
Roland
--- Permalink
-
--- 07. May 2013
-
-- -
-
-Damian Dessler
-Okay, weil sonst hätte ich für den Einstieg einen Scrum Guide geschrieben, der wirklich die Elementaren Dinge beleuchtet als Art "Einstieg".
Ich denke, ich werde das in der Eingangsseite beschreiben.
Vielen Dank,
Damian
--- Permalink
-
--- 07. May 2013
-
-- -
-
-Wolfram Lührig
-Moin,
sehr schöne Zusammenfassung. Das beschriebene Scrum enthält allerdings bereits die Erweiterung auf User Stories. Diese gehören nicht zum ursprüngliche Scrum Rahmen. Allerdings halte auch ich dies für die beste Methode. Die Erstellung guter User Stories ist allerdings die große Aufgabe dabei - ein Übungsprozess, besonders für den PO.
Ich bin eben dabei mir den Lebenszyklus von User Stories zu erarbeiten, wodurch ich auf diese Seite aufmerksam geworden bin. Ein Detail, was aber eben besonders wichtig für den Ablauf von Scrum mit User Stories ist und bei uns immer wieder zu Diskussionen führt.
Gruß
Wolfram
P.S. ich bin noch etwas über den Begriff des Iterationsbacklogs gestolpert. Etwas ungewohnte Formulierung, ich kenne eher Sprint Backlog.
--- Permalink
-
--- 20. Jan 2014
-
-- -
-
-Roland Baldenhofer
-Hi Wolfram,
ich verwende bei meinen Kunden meistens den Begriff Iterationsbacklog, da das sich eher auf eine Iteration bezieht. Das verstehen die oft besser als den Begriff Sprint Backlog. In den Lehrbüchern steht natürlich Sprint Backlog.
Grüsse
Roland
--- Permalink
-
--- 20. Jan 2014
-
-