Die Grundlage für die Definition von Personas bilden alle Informationen über die zukünftigen Benutzer des Systems, die die Projektbeteiligten auf verschiedenen Wegen sammeln, beispielsweise

• über Workshops mit Benutzern,
• mit Hilfe von Fragebögen oder
• durch Beobachtungen, welche Nutzer wie mit ihrem aktuellen oder einem vergleichbaren System arbeiten.

Die ermittelten Personas begleiten das gesamte Projekt von der Anforderungsermittlung bis hin zur Implementierung und Wartung. Designer, Architekten und Entwickler sehen sich dadurch nicht mehr mit einer abstrakten Masse von anonymen Nutzern konfrontiert, sondern können auf die einzelnen Bedürfnisse konkreter Nutzer eingehen und dementsprechend unterschiedliche Bedienungsszenarien durchspielen.

Zum Seitenanfang

Vorteile der Arbeit mit Personas

Personas bringen Leben in jedes Projekt, allein das ist ein nicht zu unterschätzender Vorteil. Einige weitere nennt Martin Seibert im Artikel Personas geben Zielgruppen Gesichter:

• Personas helfen allen Projektbeteiligten dabei, den gesamten Entwicklungsprozess auf die Bedürfnisse ihrer Nutzer und Zielgruppen auszurichten anstatt sich zur sehr auf die Ziele und (unrealistische) Vorgaben der Projektentscheider oder auf technische Restriktionen zu konzentrieren.
• Entwickler spielen Bedienungsszenarien nicht aus ihrer Sicht durch: »Wie würde ich vorgehen, um den Bericht auszudrucken?«. Stattdessen betrachten sie sie aus verschiedenen Blickwinkeln: »Wie würde Walter vorgehen, um den Bericht auszudrucken? Würde Nicolai das genauso machen? Was würde Matthias erwarten?«
• Persona helfen dabei, Wünsche von tatsächlichen Anforderungen zu unterscheiden. Als Wünsche bezeichne ich Anforderungen an das Produkt, die Stakeholder in das Projekt einbringen, dabei aber keinen Mehrwert bringen. Dazu gehören beispielsweise bestimmte Funktionen, die später überhaupt nicht genutzt werden, oder Designentscheidungen, die die Usability des Produkts verschlechtern anstatt sie zu verbessern. Die konsequente Anwendung von Persona in jeder Phase der Entwicklung kann nutzlose Wünsche aufdecken.
• Entwickler haben konkrete Bezugspersonen, die ihrer Arbeit einen Sinn geben und mit denen sie sich identifizieren können. Dadurch steigt die Identifikation mit dem Projekt insgesamt, was wiederum die Motivation erhöht. Dabei sollten alle Personas, mit denen die Projektbeteiligte sich identifizieren sollen, sympathisch beschrieben sein. Sonst entwickeln sich kontraproduktive Dialoge: »Wie würde Matthias vorgehen, um den Bericht auszudrucken?« – »Keine Ahnung, ist mir doch egal, was Matthias macht.«
• Persona verstehen alle Beteiligte: Projektmanager, Designer, Entwickler und sogar das Top-Management können sich in Persona hineinversetzen und deren Bedürfnisse verstehen.
• Persona können dabei helfen, Anforderungen zu priorisieren, indem zunächst die Anforderungen berücksichtigt werden, die sich auf Personas beziehen, die wichtiger sind als andere.

Zum Seitenanfang

Personas ausführlich definieren

Natürlich kann nur dann ein gebrauchstaugliches Produkt entstehen, das alle Anforderungen erfüllt, wenn die Persona gut ausgewählt und beschrieben wurden und die Nutzergruppe, die sie repräsentieren, möglichst realistisch und präzise abbilden. Nur dann sind alle Beteiligten in der Lage, die Anforderungen an das System vollständig zu erfassen und bei der Entwicklung zu berücksichtigen.

Eine vollständige Personabeschreibung sollte mindestens folgende Angaben und Informationen umfassen:

• Persönliche Angaben, darunter der vollständige Name, das Geschlecht und Alter.
• Ein Foto der Persona. Das ist besonders wichtig, um sich – im wahrsten Sinne des Wortes – ein Bild der Persona machen zu können.
• Angaben zu Beruf, Funktion, Verantwortlichkeiten und Aufgaben. Um zu erfahren, was diese Persona mit Ihrem System tut, müssen Sie wissen, was sie eigentlich tut.
• Fachliche Ausbildung, Wissen und Fähigkeiten, sofern sie für das Produkt von Interesse sind. Dazu gehören allgemeine Computerkenntnisse und IT-Know-how (Internet, Textverarbeitung etc.) sowie Kenntnisse über verwandte Produkte, Vorgängersysteme, Konkurrenzprodukte. Hier entscheidet sich, ob Ihre Nutzer IT-Experten sind, die sich darüber hinaus in der Produktdomäne hervorragend auskennen, oder Anfänger, die Sie behutsam an Ihr System heranführen müssen.
• Das führt uns direkt zu den Erwartungen, die die Persona an das System stellt und die sich direkt in Anforderungen übersetzen lassen.
• Typische Verhaltensmuster und Vorgehensweisen lassen Rückschlüsse zu, wie die Persona in bestimmten Situationen reagiert. Das macht es leichter, die richtige Nutzeransprache zu finden, um die Arbeit mit dem System effizienter zu machen.

Zum Seitenanfang

Gute Personas entwickeln sich ständig weiter

Der Usability-Experte Jared M. Spool schildert in seinem Artikel Das Wesentliche an einem erfolgreichen Persona-Projekt seine Beobachtung, dass die meisten Projekte sehr einfach anfangen: Projektteams tragen einfach das Wissen zusammen, das ihnen vorliegt, und entwickeln die Personas aus eigenen Erfahrungen heraus. Erst in einem zweiten Schritt untermauern die Teams ihre Annahmen durch Fakten, indem sie sich mit realen Nutzern und deren Aufgaben beschäftigen, Nutzertests und Feldstudien durchführen. Die Persona werden entsprechend angepasst und verfeinert. Das geschieht regelmäßig immer dann, wenn neue Kenntnisse hinzugekommen sind. So bleiben die Persona lebendig und entwickeln sich ständig weiter so wie echte Menschen es auch tun.

Es ist wichtig, dass alle Projektbeteiligte die Personas voll verinnerlicht haben, ganz gleich, ob die Personas durch die Kreativität und Erfahrungen des gesamten Projektteam entstehen oder nur durch die Arbeit einer kleineren Gruppe, beispielsweise der Interaktionsdesigner. Jeder muss alle Persona so beschreiben können, als seien es echte Menschen, so gut bekannt wie Familienmitglieder oder enge Freunde. Dazu Spool:

»Es gibt einen einfachen Test, um Erfolg oder Misserfolg eines Persona-Projekts vorherzusagen: Sprechen Sie mit allen Team-Mitgliedern, den Geschäftsführern und allen Entscheidern und fragen Sie nach den wichtigsten Personas. Wenn Ihnen alle das Gleiche erzählen, haben Sie es mit einem Siegerprojekt zu tun.«

Mehrarbeit ist eine Möglichkeit, kurzfristige Termine einzuhalten, etwa die Präsentation in der nächsten Woche, aber keine Lösung langfristiger Probleme. Wochen- oder monatelange Mehrarbeit verschafft nur vordergründig Luft; langfristig führt der Verzicht auf Privatleben und die dauerhafte Überbelastung zu Unzufriedenheit, Erschöpfung und Burnout-Gefühlen, die den kurzfristigen Zeitgewinn langfristig wieder zunichte machen: Die Arbeitsleistung sinkt unterm Strich unter 100%.

Übrigens ist auch der Verzicht auf Qualität eine Sackgasse. Entwickler sind zu vielen Kompromissen bereit, aber wer ständig nach dem Motto »Es ist das gut genug, was Auftraggeber und Anwender gerade eben noch schlucken« arbeiten muss, der wird irgendwann feststellen, dass er seine eigenen Qualitätsansprüche verraten hat. Vor allem für die Leistungsträger ist das häufig Grund, sich nach einem anderen Arbeitgeber umzusehen.

Wenn der Verlauf eines Projekts nicht dessen Planung entspricht, liegt das häufig daran, dass die Realität sich einer genauen Schätzung entzieht. Dieser Artikel zeigt, wie Sie dennoch zu guten Schätzungen gelangen, und betrachtet sowohl klassische Schätzverfahren als auch moderne Verfahren in agilen Projekten.

Zum Seitenanfang

Aufwandschätzung für Entwickler

Im Alltag spricht man von einer Schätzung, wenn eine intuitive Zahlenangabe oder Bewertung einer messbaren oder zählbaren Größe auf raschem Wege nach dem Augenschein, mit Intuition oder mittels Erfahrung bestimmt wird.

Beispiele für Alltagsschätzungen sind:

• Ich schätze, da fehlen noch drei Teelöffel Zucker.
• Wir müssen noch etwa 10 km fahren.
• Es sind schätzungsweise 150 Personen anwesend.
• Der Film müsste in einer Viertelstunde zu Ende sein.

Aus Sicht des Projektmanagements sind dies keine zulässigen Schätzungen.

Eine Schätzung ist stets ein Näherungswert, der mit einer bestimmten Wahrscheinlichkeit in einem bestimmten Bereich liegt.

Zulässige Schätzungen sind:

• Mit einer Wahrscheinlichkeit von über 70 % bleiben wir unter 3 Tagen.
• Wir brauchen bestenfalls 2 Tage, schlimmstenfalls 4 Tage.
• Mit einer Wahrscheinlichkeit von 80 % brauchen wir 5 plusminus einen halben Tag.

Die Herausforderungen, mit denen ein Schätzer zu tun hat, ähneln jenen, denen sich ein Pokerspieler stellen muss: Basierend auf unvollständigen Informationen, Annahmen und Wahrscheinlichkeiten müssen Entscheidungen getroffen werden, bei denen viel Geld auf dem Spiel stehen kann.

Der Cone of Uncertainty (siehe Abb. 1) beschreibt den Verlauf von Unsicherheiten in einem Projekt: Eine Schätzung, die zu Beginn eines Projekts vorgenommen wird, also noch vor der Anforderungsphase, ist im Durchschnitt mit einer Unsicherheit von Faktor 4 belastet. So kann die tatsächlich benötigte Zeit eines Projekts vier Mal so lang oder auch nur ein Viertel so lang sein wie zu diesem Zeitpunkt geschätzt. Die Unsicherheit nimmt im Projektverlauf zwar stetig ab, aber bis zum Ende des Projekts bleibt eine gewisse Unsicherheit bestehen.

Abb. 1: Cone of Uncertainty

Es bietet sich der Vergleich zum Verlauf einer Pokerhand an, bei der die Informationsmenge mit dem Aufdecken der Gemeinschaftskarten sowie dem Spielverhalten der Mitspieler zunimmt, aber erst beim Showdown Gewissheit vorherrscht; wobei der Spieler bereits zu Beginn Einschätzungen treffen muss, die er im Verlauf der Hand ständig überdenkt und neu bewertet.

Ähnlich wie Pokerspieler, die ihre eigenen Chancen, eine Hand zu gewinnen, zu hoch einschätzen oder deren Hoffnung größer ist als die objektive Wahrscheinlichkeit, scheitern viele Schätzer an ihrem eigenen Optimismus. Die Praxis zeigt nämlich: Die meisten Entwickler schätzen den zu erwartenden Aufwand um bis zu 30 % zu optimistisch ein. Was dann dabei heraus kommt, liegt auf der Hand: Der Kunde freut sich über das günstige Angebot und der Entwickler hat es mit einem unrealistischen Projektplan zu tun.

Eine dritte Parallele lässt sich ziehen: Pokerspieler können versteckte »Monsterhände« so schnell übersehen wie Schätzer verstecke Aufwände. Beim Pokern sind dies unauffällige Drillinge oder Straßen in der Hand des Gegners, die die eigene Hand beim Showdown alt aussehen lassen; bei der Aufwandschätzung Aktivitäten wie Dokumentation oder Meetings. Denken Sie daran: Gespräche und Abstimmungen mit dem Kunden oder dem Team untereinander kosten ebenfalls Zeit. Ein zweistündiges Meeting mit vier Personen entspricht einem Personentag! Über die gesamte Projektlaufzeit betrachtet kann da einiges an versteckten Aufwänden zusammenkommen.

Zum Seitenanfang

Das Gesetz der großen Zahlen

Das Gesetz der großen Zahlen ist ein mathematischer Satz aus der Stochastik und besagt, dass sich die relative Häufigkeit eines Zufallsergebnisses der Wahrscheinlichkeit dieses Zufallsergebnisses annähert, wenn das zu Grunde liegende Zufallsexperiment immer wieder durchgeführt wird.

Bei einem Münzwurf beträgt die Wahrscheinlichkeit für Kopf 50 %. Dies bedeutet jedoch nicht, dass bei zehn Würfen fünf Mal Kopf fallen muss, sondern lediglich, dass die Wahrscheinlichkeit dafür recht hoch ist. Tatsächlich könnte auch acht Mal Zahl und nur zwei Mal Kopf fallen. Das Gesetz besagt lediglich, dass sich die Quote für Kopf bei hinreichend vielen Würfen 50 % annähert.

Es ist gewagt zu behaupten, dass Einzelschätzungen Zufallsergebnisse sind. Andererseits haben wir bereits gesehen, dass Sie mit sehr hoher Wahrscheinlichkeit komplett daneben liegen, wenn Sie einen Aufwand aus dem Bauch heraus schätzen, und auch dann, wenn Sie gewissenhaft schätzen, kann der tatsächliche Aufwand deutlich höher oder niedriger liegen.

Aus diesem Grund sollten Sie eine Aufgabe in Unteraufgaben unterteilen. Das setzt voraus, dass Sie sich bereits Gedanken zur Problemlösung machen, also Informationen sammeln, die Ihre Schätzung verbessert. Wichtiger dabei ist jedoch, dass die Fehler in einer Summe von Einzelschätzungen einander häufig ausgleichen. Abb. 2 zeigt die Unterteilung einer Aufgabe in neun Teilaufgaben, die separat geschätzt wurden. Die Schätzungen liegen in den meisten Fällen daneben, teilweise bis zu 80%. Einige Aufwände wurden überschätzt, andere unterschätzt, sodass die Gesamtschätzung nur um 15% abweicht. Das ist eine akzeptable Abweichung.

Abb. 2: Die Fehler in einer Summe von Einzelschätzungen gleichen einander häufig aus

Dreipunktschätzung

Alltagsschätzungen sind in der Regel Einpunktschätzungen, bei denen sich der Schätzer auf einen aus seiner Sicht wahrscheinlichen Wert festlegt. Leider neigen wir dabei unbewusst dazu, den bestmöglichen Fall zu nennen.

Besser ist daher die Dreipunktmethode, auch PERT-Schätzung genannt.

Der Erwartungswert ist so definiert, dass mit einer Wahrscheinlichkeit von 50 % der zu erwartende Aufwand unterhalb und mit ebenfalls 50 % Wahrscheinlichkeit oberhalb des Erwartungswerts liegt.

Zum Seitenanfang

Schätzschema

Das Schätzschema kombiniert das Gesetz der großen Zahlen und die Dreipunktschätzung miteinander. Dabei handelt es sich um eine Tabelle, in der Schätzer die zu schätzenden Aufgaben – sorgfältig in möglichst viele Teilaufgaben unterteilt – und ihre Schätzwerte eintragen.

Mit Tabellenkalkulationsprogrammen wie Microsoft Excel oder OpenOffice.org Calc können Sie die PERT-Spalte über o.g. Formel befüllen lassen. Sinnvoll ist es darüber hinaus, automatisch Summen über die einzelnen Spalten zu bilden, um eine Gesamtschätzung zu erhalten.

Abb. 3 zeigt ein Schätzschema für die Aufgabe: Schreibe einen Artikel über Aufwandschätzung für die PHPUser, mindestens 4 Seiten. Es ist gut zu erkennen, dass die Aufgabe in drei Teilaufgaben unterteilt wurde, die jeweils aus weiteren Unteraufgaben bestehen, die einzeln geschätzt wurden. Das Schreiben des Artikels verursacht – wie zu erwarten war – die meisten Aufwände, aber auch für die Vorbereitung und Recherche muss viel Zeit eingeplant werden. Der Gesamtaufwand liegt mit hoher Wahrscheinlichkeit zwischen 15 und 47,5 Stunden mit dem Erwartungswert 28,75 Stunden.

Abb. 3: Schätzschema für die Aufgabe: Schreibe einen Artikel für die PHPUser

Das vorgestellte Schätzschema ist ein Werkzeug für Entwickler und soll Ihnen dabei helfen, zu besseren Aufwandschätzungen zu gelangen. Projektmanager arbeiten zumeist mit umfangreicheren Schätzschemata, die zudem die Standardabweichung berechnen, d.h. die Abweichung der Schätzungen von ihrem Erwartungswert oder mit anderen Worten: die Unsicherheit der Schätzungen. Die Schätzung aus Abb. 3 ist eine verhältnismäßig unsichere Schätzung, da die Summe aus d_max drei Mal so hoch ist wie die Summe aus d_min. Zudem enthalten professionelle Schemata zusätzliche Puffer und Wahrscheinlichkeiten, um auf Basis der Schätzungen einen realistischen Projektplan erstellen zu können. Unter Berücksichtigung der Standardabweichung würden Projektmanager bis zu 50 Stunden für die Erstellung des Artikels einplanen – abhängig von den Formeln, die zur Berechnung der Puffer angewendet werden. Die Zusammenhänge an dieser Stelle zu erklären, würde zu weit führen, aber Sie können mit Näherungen arbeiten.

Die ungefähre Standardabweichung wird nach folgender Formel berechnet.

Um die Wahrscheinlichkeit zu erhöhen, dass die tatsächlichen Aufwände geringer sind als Sie geschätzt haben, beziehen Sie die Standardabweichung in Ihr Schätzergebnis mit ein. Der zu erwartende Aufwand unterschreitet mit einer Wahrscheinlichkeit von 84 % den Wert, den Sie erhalten, wenn Sie den Erwartungswert zu der Standardabweichung addieren, und sogar 98 %, wenn Sie die Standardabweichung zwei Mal addieren.

Im oberen Beispiel beträgt die Standardabweichung näherungsweise 5,42 Stunden. Mit einer Wahrscheinlichkeit von 50 % ist der zu erwartende Aufwand kleiner als 28,75 Stunden, mit einer Wahrscheinlichkeit von 84 % kleiner als 34,17 Stunden und mit einer Wahrscheinlichkeit von 98 % kleiner als 39,58 Stunden.

Zum Seitenanfang

Aufwandschätzung in agilen Projekten

Klassische Projektvorgehensmodelle mit schwergewichtigen, formalen Prozessen gehören heute weitgehend der Vergangenheit an. Viele Projektmanager setzen heute auf agile Verfahren. Die Motivation agiler Methoden wird bereits durch die Namenswahl verdeutlicht: Agil bedeutet flink oder beweglich und bezieht sich darauf, schnell auf geänderte Rahmenbedingungen zu reagieren. Agile Vorgehensmodelle lösen sich vom klassischen Wasserfall-Modell mit dessen einzelnen Phasen und Variationen und setzen stattdessen auf eine enge Zusammenarbeit mit dem Auftraggeber, wenig bürokratischen Aufwand und Teamarbeit.

Das derzeit populärste agile Vorgehensmodell ist Scrum. Der Begriff beschreibt ursprünglich einen Spielzug im Rugby: das Gedränge der Spieler beim Einwurf des Spielballs während des Spiels – sinnbildlich für die Nähe und »Reibereien« zwischen Kunden und Projektteam.

Scrum ist ein Gesamtsystem aus Meetings, Artefakten, Rollen und Werten, das aufbauend auf den Rahmengrundsätzen der agilen Softwareentwicklung ein Prozessmodell für die Abwicklung von Projekten darstellt. Dabei setzt Scrum sehr stark auf die Selbstorganisation und Verantwortung des Teams. Ein Projektmanager im klassischen Sinne mit umfangreicher Autorität existiert nicht. Vielmehr gibt es neben dem Team und dem Kunden (repräsentiert durch die Rolle des Product Owners) den so genannten Scrum Master, dessen Aufgabe es ist, die Werte und Regeln von Scrum während des Projekts zu wahren und Hindernisse zu beseitigen.

Auch in Scrum befasst sich das Entwicklerteam zu Beginn des Projekts damit, die Aufgaben zu sammeln. Sie werden durch den Product Owner priorisiert und anschließend im so genannten Product Backlog eingetragen, einer Sammlung aller Aufgaben, die laufend während des gesamten Projekts aktualisiert wird. Wenn alle Aufgaben bekannt und in das Product Backlog aufgenommen sind, dann beginnt die erste Schätzklausur.

Schätzklausuren

Schätzklausuren finden in Scrum regelmäßig während des gesamten Projektverlaufs statt. Die erste Schätzklausur dient dazu, die Gesamtaufwände des Projekts grob abzuschätzen. Der Ablauf ist dabei wie folgt: Der Product Owner erklärt alle Anforderungen, bis das Team sie vollständig verstanden hat. Anschließend schätzt das Team die Aufwände. Der Scrum-Master moderiert die Klausur und stellt sicher, dass sie regelkonform abläuft und pünktlich endet. Sind alle Einträge abgeschätzt oder ist die Zeit abgelaufen, so endet die Klausur.

Schätzklausuren sollten höchstens zwei Stunden dauern, da nach dieser Zeit die Konzentration des Teams nachlässt und die Schätzgüte spürbar abnimmt.

Alle Teammitglieder müssen sich darüber verständigen, wie viel Aufwand mit der Umsetzung verbunden ist. Dazu muss das Team alle wesentlichen Arbeitsschritte berücksichtigen, also Design, Programmierung, Integration, Test und Dokumentation. Dahinter steht nichts anderes als die bereits bekannte Aufteilung von Aufgaben in überschaubare Teilaufgaben und somit das Gesetz der großen Zahlen. Als Schätzverfahren kann die Dreipunktschätzung dienen, allerdings ist ein anderes Verfahren geeigneter, um rasch einvernehmliche Teamschätzwerte zu erhalten: Das Team spielt Planungspoker; ein Schätzverfahren, das mit dem klassischen Pokerspiel mit Ausnahme der Tatsache, dass Karten zum Einsatz kommen, nicht viel zu tun hat.

Planungspoker

Zunächst erhält jedes Teammitglied einen Stapel Karten. Jede Karte hat auf ihrer Vorderseite eine Zahl aus einer ausgewählten Punktereihe. Die Punktewertefolge ist in Scrum nicht vorgeschrieben, gut eignen sich allerdings Zahlenreihen, die eine adäquate Auswahl an Aufwandsgrößen bieten, die sich deutlich genug voneinander unterscheiden. Eine geeignete Wertefolge ist die Fibonacci-Folge, bei der sich die jeweils folgende Zahl durch Addition der beiden vorherigen Zahlen ergibt, wobei jedem Punkt folgende Bedeutung zugeordnet wird:

Die Punktewerte stehen zueinander in Beziehung, d.h. ein kleiner Aufwand ist doppelt so groß wie ein sehr kleiner Aufwand; ein sehr großer Aufwand so groß wie ein mittlerer und großer Aufwand zusammen.

Sobald der Product Owner die Aufgabe vorgestellt und das Team etwaige Unklarheiten beseitigt hat, wählt jedes Teammitglied die Karten aus, die aus seiner Sicht den Aufwand der Aufgabe repräsentiert und legt die Karte verdeckt auf den Tisch. Sobald alle Karten auf dem Tisch liegen, drehen alle Teammitglieder gleichzeitig ihre Karte um.

In den meisten Fällen haben verschiedenen Teammitglieder unterschiedliche Zahlen aufgedeckt, vor allem in den ersten Schätzklausuren oder bei unklaren Aufgabenstellungen. Wenn also kein Konsens vorliegt, so erklären die beiden Teammitglieder, deren Schätzwerte sich am meisten unterscheiden, wie sie zu ihrem Wert gekommen sind.

Das ist übrigens nichts Ungewöhnliches, ganz im Gegenteil: Unterschiedliche Experten kommen häufig zu verschiedenen Ergebnissen. Der CSS-Purist schätzt den Aufbau des grundlegenden Spaltenlayouts auf 8, weil er ein eigenes auf das Projekt angepasste Layout-Modul schreiben möchte; der CSS-Pragmatiker setzt auf ein Framework wie YAML, kann also schon auf vorgefertigte Bausteine zurück greifen und schätzt den Aufwand daher nur auf 3. Das ist normal und gewünscht. Die restlichen Teammitglieder verfolgen die Diskussion und können ihre Entscheidung überdenken. Anschließend geht das Planungspokerspiel in die nächste Runde: Erneut wählen alle Mitglieder eine Karte, legen sie auf den Tisch und drehen sie gleichzeitig um. Das Ganze geht so lange, bis alle Schätzungen übereinstimmen, d.h. jedes Teammitglied die gleiche Karte aufgedeckt hat.

Es ist hilfreich, neue Anforderungen mit bereits existierenden Schätzungen zu vergleichen, um einen Maßstab zu erhalten und dadurch sicherzustellen, dass die Schätzwerte zueinander relativ korrekt sind. Dabei ist es sinnvoll, gleich große Anforderungen während des Abschätzens zu gruppieren und regelmäßig zu überprüfen, ob die Gruppen in sich konsistent sind.

Bereits nach wenigen Planungspokerspielen sind Teams aufeinander abgestimmt und verstehen unter verschiedenen Aufwänden dasselbe; innerhalb von zwei Minuten oder weniger kommt das Team zu einem einstimmigen Ergebnis.

Ermittlung der Entwicklungsgeschwindigkeit

In Scrum werden Projekte in Iterationen von zwei bis vier Wochen durchgeführt, die Sprints genannt werden. Zu Beginn jedes Sprints findet ein Sprintplanungsmeeting statt, in dem das Team Aufgaben aus dem (priorisierten) Product Backlog für den Sprint auswählt und in das Sprint Backlog überführt, die Aufgabenliste für den folgenden Sprint. Die Aufwandschätzungen für diese Aufgaben werden noch einmal überprüft und gegebenenfalls korrigiert.

Wenn die Aufgaben nach der Dreipunktschätzung geschätzt wurden, kann das Team ermitteln, wie viele Stunden ihm im Laufe des Sprints real zur Verfügung stehen und entsprechend viele Aufgaben in den Sprint aufnehmen. Wurde hingegen Planungspoker gespielt, muss anders vorgegangen und die Entwicklungsgeschwindigkeit (engl. velocity) des Teams ermittelt werden.

Die Entwicklungsgeschwindigkeit ist die Summe aller Aufwände der am Ende eines Sprints vom Product Owner abgenommenen Arbeitsergebnisse.

Je mehr Sprints das Team hinter sich gebracht hat, desto genauere Aussagen zur Entwicklungsgeschwindigkeit sind möglich. Angenommen, das Team verpflichtet sich im ersten Sprint, Aufgaben im »Wert« von 25 Punkten zu erledigen, schafft aber nur 16. Im nächsten Sprint nimmt sich das Team Aufgaben für 20 Punkte vor und schafft tatsächlich 22. Diese sind Basis für den dritten Sprint, in dem die 22 Punkte erreicht werden, ebenso im vierten Sprint. Nun kann diese Entwicklungsgeschwindigkeit im Projektplan angenommen werden.

Das ist übrigens nicht ungewöhnlich, dass Teams im ersten Sprint nur etwa 60% ihrer tatsächlichen Leistungsfähigkeit erreichen. Zumeist dauert es drei bis vier Sprints, bis das Team sich eingespielt hat und im Projekt »angekommen« ist.

Zum Seitenanfang

Fazit

Schätzen ist eine verantwortungsvolle und anspruchsvolle Aufgabe. Wenn sich der Schätzer verschätzt, kann das verheerende Folgen nach sich ziehen. Es ist daher unbedingt erforderlich, die Aufwandschätzung so realistisch wie möglich zu halten. Dazu ist es notwendig, das zu erreichende Ziel und die Voraussetzungen klar zu definieren, von denen der Schätzer ausgehen kann. Je klarer die Voraussetzungen sind und je genauer die Anforderungen, desto besser kann eine Schätzung sein.

Eine Schätzung ist sehr gut, wenn der tatsächliche Wert vom Nominalwert nicht mehr als 10 % abweicht. Ein Schätzverfahren ist gut, wenn die Abweichungen in 75 % der Fälle unter 25 % liegen.

Jede Aufwandschätzung ist nur ein grober Anhaltspunkt. Auch wenn der Schätzer in dem, was er schätzen muss, sehr erfahren ist und zum Zeitpunkt der Schätzung ausreichend viele Informationen zur Verfügung stehen, müssen Schätzungen zur Erstellung eines Projektplans und somit auch der Projektplan selbst regelmäßig aktualisiert werden. Agile Projektvorgehensmodelle wie Scrum sind dafür ausgelegt, dynamisch auf sich ändernde Projektanforderungen zu reagieren.

Der Artikel erschien in der PHP User, Ausgabe 5, S. 63–68. Eine gekürzte Fassung des Artikels, die Aufwandsschätzung im Rahmen agiler Projekte außen vor lässt, habe ich bereits im Rahmen des des Webkrauts-Adventskalenders 2009 unter dem Titel Hilfsmittel für Aufwandsschätzungen veröffentlicht.