INVEST In Good User Stories

Wir verwenden User Stories tag-täglich und so ist es wichtig sich hin und wieder in Erinnerung zu rufen, was denn ein gute User Story ausmacht.

Ron Jeffries beschreibt folgende drei Bestandteile einer User Story:

  • written description or short title of the story used as a token for planning and as a reminder to have conversations (Cards)
  • Conversations about the story that serve to flesh out the details of the story (Conversations)
  • Acceptance tests that convey and document details and that can be used to determine when a story is complete (Confirmations)

Weiters beschreibt Cohn (2004) folgende Kriterien einer guten User Story:

  • Independent
  • Negotiable
  • Valueable to users / customers
  • Estimatable
  • Small
  • Testable

Independent:

Unabhängige User Stories sind technisch und funktional klar voneinander abgegrenzt und beeinflussen sich nicht. Eine Abhängigkeit würde zum Beispiel entstehen, wenn in Story A und Story B (teilweise) die selbe Funktionalität implementiert wird oder Story A auf Funktionalität von Story B angewiesen ist und/oder vice versa. Abhängigkeiten in User Stories erzeugen auch Abhängigkeiten zwischen den Entwicklern und Teams, die diese User Stories letztlich implementieren. Erhöhter Kommunikations- und Koordinationsaufwand ist die Folge. Ein weiteres Problem ergibt sich beim Schätzen: In welcher Story soll die überschneidende Funktionalität von A und B geschätzt werden? Die häufigste Antwort lautet: Jene Story die als erstes Implementiert wird (nehmen wir an das sei Story A), soll den gemeinsamen Anteil in der Schätzung beinhalten. Dann braucht die Schätzung von Story B diesen Anteil nicht zu beinhalten, da diese Funktionalität ja nur einmal implementiert werden muss (was bereits in Story A passiert). Jedoch bedeutet das, dass bereits zum Zeitpunkt des Schätzens die Reihenfolge der Abarbeitung von User Story A und B implizit festgelegt wird, was keinesfalls wünschenswert ist, da eine unbestimmte Zeit zwischen Schätzung und Umsetzung liegen kann! Was passiert wenn zwischen Schätzung und Umsetzung der Kunde entscheidet, dass Story A nicht mehr im Scope ist? – Story B ist dann zu gering geschätzt, da der gemeinsame Anteil von A und B, nur in Story A geschätzt wurde.

Negotiable:

User Stories sind niemals als starres Dokument zwischen Kunde, Product Owner, Team oder sonst jemandem zu sehen, sondern der Inhalt ist zu JEDER Zeit verhandelbar und veränderbar! Auch Artefakte wie eine Definition of Ready ändern daran nichts! User Stories sind keine Verträge über Requirements, die in einer Software umgesetzt werden müssen. User Stories entstehen beim/mit Kunden und werden gemeinsam mit dem Product Owner, dem Entwickler-Team und dem Kunden iterativ ausdefiniert. Kommunikation ist hier angesagt und keine peniblen Definitionen von Klauseln und Requirements! Das agile Manifest spricht dazu eine sehr deutliche Sprache:

Customer collaboration over contract negotiation

Valueable to users:

Die Formulierung einer User Story wird immer aus der Sicht des Users (einer User-Rolle) getroffen. Das ist deshalb so wichtig, da letztendlich der Benutzer derjenige ist, der einen Mehrwert durch die korrekte Implementierung der User Story erfahren soll. User Stories, die nur technische Details beschreiben, sind daher keine korrekten User Stories, da diese für den Benutzer keinen ersichtlichen Mehrwert liefern.

Estimatable:

Wie schon vorhin angesprochen müssen User Stories vom Entwickler-Team unabhängig voneinander schätzbar sein. Gründe warum eine User Story nicht schätzbar ist, können sein:

  • Entwickler haben zu geringes Domänenwissen
  • Entwickler haben zu geringes teschnischen Wissen
  • Die User Story ist zu groß

Punkt 1 und 2 lässt sich durch eine gute Teamzusammenstellung (Cross-Funktional und gute Balance aus Senior u. Junior Entwicklern) und durch gewissenhafte Vorbereitung der User Stories minimieren. Punkt 3 lässt sich durch Teilung der User Story in kleinere Sub-Stories lösen. 

Small:

Große User Stories sind schwer schätzbar, dadurch schlecht planbar und erhöhen das Risiko durch Verzögerungen enorm (vgl. Reinerstsen 2014). Daher gibt es eine wichtige Regel: Werden User Stories vom Team als zu groß angesehen müssen diese ausnahmslos geteilt werden und so in kleinere Sub-Stories zerlegt werden. Es gibt eine ganze Reihe an Hilfmitteln für das Story Slicing:

Testable:

Die Formulierungen der User Stories (genauer: der Akzeptanzkriterien) müssen so gewählt werden, dass diese möglichst automatisiert getestet werden können. Ist ein automatisiertes Testen nicht möglich ist dies manuell durchzuführen. Eine gute Praxis ist, sich für jedes Akzeptanzkriterium zu überlegen, ob und wie dieses getestet werden kann. Ist die Testbarkeit nicht gegeben muss das Kriterium abgeändert werden um Testbarkeit zu erzielen.

Quellen:

COHN, M.: 2004. User Stories Applied For Agile Software Development, Addison Wesley, S. 17-29

REINERSTEN, D.: 2014. The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing

Advertisements

Published by

Stefan Wunder

My name is Stefan Wunder and I am a passionate Lean & Agile Coach from Graz, Austria. I have been applying Lean & Agile methodologies in various industries and contexts since 2006. Since 2014 I am working as Agile Coach at AVL List GmbH, the world’s largest independent company for development, simulation and testing technology of powertrains (hybrid, combustion engines, transmission, electric drive, batteries and software) for passenger cars, trucks and large engines. I have a Master of Science in software development and business economics. I am Certified Systemic Coach, Certified Scrum Professional (CSP), Certified Scrum Master (CSM), Certified SAFe Program Consultant (SPC) and Certified LeSS Practitioner. I am speaker at conferences, and moderator of the Scrum User Group Graz.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s