5/2012

AGILES SCHÄTZEN IM TEAM:

VERFAHREN IN DER AGILEN

SOFTWAREENTWICKLUNG

siehe Abbildung 1). Wenn wir sowieso nichtgenau wissen, was auf uns zukommt, wiesodann nicht einfach würfeln?

Ich gebe zu: Diese Methode ist auch mirnicht wissenschaftlich genug. Schließlich istSoftwareentwicklung kein Glücksspiel.Aber haben wir denn Alternativen, die mitvertretbarem Aufwand einhergehen? Wiewäre es, wenn wir – statt zu würfeln – esetwas genauer versuchen und wenigstensdie geplanten Features relativ zueinandernach ihrer Komplexität bewerten? Das isteine Aussage, die dem Kunden sicher hilft:Wie teuer wird wohl welches Feature imVerhältnis zu einem anderen – ohne zu die-sem Zeitpunkt einen konkreten Euro-Betrag direkt schon nennen zu können.

Relatives Schätzen:Relationen herstellen„Dieses ist größer als jenes.“ Aussagen die-ser Art treffen wir im Alltag häufig, teil-weise auch, ohne konkrete Werte zu nen-nen. Die Übung in Kasten 1 soll ein solches

Mit Aufwandsschätzungen machen es sich Software-Entwicklungsteams zu Recht schwer: Der

Kunde will vorweg wissen, was ein neues Feature in seiner Software kostet. Selbst wenn wir

den genannten Betrag (Aufwand) explizit als Schätzung deklarieren, wissen wir doch, was pas-

sieren wird: Im Nachhinein nagelt uns der Kunde darauf fest. Das versucht man in der agilen

Softwareentwicklung zu umgehen und beschätzt deshalb keine Aufwände, sondern die

Komplexität eines Features in Relation zu den anderen. Dieser Artikel beschreibt, wie agile

Teams schnell zu solchen Schätzungen kommen.

m e h r z u m t h e m a :

infos.seibert-media.net/display/Websoftware/Agile+Vorhersagen

tierungs aufwand für die zu schätzendeFunktion? Was ist mit Designern, Testern,Systemadministratoren und Projekt -manage ment (bzw. Product Owner (PO)und ScrumMaster), die an der Realisierungauch in gewisser Weise beteiligt sind?

Unter dem Motto „Unsere Schätzungenmüssen besser werden“ investieren Projekt -manager und ihre Softwareentwickler teil-weise richtig viel Zeit und entwickeln kom-plizierte Schätzverfahren, um vermeintlichgenauere Schätzungen zu generieren. Sowerden Vergangenheitswerte betrachtet undRisikoaufschläge optimiert. Man diskutiert,wie hoch ein Projektmanage ment- undTestaufschlag sein müsste. Dabei ist die„genaue Schätzung“ doch ein Widerspruchin sich. Wenn wir es genauer wüssten, dannmüssten wir nicht schätzen. Ein Mitarbeitervon 1&1 hat auf die Frage nach derGenauigkeit einer Schätzung und demZeitaufwand, um sie zu erhalten, eine einfa-che und konsequente Antwort parat: denselbst gebastelten Schätzwürfel (vgl. [Sch],

Als Softwareentwickler wird man häufigmit der Frage konfrontiert: „Wie langebrauchst du dafür? Schätz doch mal!”Denn es ist ja ein durchaus verständlichesBedürfnis des Kunden oder Projektverant -wortlichen zu wissen, wann die neueFunktion endlich fertig ist (Zeitplanung)und was das Ganze eigentlich kosten soll(Aufwand bzw. Kosten). Der Software -entwickler steht nun aber vor einemDilemma: Er kann und will nicht genausagen, wie viele Stunden er noch benötigt,denn er vermag den exakten Verlauf seinerArbeit nicht zu prognostizieren. Klapptalles wie geplant? Gibt es Probleme mit die-ser geplanten SQL-Abfrage oder sieht dieWebseite im Internet Explorer am Endeauch wirklich genauso aus wie in Firefox& Co.? Er kann nicht alle Eventualitätenabsehen bzw. einkalkulieren.

Nun könnte der Kunde anregen: „Erkann doch eine Dreipunktschätzung abge-ben und mir den mindesten, maximalenund den erwarteten Aufwand mitteilen.”Damit hat sicher jeder schon mal gearbei-tet. Dennoch: Abgesehen davon, dass zwi-schen den genannten Minimal- undMaximal angaben manchmal Welten liegen,gibt es auch keine Garantie dafür, dass derHöchstbetrag nicht überschritten wird. Esist eben am Ende doch nur eine Schätzung. Wenn also Schätzungen letztlich sehr unge-nau ausfallen, stellen sich folgende Fragen:Wie viel wollen wir in eine Vorabschätzungder Aufwände investieren? Soll derEntwickler sich richtig viel Zeit nehmenund versuchen, jedes geplante Feature aufdie einzelnen umzusetzenden Bestandteileherunterzubrechen? Kann er das vorabüberhaupt? Welche Aufwände müssendenn eigentlich in der Schätzung berück -sichtigt werden? Nur der Implemen -

schwerpunk t

Joachim Seibert

(jseibert@seibert-media.net)

ist CTO und Geschäftsführer der //SEIBERT/

MEDIA GmbH aus Wiesbaden. Als überzeugter

Verfechter agiler Methodik und zertifizierter Scrum

Professional hat er es sich zur Aufgabe gemacht,

Teams und Unternehmen agiler zu machen.

der au tor

Abb. 1: Der selbst gebastelte Schätzwürfel.

48 49

schwerpunk t

Alltagsbeispiel aufzeigen. Als Software -entwickler schätzen wir nun natürlich nichtso triviale Dinge wie die Größen vonLändern, die man am Ende ja auch(Wikipedia sei Dank) einfach nachschlagenkann. Teilweise wünscht sich der Kunde fürseine Software relativ große neue Features,deren einzelne Facetten im Vorfeld garnicht absehbar sind, geschweige denn dienotwendigen Arbeitsschritte. Wie lange wirdaran sitzen, welchen Aufwand diesesFeature also produziert, können wir zu die-sem Zeitpunkt nicht sagen. Die Frage, wiekomplex eine Anforderung im Verhältniszu einer anderen ist, können wir allerdingsbeantworten.

Komplex bedeutet dabei erst einmalnicht, dass die Umsetzung besonders zeitin-tensiv und mit großem Aufwand verbun-den ist. Komplexität ist vielschichtiger.Beispiele könnten sein:

n Es gibt einen komplizierten Ablauf(Workflow), der durchschritten werdensoll.

n Es sind viele Bereiche der Softwarebetroffen.

n Es sind sehr viele Änderungen vorzu-nehmen.

n Es sind viele Personen involviert.

Wenn uns der Kunde eine Liste mit ge -wünschten Features vorlegt, könnten wiralso versuchen, diese (genau wie bei demLänder-Beispiel in Kasten 1) nach ihrerKomplexität zu ordnen und in einem zwei-ten Schritt die Relationen zu beschätzen.

Fibonacci-SchätzskalaSobald wir Verhältnisse schätzen, stellt sichdie Frage der Skala. Beim Beschätzen derLänder haben wir gelernt, dass dieBeschätzungen ungenauer werden, wenndie Dinge größer sind. Das sollte unsereSkala berücksichtigen.

Eine Zahlenfolge, die die Eigenschaftmitbringt, nach oben immer größereAbstände zu haben, ist die Fibonacci-Folge:1, 2, 3, 5, 8, 13, 21, 34, 55, 89, … Daranangelehnt, hat sich die heute in der agilenWelt etablierte Skala entwickelt, die zurBeschätzung herangezogen wird: 1, 2, 3, 5,8, 13, 20, 40, 100. Die wichtigste Eigen -schaft dieser Zahlenfolge: Je größer dieZahl ist, desto größer ist der Abstand zurletzten – also genau das, was wir vorhinfestgestellt haben: Je größer die Schätzungist, desto ungenauer wird sie.

Die Crux der Story-PointsDie Zahlen bzw. Größen der Verhält nis -angaben werden in der agilen Welt häufig

Story-Points (von User-Story) oder Kom p -lexitätspunkte genannt. Das hat sich eta-bliert, ist aber eigentlich missverständlich,denn es impliziert eine Werteinheit undeben kein Verhältnis mehr. Daraus entstehtdann häufig das Missverständnis, mankönne doch gleich in Personentagenbeschätzen bzw. direkt umrechnen, in derArt: „Ein Story-Point entspricht bei unsfünf Personentagen.”

Natürlich sind Umrechnungen vonKomp lexität in Aufwand in gewissen Maßenotwendig – schließlich möchte der Kundeabschätzen können, wie weit er denGeldbeutel für ein Feature aufmachen muss.Allerdings ist eine Umrechnung vonKomplexitätsverhältnissen in Aufwandnicht trivial. Dazu später mehr.

Das Team schätztWichtig in agilen Softwareprojekten ist dieAutonomie bzw. die Selbstorganisation desTeams. Diese ist nur dann gewährleistet,wenn Entscheidungen auch im Teamgetroffen werden. Dazu zählt unter ande-rem auch die Aufwandsschätzung, anson-sten steckt gerade in diesen Schätzungenimmer wieder Konfliktpotenzial: Einzelnefühlen sich oder vielmehr ihre Bedenkenbezüglich der Beschätzung nicht berück -sichtigt. „Habe ich doch gleich gewusst,dass diese Schätzung unrealistisch ist“, isteine typische Aussage von Entwicklern, diesich mit Schätzungen konfrontiert sehen,an denen sie nicht beteiligt waren.

Es schätzt also das Team. Das Manage -ment erwidert daraufhin häufig: „Das istaber unheimlich teuer. Die verbringen dochauch so schon genug Zeit in Meetings.”Noch ein Grund mehr, warum wirVerfahren brauchen, um möglichst schnellzu einer Schätzung zu kommen. Neben dergerade angeführten Akzeptanz sei diesemManager als weiteres Argument genannt,dass es sehr wichtig ist, dass das Team sichfrühzeitig mit den Anforderungen beschäf-tigt, damit alle wissen, was auf sie zu -kommt.

Teams in agilen Projekten sind optima-lerweise cross-functional besetzt. NebenSoft wareentwicklern gehören auch Desig -ner, Tester, Systemadministratoren (aufneudeutsch: DevOps) zum Team. Wennwir nun also keine Aufwände schätzen,sondern auf relative Komplexitätsab schät -zungen hinarbeiten, hat das den großenVorteil, dass alle im Team aktiv an dieserSchätzung teilnehmen können und so eine

Was ist relatives Schätzen? Dazu ein Alltagsbeispiel fernab der Softwareentwicklung:Mich fragt jemand, ob ich denn wisse, wie groß die Fläche folgenden Länder inQuadratkilometern ist: USA, Deutschland (DE), Schweiz (CH) und Frankreich (FR).Kurz gesagt: Ich habe keine Ahnung, Wikipedia weiß es sicher – ich nicht. Allerdingskann ich auf jeden Fall sagen, welches Land flächenmäßig größer als das andere ist. Ichkann also eine Größen-Reihenfolge herstellen: CH < DE < FR < USA.Wenn es noch etwas genauer sein soll, kann ich zusätzlich versuchen, die Größenrelationder Länder in Zahlenwerten zu schätzen: CH: 1 < DE: 5 < FR: 8 < USA: 100.Eine Recherche bei Wikipedia ergibt nun: CH: 41 Tkm² < DE: 357 Tkm² < FR: 547Tkm² < USA: 9.809 Tkm².In Verhältnisangaben übersetzt, heißt das: CH: 0,6 < DE: 5 < FR: 7,7 < USA: 137

Gar nicht schlecht getroffen, oder? Wie ist diese Schätzung zustande gekommen?1. Zuallererst wird ein Referenzwert gesucht, den man gut kennt und abschätzen kann.

In diesem Fall ist das für mich natürlich Deutschland. 2. Für diese Referenzgröße wird nun (scheinbar) willkürlich ein Referenzwert vergeben,

hier z. B. der Wert 5.3. Davon ausgehend, werden die anderen Länder bzw. deren relatives Verhältnis zu -

einander geschätzt. Das fällt leicht bei Dingen mit ähnlicher Größe, hier CH, DE, FR.4. Bei verhältnismäßig großen Dingen fällt uns die Beschätzung allerdings schwer und

wird ungenau, wie das Beispiel USA zeigt.

Kasten 1: Relatives Schätzen: ein Alltagsbeispiel.

5/2012

schwerpunk t

das „Pokern um Aufwände“. Deshalb seidieses Verfahren zuerst genannt. DieRegeln des Planungspoker sind in Kasten 2beschrieben.

Der größte Vorteil dieses Verfahrens be -steht darin, dass jedes Teammitglied seineSchätzung völlig unbeeinflusst abgibt – jedenfalls theoretisch. Allerdings zeigt diePraxis, dass es mit der unbeeinflusstenBeschätzung nicht immer so weit her ist. Beider Vorab-Befragung des PO kommt es hinund wieder zu Kommentaren der Mitspielerwie, „Puh, das ist aufwändig” oder umge-kehrt „Das ist ja einfach”, was einen dannnatürlich in der persönlichen Beschätzungbeeinflusst. Hier ist der ScrumMastergefragt, solche Dinge möglichst zu unter-binden. Zusätzlich ist die gemeinsameDefinition einer festen Time box wichtig –sonst kann es (vor allem bei Verwendungder ausführlichen Variante des Pokerns, sie-he Kasten 2) unter Um ständen recht langedauern, bis ein gemeinsames Ergebniserreicht ist.

Einen großen Nachteil sehe ich außer-dem darin, dass man hier nicht erst miteiner Reihenfolge (Sortierung) arbeitet, wiewir es natürlicherweise (ohne feste Regeln)tun würden (siehe nochmals das Beispiel inKasten 1). Dadurch fällt es den Teilneh -mern schwerer, das gerade zu schätzendeFeature im Hinblick auf die Gesamtheit derAnforderungen einzusortieren.

Anforderungskartenspiel:Das Estimation GameDas Estimation Game (vgl. [Röp09])erinnert in Sachen Ablauf und Regeln tat-sächlich an ein Kartenspiel wie Romméoder Mau-Mau. Es folgt diesen Spielregeln:

n User-Storys auf Karten mitbringen: DerPO bringt seine Features (User-Storys)als Kartenstapel mit zur Beschätzung.

n Reihenfolge herstellen: Das erste Zielbesteht darin, auf dem Tisch eineReihenfolge der Karten nach aufstei-

GrundregelnAlle Verfahren sehen vor, dass derjenige,der die Anforderungen stellt (in Scrum bei-spielsweise der PO), sowie das kompletteEntwicklungsteam anwesend sind. DieAnforderungen sollten stets in Papierform(Karten) vorliegen – die Handhabung vonPapier aktiviert und involviert die Teil -nehmer viel stärker als eine Beamer-Präsentation.

Darüber hinaus ist es auch möglich, demAntragssteller eine Anforderung ohneAbgabe einer Schätzung als nicht schätzbarzurückzugeben. In diesem Fall ist dieAnforderung in modifizierter Form erneutvorzulegen. Schätzungen werden immerdann – und nur dann – aktualisiert, wennsich die fachlichen Anforderungen ändern.Das sollte im Laufe des Projekts immer derFall sein, da häufig ungenaue Initialan -forderungen für die Umsetzung konkreti-siert werden müssen.

Der Klassiker: PlanungspokerJeder, der schon ein bisschen mit agilerSoftwareentwicklung zu tun hat, kennt es,

tatsächliche Teamschätzung erreicht wird.Eine typische Aussage, wie „Ich weiß dochnicht, wie lange du für die Implemen -tierung brauchst“, ist somit obsolet.

Wie können wir aber sicherstellen, dassdas Team sich in diesen Anforderungs -workshops (in Scrum auch häufig Backlog-Grooming oder auch explizit EstimationMeeting genannt) nicht in ellenlangeDetaildiskussionen verstrickt, sondern die-se Treffen so kurz und effizient wie nurmöglich gestaltet? Dazu wäre eine festeVorgehensweise sinnvoll, um möglichstrasch und reibungslos zur oben erläutertenKomplexitätsabschätzung (bzw. -relation)zu kommen.

Agile SchätzverfahrenIn der agilen Softwareentwicklung habensich Verfahren etabliert, die gerade bei derBeschätzung im Team helfen, einen schnel-len Schätzvorgang zu gewährleisten. All die-se Verfahren haben zum Ziel, mit möglichstwenig Aufwand eine relative Komp -lexitätsschätzung zu erreichen. Als Schätz -skala hat sich hier die oben angesprocheneabgewandelte Fibonacci-Folge durchgesetzt.

Im Folgenden beschreibe ich drei von mirausgewählte Verfahren, die unter agilenTeams verbreitet sind und die in unserenagilen Softwareentwicklungsteams bei//SEIBERT/MEDIA ebenfalls Anwendungfinden. Dabei erläutere ich jeweils, wie wirselbst diese Verfahren einsetzen. VonUnternehmen zu Unternehmen und vonTeam zu Team kann es durchaus Unter -schiede im praktischen Einsatz geben.

n Jedes Teammitglied erhält einen Satz Karten, auf denen die Zahlen der abgewandel-ten Fibonacci-Folge stehen.

n Häufig gibt es zusätzliche Karten wie „?”, „Unendlich” oder „Kaffeepause”, um denTeilnehmern die Möglichkeit zu geben, mit den Karten ihre Bedürfnisse nach einergenaueren Erklärung oder einer Meetingpause zu visualisieren.

n Der PO stellt die erste Anforderung vor und beantwortet Fragen des Teams.n Der ScrumMaster fragt das Team, ob es bereit zum Pokern ist, und auf „Drei, zwei,

eins!” zeigt jeder Teilnehmer die von ihm ausgewählte Karte.n Nun erklären sich derjenige mit der höchsten Schätzung und derjenige mit der nie-

drigsten gegenseitig, warum sie entsprechend geschätzt haben.n Es erfolgt eine zweite Pokerrunde. Die kurze Variante: Nach der zweiten Runde wird

stets die größte genannte Schätzung verwendet. Liegen die Schätzungen allerdingsweiterhin sehr weit auseinander, sollte die Story zuerst „zwischengeparkt“ und amEnde erneut betrachtet werden.

n Die ausführlichere Variante: Es werden so viele Pokerrunden durchgeführt, bis alledie gleiche Schätzung abgegeben haben.

Kasten 2: Planungspoker-Spielregeln.

OBJEKTspektrum ist eine Fachpublikation des Verlags:

SIGS DATACOM GmbH · Lindlaustraße 2c · 53842 TroisdorfTel.: 0 22 41 / 23 41-100 · Fax: 0 22 41 / 23 41-199 E-mail: info@sigs-datacom.dewww.objektspektrum.dewww.sigs.de/publications/aboservice.htm

50 51

schwerpunk t

gender Komplexität zu erzeugen (sieheAbbildung 2): Ganz unten in der Folgeliegt die einfachste, ganz oben die kom-plexeste. Das Team muss sich nun eini-gen, wo „oben” und wo „unten” ist.

n Das Team spielt: Die Teammitgliedersind nun reihum am Zug. Jeder Spielermacht einen von zwei möglichenZügen: Der Spieler zieht eine Kartevom Stapel, liest diese vor und stelltdem PO Verständnisfragen. Daraufhinlegt er sie an eine von ihm gewählteStelle innerhalb der Reihenfolge ab.Oder der Spieler verschiebt mit einerkurzen Begründung (ein Satz) einebereits auf dem Tisch liegende Karte aneine andere Stelle in der Reihenfolge.

n Herumwandernde Karten: Wanderteine Karte in der Reihenfolge hin undher, muss der PO sie aus dem Spiel neh-

men. Offenbar ist die Anforderungnicht exakt genug beschrieben und esbesteht Uneinigkeit im Team, welchenInhalt das Feature genau hat.

Ist die Reihenfolge hergestellt, geht es imnächsten Schritt darum, Größenverhält nissezu beschreiben, diese Reihenfolge also umStory-Point-Beschätzungen zu ergänzen:

n Referenz definieren: Das Team musszuerst ein Referenz-Story mittlerer Größe(ca. in der Mitte der gefundenen Reihen -folge) auswählen, die es einigermaßen gutüberblicken kann (Beispiel: Deutsch landbei der Beschätzung der Ländergrößen).

n Referenz beschätzen: Für die gewählteReferenz muss nun eine Beschätzungabgegeben werden. Das kann entwederohne spezielles Verfahren durch Kon -sens im Team oder auch durch eineschnelle Pokerrunde erfolgen. SinnvolleWerte aus der Praxis liegen zwischendrei und fünf Story-Points.

n Referenz beibehalten: Ist das Referenz-Feature einmal gewählt und beschätzt,muss es bei folgenden Schätzmeetingsstets als Referenz herhalten und sollteimmer mit in die Reihenfolge (ersterSchritt) einsortiert werden – und zwarunabhängig davon, ob es bereits reali-siert wurde oder nicht.

n Skala ergänzen: Nun durchläuft man dieReihenfolge, vom Referenz-Feature aus-gehend, erst nach unten (kleiner) undfragt das Team, ab wann die nächs teStufe in der Skala erreicht wird (Entschei -dung im Konsens). Ebenso verfährt mananschließend in die Gegenrichtung.

Dieses Verfahren kommt in unseren Ent -wicklungsteams sehr oft zur Anwendung.Das Herstellen einer Komplexitäts -reihenfolge aller vorgelegten Feature-Wünsche fällt den Teams erfahrungsgemäßhäufig leichter, als jede Story wie beimPoker einzeln zu bewerten.Ohne Worte schneller schätzenAls drittes Verfahren soll die magischeBeschätzung (Magic Estimation, vgl.[Cam10], siehe Abbildung 3) angeführtwerden, die ursprünglich von Boris Glogervorgestellt wurde. Die Spielregeln zu die-sem Verfahren sind in Kasten 3 nachzule-sen. Boris Gloger erklärt die Methode aus-führlich in einem YouTube-Video (vgl.[Glo11]).

Der wesentliche Vorteil dieser Methodebesteht darin, dass sich in kürzester Zeiteine große Menge an Anforderungenbeschätzen lässt. Somit ist dieses Verfahrenideal dazu geeignet, auch für großeProjekte bzw. lange Feature-Listen eineschnelle Initialschätzung mit minimalemZeitaufwand zu erhalten. Zwar stellt sichin der Praxis heraus, dass es den Teamsschwer fällt, komplett ohne zu sprechen zuagieren (wir tendieren eben dazu, unserklären zu wollen). Haben sich Teamsaber an dieses Verfahren gewöhnt, könnensie selbst mit knapp gewählten Timeboxesein gemeinsames Ergebnis finden, mit demam Ende alle einverstanden sind.

Von der Komplexitätzum AufwandIn der Regel reicht dem Kunden eineKomplexitätsangabe, wie oben beschrie-ben, nicht aus – Story-Points sind zuabstrakt. Er will eine Aufwandsschätzunghaben („Ich muss doch ein festes Budgetbeantragen”).

n Die Fibonacci-Folge wird auf dem Tisch (oder auf dem Boden, wenn der Tisch nichtgroß genug ist) ausgelegt (z. B. mit einem Satz Pokerkarten). Dabei sind die immergrößer werdenden Abstände zwischen den Werten zu berücksichtigen (mehr Abstandzwischen den Werten 5 und 8 als zwischen 2 und 3).

n Der PO breitet seine Karten mit den Anforderungen auf dem Tisch aus.n Das Team fängt an, die Karten innerhalb der Schätzskala zu verteilen. Dabei darf

weder gesprochen, noch nonverbal per Gestik und Mimik kommuniziert werden.n Ein Teammitglied darf jederzeit eine bereits zugeordnete Karte erneut verschieben.n Wandert eine Karte ständig hin und her (Nervous Nelly), muss der PO sie aus dem

Spiel nehmen, um sie nachträglich zu diskutieren.

Kasten 3: Magic-Estimation-Spielregeln.

Abb. 2: Estimation Game: eineReihenfolge erzeugen.

5/2012

schwerpunk t

Bei bestehenden Teams und laufendenProjekten, die praxiserprobt sind, kanneine Umrechnung anhand von Erfahrungs -werten erfolgen. Über die Velocity („Wieviele Story-Points schafft mein Team durch-schnittlich pro Sprint?“) lässt sich errech-nen, was ein Story-Point zum aktuellenZeitpunkt kostet. In der Scrum-Praxisbedeutet das, mindestens drei Sprints langErfahrungswerte zu sammeln, die man zurUmrechnung heranziehen kann. Zu beach-ten ist, dass der Wert eines Story-Point ausdiversen Gründen durchaus während desProjektverlaufs schwanken kann. Nachjedem Sprint sollte dieser Wert deshalberneut ermittelt werden.

Gibt es dagegen keine Werte aus derPraxis, was etwa zu Beginn eines Projektsder Fall ist, ist eine Umrechnung vonKomplexität in Aufwand noch schwieriger.

Eine erste grobe Schätzung kann dadurcherreicht werden, dass das Team einen sogenannten Task-Breakdown (Definitionder Realisierungsschritte mit Schätzung derjeweiligen Umsetzungszeit) nur für das ver-meintlich gut bekannte Referenz-Feature(siehe Estimation Game) macht und dannden Aufwand für die anderen Anfor -derungen entsprechend über das Verhältnisumrechnet. Natürlich handelt es sich hier-

bei um einen instabilen, nicht belastbarenWert – nicht mehr als eine initiale Haus -nummer.

FazitEine relative Komplexitätsbeschätzung istsinnvoll. Vorab schon alle Eventualitätenund Schritte der Umsetzung zu kennen, istsehr aufwändig bzw. meistens sogarunmöglich. Nimmt man diese Unsicherheitals gegebene Voraussetzung hin, ist eineschnellere Beschätzung über die Verhält -nisse der Features untereinander möglich.

Da die Beschätzung in agilen Projektenimmer eine Teamleistung sein sollte, ist esempfehlenswert, stets dieselben Schätzver -fah ren einzusetzen, um den nötigen Zeit -aufwand zu minimieren. Ich empfehle agi-len Teams, für ihre Schätzungen dasEstimation Game auszuprobieren. DieseMethode hat eine hohe Akzeptanz, weil siesich natürliche, alltägliche Vorgehens -weisen bei der Bildung von Reihenfolgenzunutze macht. Gerade in Sprint-Planning-Meetings (bzw. beim Backlog Grooming),in denen ausschließlich die neuen Anfor -derungen im laufenden Projekt (im Schnittweniger als zehn) zu beschätzen sind, füh-ren geübte Teams mithilfe des EstimationGames in wenigen Minuten eine Story-Point-Beschätzung durch. Nur wenn größe-re neue Projekte anstehen und viele Storyszu beschätzen sind, setzen wir Verfahrenwie Magic Estimation ein, um noch mehrZeit zu sparen. n

Links

[Cam10] D. Campey, Magic Estimation, 2010, siehe:

campey.blogspot.com/2010/09/magic-estimation.html

[Glo11] B. Gloger, Magic Estimation, 2011, siehe: youtube.com/watch?v=QocEro1J65Y

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

[Sch] S. Schmidt, Aufwand schätzen, ohne Aufwand zu haben, siehe: blog.schst.net/2010/06/planning-dice/

Abb. 3: Magic Estimation: Stille Beschätzung.