Why You Should Define Reference User Stories

If your organization is new to Agile one of the things you might struggle is the shift from traditional to agile estimation. I have seen a lot of inexperienced agile teams struggling with the nature of story points and relative sizing. Often a lack of trust in their own estimates, which led to poor planning, was the consequence. A simple tool, called reference user stories, helped each of these teams to overcome these difficulties.

If you haven’t defined reference stories with your team yet, consider well-defined, well-sized, not too domain specific user story from your past sprint(s) as candidates. Ideally you want to have reference stories of different size (e.g. 1, 2, 3, 5, 8 and 13 story points). Alternatively you can define artificial user stories that will serve as your references. Create a table of your reference stories, like the one below, and use it in your backlog refinement meetings. Feel free to add or exchange reference stories later if you feel the need later.

Size User Story
1 Story A: As a user I want to see my user name on the page so that I know that I am logged in with the right user.
2 Story B: As a user I want to write a comment to a topic so that I can express my opinion to the author.
3 Story C: As an administrator I want to block users for the forum so that I can prevent them from spamming.
5 Story D: As a user I want to register for the website so that I can use their premium services.
8 Story E: As a system administrator I want to migrate data from database A to database B via an automated script so that I can handle the amount of data.
13 Story F: As a user I want to purchase a product via the online shop so that the article is delivered to my home.

According to my experience reference user stories have the following main benefits for agile teams:

  • Supporting relative estimation: A user story (e.g. Story X) is relatively sized to the defined reference stories (e.g. Story A, B, C, D, E, F), which helps to focus on relative estimates (e.g. story X is bigger than story B, but smaller than story D) instead of absolute figures (e.g. story B will take 40 hours of work).
  • Increase accuracy of estimates: Relative estimates are more accurate, because our brain is naturally better at relative sizing then in absolute estimation. Defined reference stories also keep a stable reference and therefore reduce variability in the estimates.
  • Normalization of story points: Defining, sharing and using reference stories among multiple teams, normalizes their view on story points. With normalized story points we can calculate velocities for multi-team projects by just summing up the team velocities. (WARNING: Never abuse normalized velocities for team performance measures!)
Advertisements

Das Pair Programming Experiment

Vor ein paar Wochen habe ich mit meinem verteilten Team ein Pair Programming Experiment durchgeführt: 2 Entwickler auf 2 Standorten (einer in Graz, einer in Rumänien) haben vier Wochen lang ausschließlich mittels Pair Programming entwickelt – das heißt ca. 160 Stunden Remote Pair Programming!

Ausgangslage:

Mein verteiltes Team hatte sich über die letzten Monate gut weiterentwickelt und an Professionalität gewonnen. Pair Programming war jedoch bis dato noch keine etablierte Praxis im Team. Das wollte ich ändern, da es auch gute Gründe gab die Entwickler zu engerer Zusammenarbeit zu bewegen. Es wurde bis dato nämlich bevorzugt alleine an Tasks zu entwickelt und für meine Begriffe zu wenig kommuniziert. Bei einem unserer Kollegen in Rumänien (Marius) war die Kommunikations-Situation besonders schwierig. Zum einen hatte Marius an seinem Standort in Rumänien keinen lokal arbeitenden Teamkollegen mit dem er sich vor Ort austauschen konnte. Zum Anderen hatte er häufig mit Impediments zu kämpfen, von denen er das Team selten in Kenntnis setzte und stattdessen versuchte selbst Lösungen zu finden. Die folgenden Probleme galt es in dieser Situation zu lösen:

  • Marius war als Einzelkämpfer an einem externen Standort zu wenig in das Team eingebunden
  • Marius kommunizierte seinen Bedarf an Hilfe zu spät ans Team
  • Marius versuchte aufkommende Probleme (meist erfolglos) selbst zu lösen

Idee:

In einer Retro kam mir dann die Idee für das Pair Programming Experiment. Marius solle einen Sprint lang kosequent mit einem in Graz arbeitendem Senior Entwickler (Edwin) ausschließlich Pair Programming machen. Ich wollte damit erreichen, dass die Isolation von Marius beendet und die Kommunikation verbessert wurde. In Folge erhoffte ich mir einen wechselseitigen Wissensaustausch, rasche Lösung von Marius’ Problemen und in Folge eine Leistungssteigerung des Teams. Da Marius selbst merkte, dass er mehr Hilfe benötigte als er selbst anforderte war er mit der Idee einverstanden und auch Edwin fand den Versuch spannend.

Verlauf des Pair Programming Experiments:

Nach wenigen Tagen war bereits klar, dass das Pair Programming zwischen Marius und Edwin seinen Zweck erfüllte. So konnte Edwin in den ersten zwei Tagen eine Vielzahl an Verbesserungen von Marius’ Entwicklungsumgebung und Infrastruktur identifizieren und umsetzen. Es wurde auch viel Smalltalk geführt, was die soziale Isolation von Marius aufbrach und der Motivation zu Gute kam. Durch die enge Zusammenarbeit wurde laufend Wissen zwischen Edwin und Marius ausgetauscht, was einen enormen Lernfeffekt hatte. Am Ende des Sprints konnten wir ein erfreuliches Resümee ziehen: Alle waren sich einig, dass uns das Pair Programming als Team verbesserte. Daher beschlossen wir das Experiment für weitere 2 Wochen fortzusetzen, die unsere Erfahrungen aus den ersten beiden Wochen bestätigen sollten.

Retrospektive:

Nach Ende der 4 Wochen machte ich mit Marius und Edwin eine Retrospektive über das Experiment. Vor allem deren persönliche Befinden, die erzielten Lerneffekte und die Rollenverteilung wärend des Experiments waren für mich interessant zu erfahren.

Rollenverteilung:

Im klassischen Pair Programming wechseln sich die Pairing-Partner regelmässig in den Rollen des Navigators und Drivers ab. Wärend der Driver den Code schreibt, sitzt der Navigator daneben und denkt mit, ohne selbst Code zu schreiben. Edwin sollte Anfangs als der erfahrenere Entwickler vorwiegend Marius’ Arbeitsweise beobachten und ihm Hinweise für Verbesserungen geben. Dadurch war Edwin typischerweise häufiger in der Rolle des Navigators. Durch die Beobachtungen von Edwin konnten rasch Schwächen in der Arbeitsweise und am Environment von Marius identifiziert und behoben werden. Über die gesamte Dauer des Experiments zeigte sich, dass sich Marius mit der Analyse von Problemen etwas schwerer tat als Edwin – er erkannte häufig nicht die Wurzel der Probleme und betrieb damit häufig Symptombekämpfung. War jedoch einmal klar was zu tun ist, war Marius wiederrum sehr effizient beim Code umsetzen. Die persönlichen Stärken und Schwächen der beiden Entwickler haben sich durch das Pair Programming sehr gut ergänzt.

Lerneffekte:

Die folgenden Lerneffekte wurden von Marius und Edwin genannt:

  • Gegenseitige Verbesserung der Programmierskills, durch engen Austausch und Beobachtung der anderen Arbeitsweise
  • Marius’ Schwächen in der Analyse konnte durch Edwins Analyse-Stärken kompensiert werden
  • Environment Probleme von Marius konnten identifiziert und gefixt werden, da mit Edwin’s System ein Vergleichsystem verfügbar war
  • Vor allem bei komplexen Tasks zeigte sich Pair Programming für beide effizienter
  • Kommunikations-Barriere minimierte sich durch den dauerhaft offenen Kommunikationskanal zwischen Graz und Rumänien

Persönliches Empfinden:

Marius und Edwin nannten folgende Punkte zu ihrem persönlichen Empfinden wärend des Experiments:

  • Sozial hat die Zusammenarbeit zwiscehn den beiden sehr gut harmoniert
  • Pair Programming half einen hohen Fokus auf die Arbeit zu halten
  • Durch die gemeinsame produktive Arbeit blieb die Motivation dauerhaft hoch
  • Für Marius wurde soziale Nähe zum Team geschaffen (Privatgespräche, Smalltalk,…)
  • Für Marius war die Identifikation mit dem Team höher
  • Das Dauer-Pair-Programming war für beide anstregend aber überzeugend

Conclusio:

Mein Resümee aus dem Experiment ist, dass Pair Programming verteilt mit den richtigen Tools genauso effizient eingesetzt werden kann, wie für lokale Teams. Voraussetzung ist allerdings die Bereitschaft des Teams, konsequent die Praktik umzusetzen sowie die soziale Verträglichkeit der Pairing Partner. Ein akuter Anlassfall bietet immer eine gute Möglichkeit für eine Veränderung, wie die Einführung einer neuen Programmier-Praktik. Tituliert man eine Veränderung als Experiment oder Versuch, so ist der Widerstand des Teams meist geringer, da der Versuch noch keine Verbindlichkeit erzeugt. Implizites Wissen (z.B. Erfahrung), das nicht durch Schulungen transportiert werden kann, lässt sich hervorragend über Pair Programming vermitteln.

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

A Language of Commitment

Sprint Commitments sind essentiell für die Arbeit mit Scrum, wenn auch nicht ganz unumstritten. Ich möchte hier jedoch nicht auf die Streitbarkeit eingehen sondern auf das, was sich hinter dem Begriff eigentlich verbirgt.

George Dinwiddie verfasst einen hervorragenden Blogpost mit dem Titel “Dysfunctional Commitment”.

Vielen wahrscheinlich bekannt, die Chicken-Pig-Geschichte über Commitment:

A Pig and a Chicken are walking down the road.The Chicken says: “Hey Pig, I was thinking we should open a restaurant!”Pig replies: “Hm, maybe, what would we call it?”The Chicken responds: “How about ‘ham-n-eggs’?”The Pig thinks for a moment and says: “No thanks. I’d be committed, but you’d only be involved!”

Robert C. Martin zitiert Roy Osherove in seinem exzellentem Buch “The Clean Coder“:

Nach Osherove besteht ein Commitment aus 3 Teilen:

  1. Du sagst, dass du etwas machen wirst
  2. Du meinst es auch so
  3. Du machst es

Für mich ist es genau diese Macher-Mentalität, die Einstellung mich mit vollem Einsatz einer Sache zu widmen und diese mit zuhilfenahme aller möglichen Mittel zum Ende zu bringen, die es ausmacht ob ich zu etwas Commitet bin oder nicht.

Agile Planung

Seit längerem komme ich wieder dazu einen Blogpost zu schreiben. Es hat sich einiges an Posting-Material in den letzten Monaten angesammelt. Das heutige Thema ist Planung in der agilen Welt.

Kent Beck und Martin Fowler sagen dazu in “Planning Extreme Programming” folgendes:

“We plan to ensure that we are always doing the most important things left to do, to coordinate effectively with other people, and to respond quickly to unexpected events”

In der Praxis zeigt sich immer wieder wie wichtig es ist, den Spagat zwischen Planung und Agilität zu schaffen. Als Scrum Master sehe ich vor allem die Herausforderung der Sprintplanung. Auch im Sprint gilt nämlich: Spät entdeckte Planungsfehler sind teuer!

In meinen Scrum Teams teilen wir das Sprint Planning in 2 Teile:

Sprint Planning 1 (SP1)

Leitfrage: WAS soll in diesem Sprint umgesetzt werden?

Fokus: Fachlich (Business Value, Kundensicht)

Outcome:

  • Fachlich, einheitliche Sicht auf die einzelnen User Stories, die im Sprint Planning vom Product Owner vorgestellt wurden
  • Commitment des Teams, welche User Stories es im Sprint umsetzen kann

Sprint Planning 2 (SP2)

Leitfrage: WIE sollen die im Commitment enthaltenen User Stories umgesetzt werden?

Fokus: Technisch (Design, Architektur)

Outcome:

  • Technisches Design für die im Commitment enthaltenen User Stories
  • Tasks, welche alle Aufgaben zur Umsetzung der User Stories umfassen

Wie immer, sieht die Theorie einfacher aus, als die praktische Umsetzung dann tatsächlich ist. Folgende Probleme treten in der Praxis in der Sprint Planung auf:

Problem Lösungsvorschlag
Im SP1 sind noch fachliche Anforderungen des Kunden unklar. Jene User Stories, die noch unklar sind nicht in das Commitment aufnehmen. Der PO muss sich um die Klärung der Anforderungen erst kümmern. Es macht keinen Sinn diese User Stories zu beginnen!
Für das technische Design ist zu wenig Know-how im Team vorhanden. Architekten, Know-how Träger aus der Domäne zum SP2 einladen.
Im SP2 wird das Design nur oberflächlich geplant. Konkreten “Desired Outcome” für das SP2 festlegen: z.B.: UML Klassen-Diagramme, Interface-Beschreibungen, Tracer Bullets, Tasks < 8h, Codestellen gemeinsam inspizieren, Offene Fragen wenn möglich gleich im SP2 klären.
Für das technische Design ist zu wenig Know-how im Team vorhanden. Architekten, Know-how Träger aus der Domäne zum SP2 einladen.
Das SP2 verläuft unproduktiv. Jeder Entwickler moderiert für eine User Story das SP2, Pausen machen wenn keine Energie mehr vorhanden ist, Jede User Story einzeln planen.
Im SP2 wurden Tasks vergessen aufzuschreiben. Für jede User Story einen abschließenden Check machen, ob alle Tasks für die vollständige Implementierung (+ Tests) der User Story vorhanden sind.
Während der Implementierung (Sprint) herrscht Unklarheit über den Scope der einzelnen Tasks. Wording der Tasks im SP2 genau besprechen, Besser 2 speziellere Tasks statt einen generischen Task aufschreiben, Falls die übliche Taskbeschreibung nicht ausreicht um die Semantik zu klären, eine erweiterte Beschreibung hinzufügen.

User Stories richtig formulieren

In der agilen Softwareentwicklung hat sich das Arbeiten mit User Stories etabliert. Eine User Story beschreibt immer eine Kundenanforderung, den dahinter liegenden Business Case, so wie den Nutzen für den Anwender und dient als Ausgangspunkt für das Entwicklerteam, so wie für die Kommunikation mit dem Kunden, Entwicklern, Product Ownern, Auftraggebern, usw. Im optimalen Fall liegen bei der Erstellung von User Stories definierte Use Cases und Personas vor, die bei der Erstellung von User Stories als Hilfestellung dienen. Der erste Teil der User Story, die High-Level Beschreibung, beantwortet immer möglichst kurz und prägnant folgende Fragen: Wer will Was, Warum tun? (Mike Cohn, 2010) verwendet dafür folgendes Template:

Als <Benutzer / Rolle> möchte ich <ein Ziel> erreichen, damit <ein Nutzen> entsteht.

z.B.: Als Webshop-Kunde möchte ich Waren in einen virtuellen Warenkorb legen, damit ich diese zu einem späteren Zeitpunkt gesammelt betrachten kann.

Wer, Was, Warum möchte ist in dieser Form eindeutig und kompakt ausgedrückt. In der Praxis ist es daher sinnvoll sich an dieses Template zu halten um die drei W-Fragen zu beantworten. Viele Product Owner und Teams meinen jedoch eine noch bessere Variante gefunden zu haben um dies zu bewerkstelligen – meiner Erfahrung nach sind diese Abwandlungen jedoch meist entweder unvollständig in der Beantwortung der W-Fragen oder schlichtweg wesentlich länger in der Beschreibung und damit schlechter verständlich.

So weit, so einfach. Eine User Story soll aber neben der Kundenanforderung auch die notwendigen Details  für die Umsetzung enthalten. Dafür werden Akzeptanzkriterien definiert. Diese sollen Fragen über das Wie, Wann und Wohin beantworten. Sie sollen außerdem als Basis für automatisierte Testfälle dienen. Ich habe mir daher folgende Form bei der Definition von Akzeptanzkriterien angewöhnt:

  • Voraussetzung: Darin werden die notwendigen Vorbedingungen (z.B. Zustand der Software, aktueller Prozessschritt, Zustand der GUI,…) definiert.
  • Auslöser: Darin wird die Aktion (z.B. User Aktion, Eingehender Request, Triggern eines Events,…) beschrieben, die den Soll-Zustand triggert beschrieben.
  • Soll-Zustand: Beschreibt den vom Kunden gewünschten Soll-Zustand mit den notwendigen technischen Details.

Ein Akzeptanzkriterium für die oben definierte Webshop User Story könnte wie folgt aussehen:

  • Voraussetzung: Der Webshop-Kunde befindet sich auf der Produktseite XY und hat die Produktoptionen (Größe, Menge, Farbe) gewählt (siehe <Link zu Mockup 1>)
  • Auslöser: Der Webshop-Kunde klickt auf den Button “In den Warenkorb legen”
  • Soll-Zustand:
    • Der Kunde sieht den Warenkorb (siehe <Link zu Mockup 2>)
    • Das Produkt befindet sich mit den gewählten Optionen im Warenkorb (siehe <Link zu Mockup 3>)
    • Die Tabelle shopping_cart enthält die Produkte, die sich im Warenkorb befinden mit allen Optionen

In der Regel sind 5-10 Akzeptanzkriterien notwendig um das Verhalten der Software ausreichend zu beschreiben. Um den Kontext und die Details näher zu Beschreiben können Klassendiagramme, Systemarchitektur-Diagramme, Mockups, Screenshots, Sequenzdiagramme, Schnittstellendefinitionen, usw. verlinkt oder an die User Story angehängt werden. Ziel ist jedoch die User Story möglichst kompakt und übersichtlich zu halten um den Fokus zu bewahren. Im Zweifelsfall ist es besser eine große User Story in zwei kleine Stories aufzuteilen.

Quellen:

Mike Cohn (2010), Succeeding with Agile Software Development using Scrum, Addison-Wesley, Kap.13, S.239

Anforderungen schätzen – aber WIE?

Es gibt wohl kaum ein kontroverseres Thema in der agilen Softwareentwicklung als des Schätzen der Anforderungen. Diesen Eindruck habe ich jedenfalls, wenn ich täglich mit Product Ownern, Entwicklerteams und Scrum Mastern über die Methodik und die verwendeten Einheiten beim Schätzen diskutiere. Welche Einheit ist die beste? Sollen abstrakte Größen, wie Story Points, oder lieber absolute Größen, wie Stunden oder Personentage, für die Schätzung von Anforderungen verwendet werden? Ich habe das Gefühl, dass sich hier keine einheitliche Herangehensweise etabliert hat. Ein Blick in die Literatur zeigt auch hier keine einheitliche Meinung über die Einheit der Schätzungen:

Kent Beck sagt zum Schätzen in der 2. Auflage seines Buches “Extreme Programming Explained” folgendes:

“The first edition of Extreme Programming Explained had a more abstract estimation model, in which stories cost one, two, or three points. […] I prefer to work with real time estimated now, making all communication as clear, direct and transparent as possible.”

Boris Gloger vertritt in seinem Buch über Scrum die Meinung, dass nur eine Schätzung in abstrakten Größen (keinesfalls Zeiteinheiten) zum Schätzerfolg führt.

Mike Cohn legt sich in seinem Buch “Succeeding with Agile: Software Development Using Scrum” nicht genau fest und lässt die Entscheidung ob “Story Points” oder “Ideal Work Hours” verwendet werden bei den Teams.

Ken Schwaber und Mike Beedle unterstützen die Ansicht von zeitunabhängigen Schätzungen in ihrem Buch “Agile Development with Scrum“:

“Duration is not considered in Scrum. Work remaining and date are the only variables of interrest.”

Es sieht also fast so aus als ob hier jeder seinen eigenen Weg finden muss. Aber wo liegen die Vor- und Nachteile von konkreten bzw abstrakten Einheiten in der Praxis?

Vorteile Nachteile
Konkrete Einheiten (Personentage, Ideal Work Hours, Stunden,…)
  • Hohe Transparenz
  • Einfache Kommunikation des Aufwands
  • Kompatibilität zu traditionellen Methoden
  • Wenig Konflikte da bekannte Methode
  • Selbstbetrug durch festhalten an unrealistischen Schätzungen
  • Ungenaue Schätzungen selbst bei sehr erfahrenen Entwicklern
  • Steigerung der Velocity nicht feststellbar

 

Abstrakte Einheiten (Story Points, Kühe, Bäume,…)
  • Fokus auf Funktionalität, die dem Kunden einen Nutzen liefert
  • Genauere Schätzungen auch von unerfahrenen Entwicklern
  • Steigerung der Velocity feststellbar
  • Inkompatibilität mit Arbeitsweise anderer Abteilungen
  • Klärung was Einfluss auf die Größe der Schätzung hat ist oft schwierig (Funktionalität, Komplexität, Rahmenbedingungen,…)
  • Erhöhtes Konfliktpotential

Unabhängig welche Methode zur Anwendung kommt, sind Referenzen (z.B. Referenz User Stories) eine große Hilfe um vergleichbare Schätzungen über die Zeit und über Teams hinweg erzielen zu können. Neben der Einheit spielt auch die Schätz Methode eine wesentliche Rolle – also wie der eigentlich Prozess des Schätzens abläuft. Dazu aber in einem anderen Blogpost mehr.