Wir verwenden User Storys aber nicht ausschließlich. User Storys
bekommen im planning oft sehr viele Story Points – meist mehr als in einem Sprint erledigt
werden kann. Also werden die meisten in kleinere Storys geteilt.
Beispiel:
Story mit der Nr.1
Story:
Pattern: Als <Rolle> will/kann ich
<Ziel erreichen> damit/so dass ich <Begründung>. (von Ralf
Wirdemann)
Als CEO
will ich dem Kunden ein neues Maschinenkonzept vorstellen, damit wir
Technologieführer bleiben.
Umfang: (Der Umfang steht in Backlog und ist bei uns automatisch ein Teil der DOD)
- Grobe Kostenabschätzung
- Grobes Layout zur Bestimmung des Platzbedarfes
- ...
Jetzt hängt
es von der Schätzung ab ob wir diese Story teilen oder nicht. Wenn wir teilen
dann so das die Storys möglichst interdisziplinär bleiben.
Das heißt
wir teilen nicht auf in: Konzept elektrisch / Konzept mechanisch / Konzept
Software
Sondern
in: Konzept Abtransport / Konzept Bedienen/ Konzept … - somit sind immer
alle Disziplinen gemeinsam im Einsatz – die Qualität der Lösung ist besser.
Was ich bei
diesem Beispiel noch zeigen möchte ist das es sehr wichtig ist agiles Vorgehen
möglichst schon beim Projekt Startup zu verwenden, bevor es Lastenhefte,
Pflichtenhefte usw. gibt.
Wo kommen
die Anforderungen wie …eine Maschine für 1 Mio. Flaschen pro Stunde… her - könnte man sich fragen.
Diese
Sachen sind Teil der Vision. Marcello Leonardi von Namics. hat das auf
dem scrum breakfast in St. Gallen schön beschrieben.
Eine Vision setzt sich
zusammen aus:
- Produkt
Datenblatt (grobe Spezifikation des Produktes, 1Mio Flaschen pro Stunde…)
- Produkt
Schachtel (wie schaut das Ding aus? Jeder soll eine Idee davon haben wie die
Verpackung / Verschalung ausschauen könnte)
- Presse
Mitteilung (was hätte man gerne das über das Produkt geschrieben wird)
- Elevator
Pitch (kurzes Statement über die Positionierung des Produktes und die
Abgrenzung zum Mitbewerber)
Das Erstellen der Vision ist Arbeit des Teams! Der PO muss gut vorbereitet sein und dann gemeinsam mit dem Team die Vision erstellen.
Wieso? Es
ist essentiell das das Team die Vision versteht und dahinter steht damit die
Umsetzung auf die Vision ausgerichtet wird.
Neben den
User Storys haben wir viele ganz „normale“ Sachen die gemacht werden müssen um
die Vision zu erreichen. Wichtig ist das sie im selben Backlog stehen und somit
priorisiert sind. Die Priorisierung muss der PO mit dem Team abstimmen denn oft
sind Abhängigkeiten der Storys untereinander gegeben – egal wie intensiv man
versucht diese zu vermeiden. Das Team schreibt natürlich auch Storys und muss
dann dem PO die Begründung liefern wieso das gemacht werden sollte.
Das Thema
ist sehr weitläufig – man könnte eine Buch darüber schreiben wobei es nicht DIE
richtige Vorgehensweise gibt. Wichtig, und immer richtig, ist die Retrospektive.
Das Team, zu dem auch der
PO gehört, muss gemeinsam durch "inspect and adapt" herausfinden, welches der
beste individuelle Weg ist.