User Storys in der Hardware Entwicklung

Bernd Wawczyniak von Bosch Engineering hat mich gefragt ob und wie wir User Storys einsetzen:

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.