Vom Geist zur Materie

Klare Aufgaben geben Selbstorganisationskräften eine Richtung – vom Umgang mit Anforderungen in agilen Projekten.

Zurück zu den Grundlagen. In agilen Projekten werden zu jedem Ende einer Iteration Produkterweiterungen geliefert. Eine Produkterweiterung stiftet den Anwendern des Produktes Nutzen. Sie kann potentiell an die Kunden ausgeliefert werden, wird möglicherweise aber auch mit anderen Produkterweiterungen gebündelt und den Kunden im Rahmen eines Release bereitgestellt.

Bevor die Produkterweiterung da ist, so dass wir sie tatsächlich sehen und nutzen können, muss die Aufgabe, die durch die Produkterweiterung erfüllt wird, klar sein, weil erst dieses Verständnis der Aufgabenstellung den Selbstorganisationskräften des ausliefernden Teams die benötigte Richtung gibt. Alle Interaktionen, die Kommunikationsnetzwerke, die benötigten Kenntnisse zur Auslieferung, die zu erstellenden Artefakte, folgen dieser Aufgabenstellung.

Das Hilfsmittel zur Beschreibung der gewünschten Produkterweiterung, und damit zur Definition einer Aufgabe, für die es sich lohnt, Zeit, Energie und Geld zu investieren, ist die Beantwortung der Fragen:

Wer will was warum?

Das Was wird durch die Frage nach dem Warum abgesichert. Warum wird eine bestimmte Produkterweiterung benötigt? Die Begründung des zu lösenden Problems oder die Beschreibung des erwünschten Nutzens, hilft zu überprüfen, ob an der richtigen Aufgabe gearbeitet wird und ob die Aufgabe richtig verstanden ist. Wer schlüssig beantworten kann, warum eine Produkterweiterung benötigt wird, kann leichter erläutern, was diese Produkterweiterung leisten soll. Der Weg zum Was führt also über das Warum.

Wer hat durch den Gebrauch der Produkterweiterung einen Nutzen? Diese Frage sichert die Aufgabenstellung ebenfalls ab. Kann ein Benutzertyp, der sich durch bestimmte Merkmale auszeichnet, identifiziert werden? Vielleicht gibt es verschiedene Benutzertypen mit unterschiedlichen Interessen, die zu berücksichtigen sind? Wann haben Sie zuletzt mit einem Produktnutzer gesprochen? Man kann dabei schöne Überraschungen erleben. Manches, das in der Theorie wie eine grandiose Idee aussieht, löst sich bei einem solchen Gespräch in Nichts auf. Kleine Veränderungen der Aufgabenstellung, zu der echte Benutzer wichtige Impulse liefern können, tragen manchmal deutlich zur Aufgabenangemessenheit und realen Anwendbarkeit bei.

Benutzergeschichten

Werden die Antworten auf die Fragestellung „Wer will was warum?“ auf einer Karteikarte notiert oder in einem Softwaresystem erfasst, erhält man eine User Story oder auch Benutzergeschichte. 

benutzergeschichte

Benutzergeschichten können von jedem Teammitglied geschrieben werden. Im Scrum Managementframework hat jedoch der Product Owner das letzte Wort in Bezug auf die Benutzergerschichten, da er entscheidet, ob und in welcher Reihenfolge sie umgesetzt werden.

Die Benutzergeschichte ist eine kurze Beschreibung der Aufgabenstellung. Wenn Fachbegriffe verwendet werden, dann die des Benutzers. Besonders für Benutzer, aber natürlich auch für alle anderen Akteure, muss die Benutzergeschichte verständlich sein. Die Benutzergeschichte ist keine Spezifikation, sondern ein Versprechen zur Diskussion. Sie sollte kurz formuliert und in der Zielsetzung genau sein. Im Umgang mit dieser Aufgabenstellung geht es für die Beteiligten immer um ein gemeinsames Verständnis, um fachliches und soziales Lernen, um die Rückkopplung und den optimalen Einsatz der erlangten Erkenntnisse. 

Erheben von Benutzergeschichten

Für die Erhebung von Benutzergeschichten ist ein zweistufiges Vorgehen hilfreich.

Im ersten Schritt klärt der Product Owner oder Produktmanager die strategische Zielsetzung seines Projektes und erstellt eine Produktvision, die mit allen Interessenvertretern abgestimmt ist. Die Produktvision ist ein kurzes Dokument – vielleicht nur eine einzige Folie oder Seite. Der Product Owner kann dazu jede Hilfe in Anspruch nehmen oder hinzuziehen, die er für notwendig hält. Diese Arbeit sollte der Product Owner sich nicht zu leicht machen. Alle Energie, die er hier investiert, zahlt sich unter Garantie im späteren Projektverlauf aus. Die Produktvision ist nicht nur ein Instrument zur Kommunikation der Projektziele, die den Projektbeteiligten eine Richtung und damit Orientierung gibt. Zusätzlich ist sie auch ein wichtiges Werkzeug zum Risikomanagement. Die Erstellung der Produktvision deckt möglicherweise Zielkonflikte auf, die dann zu einem frühen Zeitpunkt konstruktiv behandelt werden können. Ist nämlich schon zu Beginn des Projektes diese Vision nur mit großen Schwierigkeiten zu erstellen, gibt es vielleicht kein gemeinsam getragenes Verständnis darüber, warum das Projekt überhaupt durchgeführt werden muss. Sowie das Projekt dann im späteren Verlauf unter Druck gerät und Ressourcen knapp werden, wird es schwierig sein, die Akteure zu einem geschlossenen Vorgehen zu einen. Ein geeintes Vorgehen, der Blick in dieselbe Richtung, ist aber eine notwendige Voraussetzung für den Erfolg des Projektes. Das oder die Projektteams folgen dieser Aufgabenstellung. Je klarer sie ist, umso mehr Gewicht kann ihr gegeben werden. Die Selbstorganisationskräfte innerhalb des Projektes, die immer vorhanden sind, können mit einer aussagekräftigen Produktvision kanalisiert und verstärkt werden. In agilen Projekten, die auf Selbstorganisation setzen, ist das ein Muss!

Story Mapping

Ausgehend von der Produktvision werden nun in einem zweiten Schritt die Benutzergeschichten erhoben, die für ein erfolgreiches Produkt umzusetzen sind. Das Story Mapping hat sich dafür als sinnvolle Praktik erwiesen. Die Durchführung eines Story Mapping Workshops, an dem der Product Owner und das ausliefernden Team teilnehmen, bietet viele Vorteile:

  • Gemeinsames Verständnis: Ausgehend von der Produktvision wird für die Beteiligten eine gemeinsames Verständnis der strategischen Projektziele hergestellt.
  • Verschiedene Sichten nutzbar machen: Es werden Benutzergeschichten unterschiedlicher Granularität erarbeitet. Die verschiedenen Perspektiven der Teammitglieder können an Ort und Stelle berücksichtigt werden und führen immer zu einem besseren Verständnis und höherer Qualität. Sachverhalte werden sichtbar, die bis dahin unsichtbar waren.
  • Zusammenhänge erkennen: In der Diskussion werden Zusammenhänge erkannt. Abhängigkeiten jeder Art – technisch, organisatorisch oder zeitlich – tauchen auf, und können behandelt werden.
  • Projektumfang strukturieren: Eine Story Map ist eine zweidimensionale Darstellung der zu lösenden Aufgaben. Diese Darstellung hilft dabei, die Auslieferung des Produktes in verschiedene Releases zu gliedern.
  • Iteratives Vorgehen: Ähnlich wie die Unterteilung der Auslieferung in Releases, hilft die Story Map auch bei der Zuordnung von Benutzergeschichten zu Iterationsumfängen.

Story Mapping Workshop

Ganz konkret kann ein Story Mapping Workshop folgendermaßen durchgeführt werden:

Neben dem Product Owner nimmt das ausliefernde Team – oder einzelne Mitglieder des Teams – teil. Fünf Personen sind eine gute Teilnehmerzahl, die weder zu hoch noch zu niedrig ist. Zu gering sollte die Teilnehmerzahl nicht sein, weil unterschiedliche Sichten auf die zu erhebenden Benutzergeschichten benötigt werden. Die Teilnehmerzahl darf nicht zu hoch sein, weil die Kommunikationsprozesse sonst ineffizient werden. Acht oder neun Personen können noch vernünftig zusammenarbeiten, bei größeren Zahlen wird es schwierig. Wenn Sie können, wählen Sie für den Workshop einen Ort abseits der normalen Arbeitsumgebung, weil das hilft, sich von den Alltagsproblemen zu trennen, sich auf den Workshop zu konzentrieren und kreative Ideen zu produzieren.

  1. Der Product Owner stellt die Produktvision vor und erläutert sie bei Bedarf.
  2. Ausgehend von der Produktvision notieren die Teilnehmer zunächst die verschiedenen Benutzertypen, die mit dem Produkt oder System arbeiten werden. Jeder Benutzertyp auf einem eigenen Post-It. Nun notieren werden die wesentlichen Dinge notiert, die diese Benutzer mit dem Produkt bewerkstellen. Verwenden Sie dazu zum Beispiel Post-It’s derselben Farbe und schreiben Sie immer eine Tätigkeit pro Post-It auf.  Dies führt zu den wesentlichen, grob-granularen Aufgaben, die das Produkt erfüllen muss.
    benutzeraufgaben
  3. Im nächsten Schritt gruppieren die Teilnehmer die Aufgabenzettel. Die Post-It’s werden an einer Wand oder auf einem Tisch so geordnet, dass ähnliche Dinge nah beeinander liegen. Duplikate werden entfernt.
  4. Darauf folgt die Benennung der gebildeten Gruppen. Jetzt werden Post-It’s mit einer anderen Farbe verwendet und über den zuvor gebildeten Gruppen angebracht.
  5. Die benannten Gruppen, auch bezeichnet als Benutzeraktivitäten, werden nun in eine Reihenfolge gebracht, die der Reihenfolge entspricht, in der ein Benutzer die Aktivitäten durchführen würde. Wenn sich das Team nicht auf eine Reihenfolge einigen kann, ist die Reihenfolge vielleicht nicht wichtig.
    benutzeraktivitaeten
  6. Das nun vorliegende Produktskelett kann zur Prüfung den zukünftigen Benutzern vorgestellt werden. Alternativ ist auch die Arbeit mit Benutzerszenarios möglich.
  7. Erst jetzt werden Benutzergeschichten erzeugt, die unterhalb der Benutzeraufgaben angeordnet werden. Das Vorgehen entspricht wieder dem sogenannten Silent Brainstorming, das bereits im Schritt zwei zur Erfassung der Benutzeraufgaben zum Einsatz kam. Die Post-It’s sollten erneut eine andere Farbe haben, so dass in der Story Map farblich zwischen Aktivitäten, Aufgaben und Benutzergeschichten unterschieden werden kann. Zu diesem Zeitpunkt ist es ausreichend, nur die Titel – das Was – der Benutzergeschichten zu notieren. Wer und Warum muss zunächst nicht auf dem Post-It stehen. Die Benutzergeschichten werden den Benutzeraufgaben zugeordnet und etwaige Duplikate werden erneut entfernt.
    benutzergeschichten

 

Nach dem Durchlaufen dieser Arbeitsschritte hat man eine Story Map, die mit der Produktvision in Einklang steht und an der man die wesentlichen Benutzeraktivitäten, -aufgaben und -geschichten ablesen kann. Jetzt geht es darum, zu strukturieren welche Funktionalität in welchem Release ausgeliefert wird. Da jedes ausgelieferte Release für sich funktionieren muss, wird oftmals ein Releasezuschnitt gewählt, der die Story Map horizontal unterteilt. Zu diesem Zeitpunkt ist der Funktionsumfang – die Größenordnung – der Benutzergeschichten noch nicht abgeschätzt. Daher sollten Sie sich bei der Suche nach dem ersten Release davon leiten lassen, was das kleinstmögliche, sinnvolle Produkt ist, das Sie ausliefern können. Für den Teamprozess ist ein kleineres Produkt besser als ein größeres, weil das Team so schneller konkrete Hinweise erhält, was es in welcher Zeit leisten kann. Auch für die Gestaltung des Produktes kann ein kleines, im ersten Release geliefertes Produkt hilfreich sein, weil dann zu einem frühen Zeitpunkt Erfahrungen der Benutzer aus dem wirklichen Arbeitsalltag berücksichtigt werden können.

releases

Die Orientierung der Story Map kann horizontal (wie im Beispiel) oder vertikal sein, je nach dem, wie der Platz im Besprechungsraum am besten genutzt werden kann.

Einsicht gewinnen

Nach der ersten Aufteilung des Produktes auf verschiedene Releases, ist ein genaueres Verständnis für die Benutzergeschichten des nächstliegenden Releases herzustellen. Dazu ist die tiefere Behandlung der eingangs erläuterten Fragestellung „Wer will was warum?“ erforderlich.

Idealerweise kann diese Vertiefung mit den Teilnehmern des Story Mapping Workshops erfolgen. Gemeinsam oder in Teilgruppen versucht man, kurze und klare Antworten auf diese Fragen zu finden und zu notieren. Die Verschriftlichung kann auf Karteikarten oder in einem Softwaresystem erfolgen. Der Platz auf den Post-It’s wird vermutlich nicht ausreichend sein. Achten Sie durch die Vergabe von Identifikationsnummern auf eine Beziehung zwischen den Post-It’s und den Karteikarten bzw. Datensätzen, so dass sie jederzeit die Verbindung zwischen den Artefakten herstellen können.

Die Konkretisierung von Benutzergeschichten bietet immer auch die Chance, Benutzergeschichten zu verwerfen. Jede verworfene Benutzergeschichte hat einen riesigen Einfluss auf die reale Produktivität des ausliefernden Teams, weil die Umsetzung von Produkterweiterungen, die keinen Nutzen stiften, vermieden wird. Ich schätze den Produktivitätsvorteil, den man durch Verwerfen unbenötigter Stories gewinnt, viel höher ein als zum Beispiel die Erhöhung der Umsetzungsgeschwindigkeit durch „schnelleres Programmieren“.

Jede Benutzergeschichte ist eine Aufgabenstellung an das ausliefernde Team. Das Erreichen der gesetzten Aufgabenstellung spielt  eine wichtige Rolle, denn wie Ken Schwaber und Mike Beedle schreiben: „completed work has a momentum“ [Schwaber 2004:46]. Man sucht nicht nach dem theoretischen Optimum, sondern nach dem Möglichen [ebd. S. 27]. Das Tun, im Gegensatz zum Theoretisieren, ist Bestandteil des Lernkonzeptes von agilen Vorgehensweisen.

Ob die Aufgabenstellung einmal erfüllt sein wird oder nicht, wird anhand der Akzeptanzkriterien für jede Benutzergeschichte überprüft. Diese Kriterien konkretisieren die Aufgabenstellung, so dass sich daraus Testfälle ableiten lassen. An dieser Stelle können Testexperten sehr gewinnbringend mitarbeiten. Nicht-funktionale Anforderungen, z.B. „die Antwortzeit dieses Dialoges darf 1,5 Sekunden nicht überschreiten“ können ebenfalls Teil der Akzeptanzkriterien sein. Vielfach wird ein Architekt versuchen, diese Kriterien übergreifend für das Produkt zu ermitteln, da die Kriterien sich zwar an einzelnen Benutzergeschichten überprüfen lassen, die Einhaltung aber häufig übergreifende Arbeiten erfordern, die sich nicht nur an einer einzelnen Benutzergeschichte festmachen lassen.

Die Akzeptanzkriterien müssen vor dem Auslieferungsbeginn der Benutzergeschichte feststehen, also bevor das Team mit der Auslieferung innerhalb einer Iteration beginnt. Üblicherweise kommen während der Auslieferung weitere Kriterien hinzu, die dann für die Benutzergeschichte fortgeschrieben werden. Die Erweiterung der Akzeptanzkriterien während der Iteration darf nicht ohne Rücksprache im Umsetzungsteam vorgenommen werden. Wenn zusätzliche Akzeptanzkriterien die Benutzergeschichte deutlich erweitern, können diese Kriterien möglicherweise zu einer weiteren Benutzergeschichte führen, die in einer späteren Iteration ausgeliefert wird. Nur wenn die Akzeptanzkriterien zum Ende der Iteration anhand von Tests objektiv überprüft und erfüllt werden, ist die Benutzergeschichte fertiggestellt.

Hin und wieder wird zur Charakterisierung einer Benutzergeschichte das Akronym CCC verwendet, das für Card, Conversation, Confirmation steht und das 2001 von Ron Jeffries beschrieben wurde. CCC steht als Kurzform für die gerade erläuterten Konzepte der kurzen Darstellung der Anforderung auf einer Karteikarte (Card), die nicht eine Spezifikation, sondern das Versprechen zur Diskussion (Conversation) ist und deren erfolgreiche Umsetzung durch Akzeptanzkriterien (Confirmation) überprüfbar ist. [Cunningham 2001]

Arbeitsliste

Die Story Map ist eine zweidimensionale Darstellung der Anforderungen an das Produkt. In kleineren Projekten kann diese Darstellung als Medium zur Anforderungsverwaltung bereits genügen. Man klebt einfach farbige Punkte auf die Zettel, die gerade in Arbeit sind und andersfarbige Punkte auf die Zettel, die erledigt sind.

In umfangreicheren Projekten wird diese Darstellung alleine nicht ausreichend sein – weil der Platz zur Darstellung nicht ausreicht, oder weil es mehrere Teams gibt, die vielleicht sogar geographisch verteilt arbeiten. Dann wird eine Arbeitsliste benötigt, deren Ausgangspunkt der Story Mapping Workshop ist. Die Liste aller Benutzergeschichten, die zu einem Produkt führen oder ein bestehendes Produkt erweitern, ist in Scrum der Product Backlog. Wenn eine solche Liste gepflegt wird (normalerweise in einem Softwaresystem), ist sie das wesentliche Artefakt zur Verwaltung der Anforderungen. Hier findet sich, für alle Teammitglieder zugänglich, die geordnete Aneinanderreihung von gewünschten Produkterweiterungen, also die fachliche Beschreibung des zukünftigen Produktes. Es gibt keinen anderen – weiteren – Ort, an dem Anforderungen verwaltet werden. Der Product Owner oder ein Produktmanager hat das letzte Wort in Bezug auf die Organisation der Arbeitsliste. Um mit einer umfangreichen Arbeitsliste sinnvoll umgehen zu können, wird jede Benutzergeschichte um drei Daten erweitert:

  • ein Kürzel zur eindeutigen Identifikation,
  • die Priorität und den
  • Funktionsumfang.

Identifikation

Die Identifikation kann z.B. mit einer fortlaufenden Nummer für jede neue Benutzergeschichte erfolgen.

Priorität

Mit der Priorität ist die Reihenfolge der Auslieferung verknüpft. Hoch priorisierte Stories werden vor niedrig priorisierten Stories ausgeliefert. Drei oder vier verschiedene Prioritäten reichen, darunter eine Überholspurpriorität, die Vorrang vor allem hat, an dem gerade gearbeitet wird. Die Prioritäten könnten z.B. sein: Überholspur, hoch, mittel, niedrig. Gibt es mehrere Benutzergeschichten gleicher Priorität, entscheidet das Team gemeinsam mit dem Product Owner, welche dieser Stories als nächste ausgeliefert wird. Manchmal wird zusätzlich zur Priorität noch eine Auslieferungsreihenfolge festgelegt.

Funktionsumfang

Mit dem Funktionsumfang einer Benutzergeschichte ist die strategische Größenordnung gemeint. Das können Story Points oder T-Shirt-Größen sein.

Der Funktionsumfang ist kein absolutes, sondern ein relatives Maß. Wenn zum Beispiel eine Benutzergeschichte mit fünf Punkten bewertet ist, können alle anderen Benutzergeschichten im Vergleich dazu bewertet werden. Ein Story mit 10 Punkten wäre also doppelt so komplex. Generell orientiert man sich bei der Festlegung des Funktionsumfangs einer Benutzergeschichte immer an anderen Stories, die bereits bewertet worden sind. Das geht deutlich schneller, als zu versuchen, den absoluten Aufwand zur Umsetzung jeder einzelnen Benutzergeschichte festzulegen.

Zum Beispiel: eine Benutzergeschichte der Größe M kann vom Team innerhalb einer idealen Woche ausgeliefert werden, oder: eine Benutzergeschichte, die mit 5 Punkten bewertet ist, kann in einer idealen Woche vom Team ausgeliefert werden.

Implizit ist mit dem Funktionsumfang zwar ein bestimmter Aufwand verknüpft, vorrangig ist aber die Frage, ob die Benutzergeschichte in einem gegebenem Zeitraum fertiggestellt werden kann. Die möglichst präzise Aufwandsschätzung bis auf Stundenebene bringt das Team nicht weiter, damit sollte keine Zeit vergeudet werden. Eine detaillierte Aufwandsschätzung stimmt am Ende ohnehin nicht und sie verleitet all zu sehr dazu, genau diesen Aufwand einhalten zu wollen. Aufwandsverbrauch ist als Fortschrittsmaß zweitrangig. Fertiggestellte Produkterweiterungen sind vielmehr ein geeignetes Maß, um Fortschritt zu messen.

Nach einigen Auslieferungsiterationen ist für das Team bekannt, welcher Funktionsumfang in einer Iteration lieferbar ist. Das ist die Geschwindigkeit (Velocity) des Teams. Auf Grundlage dieser empirischen Erkenntnis läßt sich herleiten, wann die Arbeitsliste abgearbeitet ist, oder, bei gegebenem Releasetermin, wieviele Benutzergeschichten aus der Arbeitsliste fertiggestellt werden können. Diese Information ist sehr viel belastbarer als die meisten Aufwandsschätzungen, mit denen Sie es in Ihrem Arbeitsleben bisher zu tun hatten.

Schätzverfahren

Die Schätzung des Funktionsumfangs und die Geschwindigkeit des Teams sind die wesentlichen Größen für eine sinnvolle, empirisch herleitbare Releaseplanung. Der Schätzvorgang selbst bietet zusätzlich die Chance zur Kommunikation innerhalb des Teams und zum besseren Verständnis der zu bewältigenden Aufgaben. Abhängig von der verfügbaren Zeit, der Anzahl der Benutzergeschichten und vom benötigten Detailverständnis können verschiedene Verfahren zur Schätzung eingesetzt werden. Einige wesentliche Verfahren, die einander ergänzen, sind die

  • Magic Estimation, das
  • Estimation Game und das
  • Planning Poker.

Generell gewinnen die hier vorgestellten Schätzverfahren an Aussagekraft, je differenzierter der Blick auf die abzuschätzenden Benutzergeschichten ist. Weiterhin ist es der Schätzqualität zuträglich, wenn die Personen schätzen, die auch für die Umsetzung verantwortlich sind.

Magic Estimation

Mit der Magic Estimation lassen sich umfangreiche Arbeitslisten in kurzer Zeit abschätzen, Diskussionen und tiefe Analysen werden bewusst vermieden. Mit diesem Verfahren ist es durchaus möglich, eine Arbeitsliste mit 100 Einträgen in einem halben Tag abzuschätzen.

Die Magic Estimation kann im Rahmen eines Story Mapping Workshop durchgeführt werden. Die Teilnehmer sind dann bereits auf die Arbeit mit den Benutzergeschichten eingestimmt, die Zielsetzung des Projektes ist kommuniziert und man kann einfach im Arbeitsrhythmus fortfahren. Es gibt Story Mapping Workshops, deren Teilnehmer ihren Schwerpunkt eher im Fachbereich und nicht so sehr in der Domäne der technischen Umsetzung haben. Das ist zunächst kein Problem, hilft vielleicht sogar bei der Beschreibung der gewünschten Funktion, dem Was, wenn umfangreiche Vorhaben umgesetzt werden sollen. Die Schätzung ist dann auch als solche zu begreifen – als Größenordnung des Funktionsumfanges aus fachlicher Sicht.

Die Magic Estimation funktioniert folgendermaßen:

  1. Product Owner und Team sind anwesend.
  2. Für jede Benutzergeschichte ist ein Post-It mit dem Titel und wenn möglich mit der Id vorbereitet. Verwenden Sie dazu nicht die Post-It’s aus ihrer Story Map! Duplizieren sie diese Post-It’s stattdessen.
  3. Kleben Sie nun an eine Wand Zettel mit unterschiedlichen Größenordnungen die in ihrem Projekt verwendet werden sollen, also z.B. T-Shirt-Größen S, M, L, XL, XXL und das ? für nicht einschätzbaren Funktionsumfang.  Lassen Sie Platz, so dass Sie die Benutzergeschichten den Größenordnungen zuordnen können.
  4. Wenn das Team mit relativen Schätzverfahren nicht vertraut ist, muss eine kurze Einführung stattfinden. Ich verweise dazu auf den vorhergehenden Abschnitt zum Funktionsumfang. Der Wesentliche Punkt ist: wir wollen wissen, wie der Funktionsumfang der Benutzergeschichten im Vergleich zueinander ist, also ob eine Story größer oder kleiner als eine andere ist. Absolute Zahlen spielen keine Rolle! Daher ist es auch besser, T-Shirt-Größen und keine Zahlen für die Größenordnung zu verwenden.
  5. Die Teilnehmer ordnen nun, alle gleichzeitig arbeitend, die Zettel mit den Benutzergeschichten den Größenordnungen zu. Sprechen ist nicht erlaubt. Benutzergeschichten, die ein anderer Teilnehmer zugeordnet hat, dürfen nicht umgeordnet werden.
  6. Nachdem alle Benutzergeschichten einer Größenordnung zugewiesen sind, betrachten und vergleichen die Teilnehmer die Schätzungen. Wenn ein Teilnehmer eine Benutzergeschichte anders schätzen möchte, kann er das nun tun, muss dem Team aber den Grund für die Neuzuordnung der Benutzergeschichte nennen. Keine Diskussion. Der Product Owner notiert sich die Benutzergeschichten, für die es keine Einigung gibt.
  7. Die nicht festgelegten Benutzergeschichten werden im Rahmen einer Diskussion im Anschluss abgeschätzt.

magic_estimation

Abschließend werden die Schätzwerte in die Arbeitsliste aufgenommen, wo sie an jeder Benutzergeschichte vermerkt werden. Hier kann es sinnvoll sein, den Größenordnungen Story Points zuzuweisen (z.B. 1, 2, 3, 5, 8, 13, 20, 40, 100), so dass mit den Punktzahlen im Projektverlauf gerechnet werden kann.

Estimation Game

Das Estimation Game greift ebenso wie die Magic Estimation den Gedanken der relativen Größenordnung von Benutzergeschichten auf. Die Regeln sind:

  1. Wie immer: Product Owner und Team nehmen teil.
  2. Für jede abzuschätzende Benutzergeschichte gibt es ein Post-It mit dem Titel der Benutzergeschichte.
  3. Jemand aus dem Team nimmt die erste Benutzergeschichte, liest sie vor und hängt das Post-It an die Wand.
  4. Der nächste Teilnehmer nimmt die nächste Benutzergeschichte, liest sie vor und ordnet das Post-It an der Wand wie folgt:
    • Neben die bereits vorhandene Benutzergeschichte, wenn der Funktionsumfang ähnlich groß ist.
    • Über die bereits vorhandene Benutzergeschichte, wenn der Funktionsumfang geringer ist.
    • Unter die bereits vorhandene Benutzergeschichte, wenn der Funkionsumfang größer ist.
  5. Die Teilnehmer setzen die Schätzung der Reihe nach fort. Jeder Teilnehmer hat jetzt folgende Möglichkeiten, wenn er an die Reihe kommt:
    • Er nimmt die nächste Benutzergeschichte und ordnet sie, so wie oben beschrieben in die bereits abgeschätzten Benutzergeschichten ein.
    • Wenn er glaubt, eine bereits abgeschätzte Geschichte ist nicht richtig eingeordnet, ordnet er sie neu. Kurze Begründung. Keine Diskussion.
    • Aussetzen.
  6. Das Spiel ist beendet, wenn alle Benutzergeschichten zugeordnet sind oder alle Teilnehmer aussetzen.

estimation_game

Wie bei der Magic Estimation können den an der Wand hängenden Komplexitätsgruppen (die Zeilen) nun Story Points zugewiesen werden (z.B. 1, 2, 3, 5, 8, 13, 20, 40, 100).

Planning Poker

Planning Poker wurde bereits 2002 von James Grenning vorgestellt. Planning Poker ist aufwendiger als die beiden zuvor behandelten Verfahren. Man kann es z.B. im laufenden Projekt für neu hinzukommende Benutzergeschichten verwenden. Bei allen Stärken, die das Planning Poker in Bezug auf die Analyse der betrachteten Benutzergeschichten bietet, sehe ich inzwischen auch einige Probleme:

  • Man benötigt Planning Poker Karten. Sicher keine große Sache, aber die Karten müssen in ausreichender Zahl zur Hand sein, wenn man sie benötigt.
  • Man arbeitet von Anfang an mit Zahlen und gerät leicht in die Diskussion, wieviele Stunden Aufwand einem Story Point entsprechen. Der Aspekt der relativen Größenordnung von Benutzergeschichten wird nicht so stark unterstützt wie bei der Magic Estimation und dem Estimation Game.
  • Planning Poker benötigt mehr Zeit.

Die Kehrseite des größeren Zeitbedarfs ist eine bessere Analyse der Benutzergeschichten, die der späteren Sprintplanung zugute kommen kann. Planning Poker funktioniert so:

  1. Product Owner und Team nehmen teil.
  2. Jeder Teilnehmer hat Planning Poker Karten, die auf einer Seite mit Story Points beschriftet sind (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?)
  3. Der Product Owner stellt die abzuschätzende Benutzergeschichte vor.
  4. Jeder Teilnehmer legt die Karte mit seiner Punktschätzung für die Geschichte verdeckt auf den Tisch. Verdeckt, um das sogenannte Anchoring, das Orientieren an Meinungsführern, zu vermeiden.
  5. Alle gemeinsam decken ihre Karten auf.
  6. Die beiden Teilnehmer mit der geringsten und höchsten Schätzung erklären kurz, wie sie zu der Schätzung gelangt sind.
  7. Die Schätzung wird wiederholt, bis ein Konsent (mit t am Ende) erreicht ist. Die geschätzte Punktzahl wird an der Benutzergeschichte in der Arbeitsliste vermerkt.
  8. Der Vorgang wird für alle abzuschätzenden Benutzergeschichten wiederholt.

Schätzen mit mehreren Teams

Arbeiten mehrere Teams an einem umfangreichen Produkt, helfen die folgenden Maßnahmen bei der Organisation der Arbeit:

  • Ähnliches Maß für Funktionsumfang: Die Teams sollten sich auf ein ähnliches Maß für den Funktionsumfang einigen. Nehmen Sie an, Sie haben drei Teams. In einem Team 8 Personen, im anderen 5 und im dritten Team 4 Personen. Diese Teams existieren, weil sie ein bestimmten Know-how haben und spezifische Aufgaben bewältigen. Wenn jedes Team sich derart einigt, dass eine Benutzergeschichte der Größe M durch das Team in einer idealen Woche geliefert werden kann, so sind die Stories aufwandsmäßig zwar nicht vergleichbar, der Fortschritt über die Zeit kann teamübergreifend aber durchaus verglichen werden, da für jedes Team gilt: eine M-Story ist in einer idealen Woche fertig. Es geht dabei um Fortschritt und Fertigstellung innerhalb einer Zeiteinheit, nicht um Aufwand.
  • Teams folgen der Aufgabenstellung: Die Teamzusammensetzung folgt der Aufgabenstellung. Machen Sie sich klar, warum es die drei Teams gibt und welche Aufgaben jedes Team erfüllen soll und erfüllen kann. Wenn jedes Team seine Aufgabe und die Abhängigkeiten zu den anderen Teams kennt, wirkt das für die Zusammenarbeit normierend und unterstützt die Integration der von den Einzelteams gelieferten Produkterweiterungen.
  • Feature-Teams sind besser als Komponenten-Teams: Wenn möglich, sollten die Teams nicht nach Komponenten gebildet werden (also nicht ein Team für Frontend, ein Team für Backend usw.), sondern nach Produkterweiterungskategorien (z.B. Auskünfte, Änderungen, Neuanlage), innerhalb derer ganzheitliche Anforderungen umgesetzt werden können. Das minimiert Abhängigkeiten der Teams untereinander, unterstützt eine ganzheitliche Sicht für jedes Team und erleichtert für jedes Team die Bereitstellung von nützlichen Ergebnissen.

Benutzergeschichten zergliedern

Infolge der Schätzung stellt sich wahrscheinlich heraus, dass einige der Benutzergeschichten einen sehr hohen Funktionsumfang haben, vielleicht 40 oder auch 100 Story Points. Andere wiederum sind sehr gut abzugrenzen und sind mit einem Funktionsumfang zwischen 1 und 10 bewertet. Die kleineren Benutzergeschichten sind vermutlich innerhalb einer Iteration auszuliefern – das wird die Praxis zeigen. Die größeren sind sicher nicht innerhalb einer Iteration fertigzustellen. Jetzt geht es darum, diese umfangreichen Benutzergeschichten besser zu begreifen und so zu zerlegen, dass mehrere überschaubare Stories daraus werden, von denen jede end-to-end funktioniert und einzeln ausgeliefert werden kann. Es ist völlig ausreichend, diese Zerlegung nur für die Benutzergeschichten der nächsten zwei oder drei Iterationen vorzunehmen, weil die Zerlegung Zeit und Energie kostet und am besten funktioniert, wenn die Umsetzung der Benutzergeschichte kurz bevorsteht. Ausserdem kann es sein, dass mit dem Fortschreiten des Projektes bestimmte Benutzergeschichten anders bewertet werden, oder dass erst im weiteren Verlauf Erkenntnisse gewonnen werden, die für eine sinnvolle Zerlegung wichtig sind. Hat man in diesen Fällen im Vorfeld bereits eine Zerlegung vorgenommen, ist unnötiger Arbeitsaufwand entstanden, der wiederholt werden muss.

In einer idealen Welt erfüllt jede Benutzergeschichte die INVEST-Kriterien, die bedeuten:

  • Independent: Jede Benutzergeschichte sollte von allen anderen unabhängig umsetzbar sein. Das erleichtert die Bestimmung der Auslieferungsreihenfolge.
  • Negotiable: Die Benutzergeschichte ist in der Formulierung des verfolgten Ziels klar, legt die Art der Umsetzung aber nicht fest (das Versprechen zur Diskussion – hatten wir oben schon).
  • Valuable: Die Benutzergeschichte schafft Wert oder Nutzen, die Frage nach dem Warum kann also positiv beantwortet werden.
  • Estimable: Sie kann durch das Team abgeschätzt werden.
  • Small: Die Benutzergeschichte ist klein. So klein, dass die Auslieferung innerhalb einer Iteration gelingt.
  • Testable: Die Benutzergeschichte kann getestet werden. Diese Testbarkeit leitet sich aus den Akzeptanzkriterien ab, über die weiter oben bereits die Rede war.

Um die Benutzergeschichten mit großem Funktionsumfang so zu zerlegen, dass die INVEST-Kriterien erfüllt sind, können verschiedene Techniken herangezogen werden. Zum Beispiel:

  • Aufteilung nach Granularität: Einige Funktionen können in einem ersten Schritt in einer einfachen Variante umgesetzt und im nächsten Schritt verfeinert werden. Zum Beispiel kann der erste Schritt zur Implementierung einer Suche die Eingabe eines einfachen Suchwortes zulassen. Im nächsten Schritt werden vielleicht logische Verknüpfungen und Filter unterstützt.
  • Aufteilung nach Benutzertyp: Einem Sachbearbeiter stellt sich die neue Funktion vielleicht anders dar, als einem Kunden. Unterschiedliche Benutzer können zu unterschiedlichen Benutzergeschichten führen.
  • Aufteilung nach Geschäftsvorfall: Möglicherweise muss die neue Eingabemaske nicht sofort für alle Geschäftsvorfälle funktionieren, sondern es reicht auch, einzelne Geschäftsvorfälle Schritt für Schritt zu unterstützen.
  • Aufteilung nach Arbeitsfolge: Lange Bearbeitungsketten, die aus unterschiedlichen Masken bestehen, lassen sich auf einzelne Masken herunterbrechen.
  • Aufteilung nach Operation: Benutzergeschichten können aufgeteilt werden nach Eingabe-, Lese-, Änderungs- und Löschoperation.

Natürlich müssen die zerlegten Benutzergeschichten geschätzt und in eine Auslieferungsreihenfolge gebracht werden, siehe oben.

Manchmal gibt es auch sogenannte Technikstories. Zum Beispiel die Reorganisation der Datenbankstruktur. Genaugenommen sind das keine Benutzergeschichten, weil ein Benutzer darin nicht involviert ist. Ich finde es hilfreich, diesen Stories Raum für eine qualitativ hochwertige Umsetzung zu geben und sie zu schätzen. Nicht immer lassen sich Aufräumarbeiten und Refaktorisierungen mit einer Benutzergeschichte in Verbindung bringen. Für diese Fälle gibt es die Technikstories.

Ebenso finde ich es sinnvoll, Fehler bewusst zu verwalten und ihnen sogar Fehlerpunkte zuzuweisen. Es gibt Gründe für und gegen die Zuweisung von Punkten:

Pro

  • Auch Fehler haben eine unterschiedliche relative Größe zueinander und zu den Benutzergeschichten. Für die Planung, wieviel Arbeit in einer Iteration erledigt wird, ist diese Kenntnis hilfreich.
  • Die Kapazität des Teams wird realistisch(er) dargestellt, da die Fehlerpunkte und die Story Points der Benutzergeschichten addiert werden können.

Contra

  • Die Behebung von Fehlern ist keine Vorwärtsbewegung, weil nichts Neues geschaffen wird. Aus dieser Perspektive erhöhen die Fehler nicht die Geschwindigkeit des Teams, sondern verringern sie. Wenn Fehlern keine Story Points zugewiesen werden, verringert das automatisch die darstellbare Geschwindigkeit des Teams. Es wird klar, in welchem Funktionsumfang Neues geschaffen wird.

Ich plädiere dennoch für die Verwendung von Punkten in Zusammenhang mit Fehlern. Beim Reporting sollten Fehlerpunkte und Punkte von Benutzergeschichte separat dargestellt werden. So hat man sogar eine zusätzliche Information, nämlich wie hoch der Anteil der Fehlerbehandlung am gesamten Tun des Teams ist.

Was und Wie

Die gedankliche Trennung von Aufgabenstellung und Lösungsweg ist ein wichtiges Konzept bei der Auslieferung von Benutzergeschichten. Das agile Team beginnt jede Iteration mit der Haltung „start to end – beginne um fertig zu werden“. Ausgehend vom erwünschten Ende sucht das Team den Weg zu einer guten Lösung. Das Wie, der Lösungsweg, ist in der Aufgabenstellung bewusst offen gehalten, denn es ist die Pflicht und das Recht des Teams, diesen Weg selbst zu finden. Ausserdem erlaubt die Trennung von Aufgabenstellung und Lösungsweg eine organisatorische Umsetzung mit klaren Verantwortlichkeiten. In Scrum ist beispielsweise der Product Owner für die Definition der Aufgabe verantwortlich, während das Team für den Lösungsweg und die Qualität der Lösung verantwortlich ist. Verantwortlich bedeutet in diesem Zusammenhang: Wer hat das letzte Wort für Entscheidungen in seinem Verantwortungsbereich. Der Weg bis zur Entscheidung wird in einem Dialog von allen Beteiligten beschritten. Teamentscheidungen müssen dabei nicht unbedingt im Konsenz getroffen werden, sondern ein Konsent, also eine Lösung, zu der alle Beteiligten Ja sagen können, selbst dann, wenn nicht alle die Lösung für optimal halten, ist oftmals ausreichend um weiterzukommen. Ja sagen bedeutet dann auch: Ja tun.

Beispiel: Ein Product Owner oder Produktmanager schreibt die Benutzergeschichte zunächst auf und stellt sie dem Team vor. Das Team fragt nach, lässt sich die Story vom Product Owner erklären, hinterfragt die Begründung, verlangt nach genaueren Erläuterungen, weist auf technische Zusammenhänge hin, schlägt Alternativen vor. Der Product Owner hat in diesen Diskussionen das letzte Wort in Bezug auf die Formulierung der Benutzergeschichte und in Bezug auf das mit der Geschichte verfolgte Ziel. Wenn das Team die Benutzergeschichte verstanden und abgeschätzt hat, und sofern die Geschichte innerhalb einer Iteration lieferbar ist, wird das Team die Benutzergeschichte umsetzen. Während dieser Umsetzung können dem Product Owner oder auch den möglichen Anwendern Zwischenstände präsentiert werden, um Feedback einzuholen und die konkrete Ausgestaltung zu präzisieren. Neue Erkenntnisse, die in dieser Phase gewonnen werden, werden ebenfalls diskutiert und berücksichtigt, so dass diese Erkenntnisse zur Verbesserung der Lösung beitragen. Man sollte allerdings darauf achten, nicht die ursprüngliche Aufgabenstellung zu vergößern. Ist das der Fall, muss eine zusätzliche Benutzergeschichte erarbeitet werden, durch die die erweiterte Aufgabenstellung sichtbar wird, so dass die Priorisierung und Abschätzung der neu entstandenen Aufgabe möglich wird.

Definition of Ready

Mit dem hier dargelegten Vorgehen lassen sich Ideen transformieren zu Benutzergeschichten. Auf dieser Grundlage kann eine Arbeitsliste mit abgeschätzten und priorisierten Benutzergeschichten aufgebaut und gepflegt werden. Die Basis für agiles Anforderungsmanagement ist damit gelegt. Natürlich muss die Arbeitsliste kontinuierlich auf dem Laufenden gehalten werden. Neue Benutzergeschichten sind aufzunehmen und bereits aufgenommene Geschichten möglichwerweise zu restrukturieren und neu zu schätzen. Das geschieht immer in Absprache zwischen dem Product Owner/Produktmanager und dem Team.

Aus der vorbereiteten Arbeitsliste werden die jeweils nächsten Benutzergeschichten vom Team zur Auslieferung ausgewählt und in der kommenden Iteration umgesetzt. Auf die dazu erforderliche Iterationsplanung, die unter den Metaphern der Analyse und des Entwurfs stattfindet, gehe ich in diesem Zusammenhang nicht näher ein. Es hat sich der Begriff der Definition of Ready (Bereitstellungskriterien) eingebürgert, der beschreibt, welche Eigenschaften eine Benutzergeschichte innerhalb der Arbeitsliste haben muss, bevor das Team und der Product Owner diese Benutzergeschichte in der Planung der nächsten Iteration berücksichtigen können. Bereit bedeutet:

  • Klar: Die Benutzergeschichte ist klar, wenn alle Mitglieder des Teams ein gemeinsames Verständnis über den Inhalt und die Bedeutung der Benutzergeschichte haben.
  • Machbar: Die Benutzergeschichte ist machbar, wenn sie innerhalb einer Iteration gemäß der Definition of Done umgesetzt werden kann.
  • Testbar: Die Benutzergeschichte ist testbar, wenn es einen Weg gibt, die gewünschte Funktionalität darauf zu testen, ob sie funktioniert wie erwartet.

Benutzergeschichten werden durch das Team und den Product Owner im Rahmen der Pflege der Arbeitsliste bereit gemacht. Es ist nicht die alleinige Aufgabe des Product Owners, diese Vorbereitungen zu treffen, um dem Team die Konsumption der Benutzergeschichten leichter zu machen.

Definiton of Done

Die Definition of Done (Fertigstellungskriterien) legt fest, welche allgemeinen Anforderungen eine Benutzergeschichte erfüllen muss, um als erfolgreich umgesetzt zu gelten.

Auslieferung

Bereitgestellte Benutzergeschichten kommen für eine Auslieferung in der nächsten Iteration in Frage. Ob und wie das erfolgt, zeigt sich in der Iterationsplanung, die zu Beginn einer jeden Iteration durch das Team und den Product Owner durchgeführt wird.

Das Erarbeiten einer Aufgabenstellung, die für die Beteiligten klar ist und die somit den Selbstorganisationskräften eine Richtung geben kann, ist der wesentliche Aspekt agilen Anforderungsmanagements. Die hier vorgeschlagenen Techniken können Ihnen bei diesem Unterfangen eine Hilfe sein und erleichtern den beschwerlichen Weg von der Idee zum Produkt.

Referenzen

[Cunningham 2001] W. Cunningham, Essential XP: Card, Conversation, Confirmation, 2001, siehe: http://xprogramming.com/articles/expcardconversationconfirmation/

[Grenning 2002] J. Grenning, Planning Poker or How to avoid analysis paralysis while release planning, 2002, siehe: http://www.renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf

[Maloney] C. Maloney, Silent Brainstorming, siehe: http://www.getrealaboutbusiness.com/silent-brainstorming/

[Patton 2008] J. Patton, The new User Story Backlog is a Map, 2008, siehe: http://www.agileproductdesign.com/blog/the_new_backlog.html

[Pichler 2010] R. Pichler, Definition of Ready, 2010, siehe: http://www.romanpichler.com/blog/product-backlog/the-definition-of-ready/

[Röpstorff 2009] S. Röpstorff, Team Estimation Game, 2009, siehe: http://www.projekt-log.de/agile_softwareentwicklung/team-estimation-game/

[Schneider 2012] U. Schneider, Fertigstellungskriterien, 2012, siehe: https://allesagil.net/2012/07/03/fertigstellungskriterien-definition-of-done/

[Schwaber 2004] K. Schwaber, M. Beedle, Agile Software Development with Scrum, Pearson Prentice Hall 2004

[Westphal 2009] R. Westphal, Soziokratie – Organisationen agil führen, 2009, siehe: http://soziokratie.blogspot.de/2009/08/konsent.html

[Wiki] Wikipedia User Story, siehe: http://de.wikipedia.org/wiki/User_Story

Advertisements