User Stories sind fachliche Einheiten, die Wert für Kunden repräsentieren. Dabei sind Kunden sowohl Benutzer als auch andere Stakeholder wie Support.
A story should be understandable to customers and developers, testable [and] valuable to the customer […].
– Kent Beck & Martin Fowler: Planning Extreme Programming
User Stories sind die Einheiten, in denen agile Entwicklung voranschreitet.
We demonstrate progress by delivering tested, integrated code that implements a story.
– Kent Beck & Martin Fowler: Planning Extreme Programming
Working software is the primary measure of progress.
– Agiles Manifest
Schneide vertikal.
Schneide nach fachlichen Aspekten, nicht nach technischen Schichten oder Wasserfall-Phasen.
Ein Beispiel:
Bernd Schiffer (2008) Horizontaler und vertikaler Schnitt von Stories
Vertikaler Schnitt bringt folgende Vorteile mit sich.
- Die fachlichen Details der Story werden explizit.
- Das Umsetzungsteam kommt früher zu funktionierender Software. Es lernt so über die Umsetzung und reduziert Umsetzungsrisiken.
- Der Product Owner erfährt früher, ob die entwickelte Funktionalität den gewünschten Nutzen stiftet.
- Der Product Owner kann differenzierter priorisieren, welche Teile der Funktionalität wichtig sind.
- Die Software kann früher ausgeliefert werden.
- Fachliche Schnitte vereinfachen die Planung, da sie Abhängigkeiten zwischen Arbeitseinheiten reduzieren.
Auch wenn nicht jedes Story-Scheibchen ausgeliefert wird, ist jedes einzelne dadurch wertvoll, dass es den Feedback-Zyklus von der Idee bis zur Umsetzung drastisch verkürzt und so Akzeptanz- und Umsetzungsrisiken reduziert.
Die meisten Schnittmuster folgen dem Grundprinzip des Dimensional Planning: Sie stellen eine Progression vom Einfachen zum Ausgefeilten dar.
- Richard Lawrence (2009) Patterns for splitting user stories
Grafisch schön aufbereitet: http://www.richardlawrence.info/2012/01/27/new-story-splitting-resource/
Und auf Deutsch: http://www.richardlawrence.info/2012/08/24/splitting-stories-in-german-or-user-stories-aufteilen/ - Rachel C. Davies (2010) Slicing and dicing epic user stories
- William C. Wake (2009) 20 ways to split stories
Bei folgenden Mustern ist Vorsicht angebracht. Sie sind nicht falsch. Man sollte aber prüfen, ob man andere Muster anwenden kann.
- "Erst API, dann UI." [3]
Die Fachlichkeit wird erst später fertig. Der Product Owner weiß erst später, ob er auch das bekommt, was er intendiert hat. Die Gefahr, dass die Schnittstelle nicht zur Oberfläche passt, erhöht sich. Die Wahrscheinlichkeit von Nacharbeiten erhöht sich. - "Eine Story pro Maske." [2]
Eine Bildschirmmaske enthält oft mehr Funktionalität, als in einer Story umgesetzt werden kann. Dieses Schnittmuster verleitet dazu, UI-Elemente einzubauen, die noch nichts tun. - "Erst Proof of Concept, dann richtige Umsetzung." ("Spike" in [1])
Richard Lawrence warnt selbst vor diesem Muster: «The spike split is last because it should be your last resort. You probably know enough to build something. Do that, and you’ll know more. So, make every effort to use one of the previous eight patterns before resorting to the spike pattern.»
Um den vertikalen Schnitt von User Stories zu unterstützen, muss das Umsetzungsteam seine Arbeitsweise grundlegend ändern. Folgende Fertigkeiten sind entscheidend:
- gute Kommunikation innerhalb des Teams,
- iterativ-inkrementelle Arbeitsweise auch innerhalb von User Stories,
- simples Design (technisch), das die aktuelle Funktionalität gut unterstützt und keine umfassenden Annahmen über die zukünftige trifft,
- Bereitschaft, Code wiederholt zu überarbeiten (Refactoring),
- hoher Automatisierungsgrad, vor allem für Regressionstests.
- Version 1.2, 25. August 2015
- Anti-Patterns
- Konsequenzen fürs Umsetzungsteam
- Version 1.1, 30. April 2013