User Story

So schreiben Sie richtig gute User Stories

Wenn Sie Software entwickeln, machen Sie sich regelmäßig Gedanken, wie Ihr Team mit den Wünschen, Ideen und Anforderungen des Auftraggebers umgeht. Gibt es ein Lastenheft und einen Projektplan? Arbeiten Sie sich vom Grobkonzept zum Feinkonzept? Oder arbeiten Sie schon agil? Dann kennen Sie sicherlich User Stories - eine beliebte und bewährte Variante in Scrum. Eigentlich ganz einfach: Anforderungen werden aus Nutzersicht so weit heruntergebrochen, dass sie auf eine DIN-A6-Karte passen. Trotzdem tun sich viele Teams anfangs mit User Stories schwer. Wie schreibt man also "gute" User-Stories?

Weiterlesen
Markiert in:

Scrum. Oder die Kunst, doppelt so viel Arbeit in der halben Zeit zu schaffen.

„The Art of Doing Twice the Work in Half the Time“ – ein im wahrsten Sinne des Wortes viel versprechender Buchtitel des Scrum-Mitbegründers Jeff Sutherland. In der deutschen Übersetzung war der Verlag zwar nicht ganz so mutig, nichtsdestotrotz bringt auch der Titel „Die Scrum-Revolution“ das Ziel des agilen Frameworks zum Ausdruck: einen Umbruch im Unternehmen bewirken.

Aber was kann die Wunderwaffe Scrum wirklich? Eignet sich Scrum für jedes Projekt, jedes Unternehmen, jedes Team – auch für Sie?


Mal ehrlich: Wo ist der Haken?

Dass Scrum mehr ist als ein US-Hype mit dem typisch amerikanischen Hang zur Übertreibung, beweisen inzwischen zahlreiche deutsche Erfolgsgeschichten. Ein gutes Beispiel ist die Scout24-Unternehmensgruppe. Das Münchner Online-Unternehmen setzte schon vor rund 7 Jahren auf Scrum in der Produkt- und Softwareentwicklung – mit schnell sichtbaren (und messbaren) Erfolgserlebnissen: Im ersten Jahr nach der Scrum-Einführung stieg die Entwicklungsgeschwindigkeit nach eigenen Angaben um 200 Prozent und die Anzahl kritischer Fehler konnte um rund 80 Prozent gesenkt werden.

Effizienzsteigerungen durch Scrum im Vergleich zu klassischen Wasserfall-Modellen sind nachgewiesen. Aber wenn es so einfach ist, warum machen dann eigentlich nicht alle Scrum?

„Scrum is very easy to understand but very difficult to master.“
Ken Schwaber

Scrum ist komplex. Scrum fordert. Und Scrum verändert. Auch Scout24 berichtete von der Erfahrung, dass Scrum weit mehr ist als eine „Methode“. Die Einführung von Agilität geht Hand in Hand mit einer neuen Unternehmenskultur, die unter anderem das Verhältnis zwischen Team und Management und das Verständnis von Arbeit und Führung hinterfragt – und bei Bedarf eben auch umkrempelt.

Schon gewusst? „Scrum“ wird 30!

So revolutionär der Ansatz vielen Unternehmen scheint: Die Erkenntnis, dass kleine, interdisziplinäre und selbstorganisierte Teams bessere Ergebnisse erzielen, ist nicht neu. Bereits vor Jahrzehnten experimentierten renommierte Firmen mit vergleichbaren Modellen des Projektmanagements, ausgehend von der Lean-Production-Bewegung in Japan.

1986 stellten Hirotaka Takeuchi und Ikujiro Nonaka in einem Aufsatz der Harvard Business Review verschiedene Fallbeispiele von Unternehmen vor, deren Produktentwicklungen ungewöhnlich schnell und innovativ waren, u.a. Pkws bei Honda, Spiegelreflexkameras bei Canon, Kopierer bei Fuji-Xerox sowie PCs bei NEC.

Als ausschlaggebende Gemeinsamkeit der analysierten Unternehmen identifizierten die beiden Wirtschaftswissenschaftler kleine Teams mit einer charakteristischen Arbeitsweise, die Takeuchi und Nonaka „Scrum“ nannten (die engl. Bezeichnung für einen Rugby-Spielzug, übersetzt „Gedränge“).

„In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method - as in rugby, the ball gets passed within the team as it moves as a unit up the field.“
Hirotaka Takeuchi und Ikujiro Nonaka

Takeuchi und Nonaka formulierten 6 Bedingungen für effiziente Teams:

  • Built-in instability
  • Self-organizing project teams
  • Overlapping development phases
  • Multilearning
  • Subtle control
  • Organizational transfer of learning

Inspiriert von Takeuchi und Nonaka entwickelten Jeff Sutherland und Ken Schwaber rund 10 Jahre später den „Rugby Approach“ weiter zu dem Framework, das wir heute als Scrum kennen.

Die Zeit war reif für Scrum

1994 veröffentlichte die Standish Group den ersten CHAOS-Report mit desaströsen Zahlen: Rund ein Drittel aller IT-Projekte scheiterte vorzeitig, nur 16 Prozent erreichten das angestrebte Entwicklungsziel ohne Mängel. Gleichzeitig erhöhte sich Mitte der 90er Jahre die Nachfrage nach leistungsfähiger Software rasant – entsprechend händeringend suchte die Softwareindustrie nach Lösungen.

Auch Sutherland und Schwaber beschäftigten sich intensiv mit der Frage, wie die Produktion von Software effizienter gestaltet werden konnte. Großes Verbesserungspotenzial sahen sie in der Flexibilisierung der Projektprozesse, weg von „top down“, hin zu mehr Spielraum für eigenverantwortliches Handeln.

Die Veröffentlichungen von Schwaber und Sutherland wurden von der Entwickler-Community wissbegierig aufgenommen und getestet. 2001 hielten Jeff Sutherland, Ken Schwaber und 15 weitere Experten die neuen Werte der Bewegung im Agilen Manifest fest – bis heute das Fundament aller agilen Methoden, von denen Scrum die populärste ist.

Scrum: Freiheit in Grenzen 

„Wenn man ein Projekt beginnt, warum sollte man dann nicht regelmäßig überprüfen, ob die Richtung noch stimmt und man Leistungen erbringt, die tatsächlich gebraucht werden? Warum nicht prüfen, ob es vielleicht Mittel und Wege gibt, um besser und schneller voranzukommen, und welche Hindernisse dem womöglich entgegenstehen?“
Jeff Sutherland

Als Gegenentwurf zum klassischen Projektmanagement formuliert Scrum statt eines Plans eine Vision, die erst im Projektverlauf konkretisiert wird. Diese empirische Entwicklung erfolgt nicht völlig ungesteuert, sondern iterativ-inkrementell und innerhalb fest definierter Rollen, Ereignisse und Artefakte.

2010 verfassten Ken Schwaber und Jeff Sutherland mit dem „Scrum Guide“ einen offiziellen Scrum-Leitfaden, der kontinuierlich weiterentwickelt wird.

Wichtig für den Projekterfolg ist das Zusammenspiel der Rollen, Ereignisse und Artefakte nach Scrum-Regeln. Dazu betrachten wir den Scrum-Flow genauer:

Der Scrum-Flow / © Teamprove

Die Scrum-Rollen

  • Product Owner
    Der Produkteigner vertritt die Interessen der Anwender und Stakeholder und ist für die strategische Entwicklung und den wirtschaftlichen Erfolg des Projekts verantwortlich. Er pflegt das Product Backlog und priorisiert die Anforderungen. Kurz gesagt: Er bestimmt WAS gemacht wird und in welcher Reihenfolge. Falls kein direkter Kontakt zwischen Entwicklungsteam und Kunde möglich ist, ist der Product Owner das Bindeglied zum Kunden.

  • Entwicklungsteam
    Das Team entscheidet gemeinsam, WIE die Vorgaben des Product Owners umgesetzt werden, unter Berücksichtigung der gewünschten Reihenfolge und unter Einhaltung der vereinbarten Qualitätsstandards. Scrum-Teams arbeiten interdisziplinär, ohne Hierarchien und mit einer optimalen Teamgröße von 7 +/-2 Mitgliedern.

  • Scrum Master
    Der Scrum Master stellt sicher, dass die Scrum-Regeln und Werte eingehalten werden und hilft dem Team, selbstorganisiertes Arbeiten so anzuwenden, dass bessere Ergebnisse erzielt werden. Er ist nicht weisungsbefugt, sondern fungiert als Moderator und versteht sich als Dienstleister des Projektteams.

Die Scrum-Ereignisse

Aktivitäten im Scrum-Prozess:

  • Sprint Planning
    Priorisierung und Auswahl der Backlog Items für den nächsten Sprint

  • Daily Scrum
    Status quo und Tagesplanung

  • Sprint Review
    Präsentation des Inkrements

  • Sprint-Retrospektive
    Rückblick mit dem Ziel der Verbesserung

  • Product Backlog Refinement / Grooming
    Pflege des Product Backlogs

Die Scrum-Artefakte

Resultate des Scrum-Prozesses:

  • Product Backlog
    alle Anforderungen an das Produkt

  • Sprint Backlog
    alle ausgewählten Backlog Items für einen Sprint

  • Product Increment
    fertiges Teilprodukt, das am Ende des Sprints geliefert wird

Von der Vision zum Product Backlog

Aus der Vision des Product Owners werden sämtliche Elemente des Produkts abgeleitet, die entwickelt werden müssen.


Formulieren Sie die Funktionalitäten („Product Backlog Items“) in Form von User Stories auf Story Cards! Wichtig: Beschreiben Sie die Funktionalität aus Sicht des Anwenders in 1 Satz, ohne technischen Fachjargon und immer unter Betrachung des Kundennutzens. Bewährt hat sich das Muster „Ich als möchte <Ziel/Wunsch> um “. Ein Beispiel: „Als Nutzer des Onlineshops will ich zwischen verschiedenen Versandoptionen wählen können, um die Lieferung genau dann zu bekommen, wann ich sie benötige.“

Die Summe aller User Stories bildet das Product Backlog - eine Sammlung sämtlicher Funktionen und Merkmale, die das fertige Produkt haben soll. Zu Beginn des Projekts ist das Product Backlog noch grob und wird im Projektverlauf immer detaillierter. Auf Basis der User Stories wird auch der Aufwand für das Projekt geschätzt.

Nach dem Sprint ist vor dem Sprint

Charakteristisch für Scrum ist die Entwicklung in Zyklen („Sprints“). Die sogenannten Sprints sind während des Projekts immer gleich lang („Timebox“), um einen Entwicklungsrhythmus zu erzeugen. Gemäß Scrum-Guide sind die Sprints zwei bis maximal vier Wochen lang.


Wir haben gute Erfahrungen damit gemacht, eine Scrum-Einführung mit einwöchigen Sprints zu starten. So gewöhnen sich die Projektbeteiligten schneller an die Routine von Scrum-Ereignissen und Scrum-Artefakten und das Feedback fließt in kürzeren Abständen ein. Auch Fragen und Änderungen können in einwöchigen Sprints sehr zeitnah diskutiert werden.

Ziel jedes Sprints ist die Fertigstellung einer neuen, lauffähigen Funktion („Inkrement“), die dem Kunden ausgeliefert werden könnte, d.h. innerhalb jedes Sprints werden alle Aufgaben (Planung, Entwicklung, Test, Dokumentation) abgeschlossen. Auch wenn die sofortige Nutzung nicht in jedem Sprint funktioniert (und auch nicht bei jedem Inkrement sinnvoll ist), so ist ein „potentially shippable increment“ doch immer das Ziel! So wird im Verlauf der Sprints der Umfang bzw. die Qualität des Produkts immer ausgereifter.

Aber wann ist ein Inkrement „fertig“? Als Bemessungsgrundlage dient hier die „Definition of Done“ – eine Checkliste konkreter und verbindlicher Anforderungen, auf die sich Product Owner und Team vor Beginn des Sprints einigen.

Während eines Sprints organisiert sich das Entwicklungsteam selbst und die Anforderungen dürfen nicht verändert werden.

Und was macht man so während eines Sprints?

Der Vorteil von Scrum liegt in der Ritualisierung der Prozesse: Alle Meetings finden regelmäßig und innerhalb einer gleichbleibenden Timebox statt. Alle Teilnehmer kennen das Ziel des Meetings und die zur Verfügung stehende Zeit. So ist gewährleistet, dass sich jeder auf das Wesentliche konzentriert und jedes Meeting dazu beiträgt, das Projekt voranzubringen – das Projekt bleibt kontinuierlich in einem produktiven „Flow“.

Sprint Planning

Jeder Sprint beginnt mit einer meist eintägigen Sprint-Planung: Der Product Owner präsentiert sein Ziel sowie die Product Backlog Items mit der höchsten Priorität, und das Team stellt Rückfragen, bis alle Anforderungen verstanden sind.

Auf Basis der Aufwandsschätzung  und der Kapazitäten entscheiden die Teammitglieder dann gemeinsam, wie viele Stories sie in der vom Product Owner vorgegebenen Reihenfolge in den Sprint übernehmen („committen“) können. Aus der Liste dieser ausgewählten User Stories für den nächsten Sprint entsteht das Sprint Backlog.


Achten Sie darauf, dass das Team seine Arbeitsmenge und die Arbeitsweise unbeeinflusst selbst steuern kann – es bekommt keinerlei Vorgaben über das „WIEVIEL“ und das „WIE“! Gleichzeitig trägt das Team die Verantwortung für eine pünktliche Lieferung der zugesagten Funktionalitäten in der vereinbarten Qualität - ein typischer Knackpunkt zu Beginn einer Scrum-Transition, da sich die Teams häufig zu hohe, unrealistische Ziele setzen.

Daily Scrum

Jeden Tag zur selben Zeit trifft sich das Team zu einem 15-minütigen Meeting, das vom Scrum Master moderiert wird. Die Teammitglieder berichten über die Fortschritte, sprechen sich ab, wer welche Aufgabe übernimmt und informieren den Scrum Master über Probleme. (Was habe ich gestern getan? Was werde ich heute tun? Was hindert mich zu tun, was getan werden müsste?) Auf einem Scrum Board wird ähnlich wie beim Kanban-Board der Status der einzelnen Aufgaben visualisiert.


Verwenden Sie hier ein physisches Board, das viel Platz bietet! Es gibt zwar gute digitale Tools, aber eine Tafel erhöht die Transparenz und fördert die Kommunikation. Können Sie auf die Online-Variante nicht verzichten (z.B. weil sich die zeitweise räumliche Trennung des Teams nicht ganz vermeiden lässt), so ist ein zusätzliches physisches Board trotzdem sehr empfehlenswert.

Product Backlog Refinement

Für die Backlog-Pflege hat sich ein Product Backlog Refinement (oder „Grooming“) gegen Ende des Sprints bewährt. Ziel ist es, frühzeitig neue Informationen zusammenzutragen, so dass Product Owner und Teammitglieder optimal vorbereitet in das nächste Planning Meeting gehen.

Gegenstand des Refinement-Meetings sind beispielsweise Priorisierungen für den nächsten Sprint, Erweiterungen des Product Backlogs, das Herunterbrechen umfangreicher Backlog-Items in zeitlich umsetzbare Stories sowie neue oder genauere Aufwandsschätzungen.


Planen Sie ausreichend Zeit für das Grooming ein – der Scrum Guide sieht vor, bis zu 10 Prozent der Sprint-Zeit für das Refinement-Meeting zu reservieren, um das nächste Sprint Planning so effizient wie möglich zu gestalten.

Sprint Review

Am Ende des Sprints präsentiert das Team dem Product Owner die neue Funktionalität. Nur lauffähige Inkremente dürfen vorgestellt werden, alle nicht fertig gestellten Funktionalitäten gelten als nicht geliefert.

Sprint Retrospektive

Ein wesentliches Scrum-Element ist kontinuierliches Lernen: Im Rahmen einer Sprint Retrospektive analysieren die Teammitglieder die Prozesse und beschließen, welche Änderungen nötig sind, um in der Zukunft effektiver zu arbeiten („Backlog Impediment“).


Die Änderungen sollten nicht auf die lange Bank geschoben, sondern möglichst sofort umgesetzt werden! Übrigens: Zum effektiven Arbeiten zählt auch der Spaß an der Arbeit! Die Verbesserungsvorschläge können also durchaus auch Ideen aufgreifen, wie die intrinsische Motivation erhöht werden kann.

Und wann ist das Produkt fertig?

Der Scrum-Trick: Mit den Inkrementen erhält der Kunde während des Projekts schon sehr früh voll funktionsfähige (Teil-)Versionen geliefert, die mit jeder Iteration umfangreicher und/oder qualitativ hochwertiger werden. Neue Features können mit „echten“ Nutzern getestet werden, und in jedem Sprint können bestehende Anforderungen abgeändert oder neu priorisiert werden.

So bestimmt der Kunde während des gesamten Projekts die Entwicklungsrichtung – auch den Zeitpunkt des Projektabschlusses: Wenn der Product Owner mit den Funktionalitäten der aktuellen Produktversion zufrieden ist und keine weiteren Entwicklungen wünscht, ist das Scrum-Projekt beendet.

Scrum: lean, aber nicht leicht

„Prima, Scrum passt ja auf 1 DIN-A4-Blatt!“, so scheint der erste Eindruck. Stimmt, das Rahmenwerk ist schlank und die Regeln sind einfach zu verstehen – aber in der Umsetzung alles andere als trivial! Insbesondere das neue Rollenverständnis und das selbstorganisierte, interdisziplinäre Arbeiten ohne übergeordneten Projektmanager und ohne genaue Vorgaben „von oben“ muss verinnerlicht werden.

In Unternehmen mit anweisungsorientierter Unternehmenskultur sind außerdem nicht nur die Erwartungen hoch, sondern auch die Bedenkenliste lang:

  • Wird unser Management durch Scrum entmachtet?
  • Was passiert mit den Zielvereinbarungen (MBO) unserer Mitarbeiter?
  • Was machen künftig überhaupt unsere Projektleiter?
  • Wie sollen wir Budgets planen, wenn die Aufwände nicht exakt geschätzt werden können?
  • Sind unsere Projekte nicht zu groß für agile Methoden (Thema Skalierung)?

Fakt ist: Der Erfolg von Scrum hängt von zahlreichen Faktoren ab. Wie aufgeschlossen sind die Teammitglieder für die neuen Prozesse – und wie gut setzen sie Selbstorganisation um? Hält sich das Management in den Meetings tatsächlich mit „top down“-Ansagen zurück? Wird von beiden Seiten offen und ehrlich kommuniziert? Hat das Team Unterstützung durch einen versierten Scrum Master?


Sofern im Team niemand die nötige Erfahrung hat, um die Rolle des Scrum Masters einzunehmen, ist die Begleitung durch einen externen Scrum-Coach empfehlenswert, der übergangsweise die Rolle des Scrum Masters übernimmt und das Team bei der Transition unterstützt. 

Die wichtigste Voraussetzung für eine erfolgreiche Scrum-Transition ist die Bereitschaft für die in Sutherlands Buch versprochene Revolution im Unternehmen – alles andere ist erlernbar. Um auf den Titel zurückzukommen: Ja, dann kann Scrum tatsächlich dazu führen, die doppelte Arbeit in der halben Zeit zu schaffen. Wir helfen Ihnen gerne dabei! Eine Liste mit Lesetipps finden Sie übrigens hier.

Welche Erfahrungen haben Sie mit der Einführung von Scrum gemacht? Wir freuen uns auf Ihre Kommentare und Fragen!

Bildnachweis:
Titelbild Scrum: matthewjones / 123RF

Weiterlesen

Die Karten auf den Tisch! | Aufwandsschätzung Teil 3

Aufwandsschätzung ist sinnvoll. So unser Fazit nach Teil 1 und Teil 2 unserer Serie. Auch die Begriffe „Story Points“ und „Velocity“ konnten wir (hoffentlich) verständlich erklären. Aber jetzt ab in die Praxis: Wie läuft das konkret in den Entwicklerteams und welche Schätzmethoden haben sich bewährt? Wir werden in diesem Artikel einen kurzen Überblick über die unterschiedlichen Herangehensweisen geben und dann im Detail vor allem auf agile Schätzspiele wie den „Planning Poker“ eingehen.


agil = undiszipliniert?

Dieses Prinzip wird häufig von den Teams, aber auch von Kunden falsch interpretiert: „Wir arbeiten eben agil“ ist keine Ausrede für Projekte, deren Zeitplan oder Budget aus dem Ruder läuft oder bei denen Augenwischerei betrieben wurde, um den Aufwand zu Projektbeginn möglichst kleinzureden! Ganz im Gegenteil ist es das Ziel agiler Methoden, zielführender und damit wirtschaftlicher zu arbeiten, indem individuell entschieden wird, wieviel Dokumentation und Planung zum jeweiligen Projektzeitpunkt wirklich nötig sind.

„So wenig wie möglich, so viel wie nötig“: Vor dem Hintergrund, dass die Schätzkosten im Schnitt satte 3 Prozent der Projektkosten ausmachen, eine absolut sinnvolle Vorgehensweise!

Es gibt nicht „die“ Schätzmethode!

Um die verschiedenen Methoden besser in den Gesamtkontext einordnen zu können, holen wir etwas aus – wirklich nur kurz, versprochen! Grob eingeteilt gibt es zwei Ansätze, um Schätzungen durchzuführen:

Eine algorithmische Schätzung berechnet den Aufwand mit Hilfe mathematischer Formeln aus historischem Datenmaterial, statistischen Analysen und der Bewertung bereits vorliegender Größen. Entscheidend für ein präzises Ergebnis ist die Kalibrierung, d.h. die Parameter der Formel müssen firmenspezifisch angepasst werden (z.B. die Erfahrung der Mitarbeiter). Zwei der bekanntesten algorithmischen Methoden sind COCOMO und das Function-Point-Verfahren  – vergleichsweise aufwändig, aber bei gutem Datenmaterial in der Regel sehr präzise.

Eine empirische Schätzung basiert auf Erfahrungswerten von Fachleuten und/oder früherer, vergleichbarer Projekte. Am gängigsten sind hier Expertenschätzungen, zu denen u.a. beispielsweise der auf der Delphi-Methode basierende „Planning Poker“ und die Schätzklausur zählen.

Auch wenn es gerade für kühle Rechner im Controlling verlockend erscheint, eine Formel mit Zahlen zu füttern und so den Aufwand berechnen zu können: Die Erfahrung zeigt, dass empirische Methoden hinsichtlich der Präzision locker mithalten können. Da in agilen Teams außerdem großer Wert darauf gelegt wird, dass die Schätzmethode von allen Beteiligten ohne großen Erklärungsaufwand angewendet werden kann, kommen die hochkomplexen algorithmischen Modelle im agilen Umfeld kaum zum Einsatz bzw. in adaptierter Form (z.B. „Agile COCOMO“).

Am weitesten verbreitet ist die Expertenschätzung – laut Umfragen in rund 80 Prozent der Unternehmen die Methode der Wahl. Die Qualität der Schätzung hängt nicht nur von der Erfahrung der Schätzenden ab, sondern auch von der Anzahl durchgeführter vergleichbarer Projekte. Grobe Abweichungen können beispielsweise entstehen, wenn Erfahrungen aus kleinen Projekten 1:1 auf große Projekte skaliert werden.

In Scrum-Projekten ist eine realistische Aufwandsschätzung unter anderem nötig, um zu entscheiden, wie viele User Stories in einen Sprint gepackt werden können. Wir stellen hier drei Schätzvarianten vor, die sich in agilen Teams bewährt haben – nicht zuletzt aufgrund ihres spielerischen Charakters: das beliebte „Planning Poker“ nach Mike Cohn, „Magic Estimation“ nach Lowel Lindstorms und das „Team Estimation Game“ nach Steve Bockman.

Planning Poker

Populär wurde Schätzpoker in den letzten 10 Jahren durch Mike Cohn’s Buch „Agile Estimating and Planning“. Vorteil: Es handelt sich um ein transparentes, konsensorientiertes Verfahren, d.h. das Team versucht gemeinsam zu einer möglichst realistischen Schätzung des Entwicklungsaufwands zu kommen – perfekt für agile Teams, um deren gewünschte Selbststeuerung zu unterstützen.

Moderiert wird der Schätzvorgang durch den Scrum Master, optimalerweise steht auch der Product Owner für Verständnisfragen zur Verfügung. Zu Beginn wird eine möglichst kleine und einfach zu schätzende User-Story als Referenz festgelegt, zum Beispiel ein Formular. Jedes Teammitglied erhält nun einen Satz Schätzpoker-Karten. Die gängigen Kartensätze arbeiten mit der Fibonacci-Zahlenreihe 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, „?“ (kann nicht geschätzt werden) und „Pause“ (z.B. eine Kaffeetasse).

Nun stellt der Scrum Master die einzelnen zu schätzenden User Stories vor. Wichtig ist, bei der Beschreibung Wertungen wie „einfach“ oder „kompliziert“ zu vermeiden, um das Team nicht zu beeinflussen.

Anschließend kommen die Karten ins Spiel: Jedes Teammitglied legt für die betreffende Story verdeckt (!) eine Karte mit dem geschätzten Story-Points-Wert auf den Tisch. Die Zahlen auf den Karten sind eine Maßeinheit für die Komplexität in Bezug auf die anfangs festgelegte Referenzstory.

Weichen nach dem Umdrehen der Karten die einzelnen Bewertungen erheblich voneinander ab, begründen die Schätzer des größten und kleinsten Werts ihre Entscheidung. Die anderen Teilnehmer und der Product Owner können an der Diskussion teilnehmen. Dann wird die Schätzung wiederholt, bis es zu einem Konsens kommt. Wichtig ist es, dass es sich dabei nicht um einen „faulen Kompromiss“ handelt, sondern um einen Schätzwert, hinter dem jedes einzelne Teammitglied steht – sowohl die konservativen als auch die optimistischen Schätzer.

Teams mit ungeübten Schätzern verzichten häufig auch auf die Karten mit den Werten 20, 40 und 100 und brechen die User-Stories lieber auf mehrere kleinere, weniger komplexe Teileinheiten herunter. Sinnvoll ist es außerdem, eine Pokerrunde auf maximal 90 Minuten zu begrenzen – wenn die Konzentration nachlässt, ist es Zeit, die „Pause“-Karte auszuspielen.

Magic Estimation

Bei großen Projekten kann es zum Start sinnvoll sein, die einzelnen User Stories nicht nacheinander zu schätzen, sondern auf „magische“ Weise zu einem schnelleren Ergebnis zu kommen:  Wie beim Schätzpoker wird eine Referenzstory festgelegt und der Scrum Master stellt (bei Bedarf unterstützt vom Product Owner) die einzelnen User Stories vor. Anschließend verteilt er die Karten mit den User Stories unter den Teammitgliedern. Auf dem Boden wird (z.B. mit Schätzpoker-Karten) die Fibonacci-Reihe ausgelegt.

Nun läuft die Stoppuhr: Jeder hat nun 10 Minuten Zeit, seine Karten entlang der Skala gemäß seiner Komplexitätsschätzung zu platzieren UND auch Karten anderer Teammitglieder zu verschieben. So entsteht sehr zügig ein erstes Bild, wie die Teammitglieder die Aufwände der einzelnen User Stories im Vergleich zueinander sowie zur Referenzstory einschätzen. Gleichzeitig wird schnell klar, bei welchen Karten sich die Teammitglieder uneinig sind – diese werden zur Seite gelegt und später gemeinsam diskutiert. Bei „Magic Estimation“ geht es noch nicht so sehr um Präzision, sondern um Relation und eine erste grobe Einschätzung.

Team Estimation Game

Haben Sie ein Team, dessen Schätzungen regelmäßig in lange technische Diskussionen über das „Wie“ ausufern? Dann ist das Team Estimation Game vielleicht die richtige Schätzmethode für Sie: Auch hier moderiert der Scrum Master das Meeting und der Product Owner beantwortet Fragen. Alle User Stories liegen verdeckt auf einem Kartenstapel.

Das erste Teammitglied zieht eine User Story aus dem Stapel und platziert sie in der Mitte des Whiteboards.

Das zweite Teammitglied zieht eine weitere User Story und hat nun drei Möglichkeiten, diese in Relation zur ersten User Story zu setzen:

  • neben der ersten Karte: ähnliche Komplexität
  • unter der ersten Karte: größere Komplexität
  • über der ersten Karte: niedrigere Komplexität

Die nächsten Teammitglieder haben nun jeweils zwei Möglichkeiten:

  • Sie ziehen eine neue Karte und platzieren diese entsprechend.
  • Sie verändern die Position einer bereits gepinnten User Story, weil sie mit der bisherigen Komplexitätseinschätzung nicht einverstanden sind.

So geht es reihum, bis alle User Stories ausgespielt und platziert sind. Üblicherweise bilden sich „Cluster“, die am Ende des Spiels noch mit konkreten Story Points versehen werden können (z.B. indem das Team den Clustern Zahlenkarten aus dem Planning-Poker-Set zuordnet).

Unbedingt sinnvoll ist es, die Umpositionierung von Karten zu vermerken, z.B. durch Klebepunkte, und Karten ab 3 Klebepunkten später gemeinsam zu diskutieren.

Übung macht den Meister

Egal ob Planning Poker, Team Estimation Game oder eine ganz andere Methode: Wichtig für möglichst gute Expertenschätzungen ist üben, üben, üben. Jeder Entwickler hat eine individuelle Zeitspanne, die er realistisch abschätzen kann und die noch dazu je nach Schwierigkeitsgrad der Aufgabe variiert. Die Einteilung des Projekts in User Stories sollte deshalb auf das Schätzvermögen Ihres Teams zugeschnitten sein.

Tipp: Notieren Sie VOR jedem Projekt Ihre Schätzungen und gleichen Sie NACH der Umsetzung ganz ehrlich ab, wie viel Zeit tatsächlich benötigt wurde. So trainieren Sie Ihre Wahrnehmung – bis sich im Idealfall Soll und Ist irgendwann decken.

Sie haben Fragen zu bestimmten Schätzverfahren oder benötigen Unterstützung bei der Auswahl einer für Sie geeigneten Methode? Gerne coachen wir Ihre Teams bei der Durchführung von Schätzmeetings!

Weiterlesen