Schätzung

Von Mitch Lacey. Besitzer von Mitch Lacey & Associates, Inc, einem auf Agile- und Scrum-Umsetzungen und -Optimierungen spezialisierten Beratungsunternehmen.

Januar 2012

Mitch Lacey erklärt die Schwierigkeiten beim Schätzen von Softwareprojekten, zudem bietet er Tipps und Tricks zur Nutzung von zwei agilen Softwareschätzverfahren bei der Projektschätzung.

Betrifft

Application Lifecycle Management; Team Foundation Server

Inhalt

• Einführung

• Warum Schätzung schwierig ist

• Schätzverfahren

• Storypunkt als Maßeinheit

• Planning Poker

• Wandschätzverfahren

• Schätzung

• Priorisierung

• Schlussfolgerung

Kreative und unvorhersehbare Arbeit zu schätzen, ist wirklich sehr schwierig. Eine geeignete Methode dafür auszuwählen, kann sich als ebenso schwierig erweisen. Fred Brooks sagt es am besten: „Es ist sehr schwierig, eine energische, plausible und Job gefährdende Verteidigung einer Schätzung abzugeben, die von keiner quantitativen Methode abgeleitet ist, von wenig Daten unterstützt wird, und in erster Linie auf der Intuition der Manager basiert.“

Dennoch werden Sie aufgefordert, im Voraus und frühzeitig Schätzungen für die Softwareprojekte abzugeben. Und trotz aller Bemühungen, das Management daran zu erinnern, dass es sich um grobe Schätzungen handelt, werden diese Erstschätzungen nur allzu häufig als verbindlich betrachtet.

In diesem Artikel erkläre ich Ihnen, warum Projektschätzungen im Voraus so schwierig sind, wie agile Softwareschätzverfahren helfen können, und wie Sie Ihren Produktrückstand mit Planning Poker und Storypunkten schätzen können.

Warum Schätzung schwierig ist

In den meisten Projekten werden Sie aufgefordert, eine Schätzung im Voraus vorzunehmen. Um zu verstehen, warum das ein solches Problem ist, muss der 1981 von Barry Boehm eingeführte und von Steve McConnell 1997 in seinem Buch Software Project Survival Guide erneut aufgegriffene „Cone of Uncertainty“, der den Verlauf von Unsicherheiten bei Projekten beschreibt, betrachtet werden.

Der Cone of Uncertainty veranschaulicht, dass die Unsicherheit zu Beginn eines Projekts am größten ist (eine Varianz von 4x bis 0,25x im Messbereich). Diese Varianz bedeutet, dass ein auf 12 Monate geschätztes Projekt am Ende tatsächlich zwischen 3 und 48 Monate dauern kann. Zu Beginn eines Projekts ist die Sicherheit bezüglich des Projekts am geringsten, aber dennoch erfolgt zu diesem Zeitpunkt die Aufforderung, sehr präzise Schätzungen abzuliefern.

Im Agile-Bereich wird versucht, so schnell wie möglich von Unsicherheit zu Sicherheit fortzuschreiten. Dies wird erreicht, indem frühzeitig das Maximum an Kenntnissen über das System, und wie es entworfen werden soll, erlangt wird. Dazu wird ein einzelner Pfad durch das System erstellt, eine vollständige und funktionierende Story. Mit dieser werden Entwurfs- und Anforderungsannahmen frühzeitig herausgefiltert, sodass der Zustand der Sicherheit schneller und mit mehr Zuversicht erreicht wird.

Schätzverfahren

Es gibt eine Vielzahl von nutzbaren Schätzverfahren, darunter Zählung, Sachverständigenurteil (Einzelperson und Gruppe), Zerlegung, Analogie, Proxyschätzung, Planning Poker und das Wandschätzverfahren. Zudem können Tools wie Cocomo II verwendet werden. Bei all diesen Verfahren muss eine Einheit – Stunden, Tage, Wochen, Monate, Idealtage, T-Shirt-Sizing, Punkte – oder alle davon für eine Schätzung ausgewählt werden. Wenn Sie die Einheit nicht verstehen, ist die Schätzung wertlos. Unter Berücksichtigung der genannten Punkte ist es kein Wunder, dass eine Schätzung so schwierig ist.

Agile Teams tendieren beim Schätzen des Produktrückstands zu bestimmten Schätzeinheiten und -verfahren (Storypunkte und Planning Poker), aber Ihr Team kann gerne die Methode auswählen, die am besten für die Anforderungen geeignet ist. Nach meiner Erfahrung bringt es die besten Ergebnisse, wenn die Schätzung in Form von Storypunkten und entweder mit Planning Poker oder dem Wandschätzverfahren erfolgt. In den folgenden Absätzen lernen Sie die Storypunkte als Maßeinheit kennen, außerdem stelle ich Ihnen die von mir bevorzugten Schätzverfahren vor: Planning Poker und Wandschätzverfahren.

Storypunkt als Maßeinheit

Mike Cohn beschreibt Storypunkte am besten: „Storypunkte sind eine Maßeinheit, um die Gesamtgröße einer User Story, einer Funktion oder einer anderen Arbeit zu beschreiben.“ Storypunkte geben an, wie umfangreich eine Story entweder hinsichtlich der Größe oder der Komplexität im Vergleich zu anderen ist. Mike bezieht sich oft auf „Hunde-Punkte“, wenn er Teams das Konzept der relativen Größe vermittelt. Ein Hund mit zwei Punkten (klein) wäre ein Chihuahua. Ein Hund mit 13 Punkten (groß) wäre eine Deutsche Dogge. Unter Berücksichtigung dieser beiden Größenangaben ist es recht einfach, die Größe der anderen Hunderassen in Relation zu einem Chihuahua oder einer Deutschen Dogge einzuschätzen. Ein Beagle, der ungefähr doppelt so groß ist wie ein Chihuahua, könnte fünf Punkte bekommen. Ein Labrador, der größer ist als ein Beagle, aber kleiner als eine Deutsche Dogge, könnte acht Punkte erhalten.

Wenn Sie gerade den Umgang mit Storypunkten erlernen, sollte Ihr Team eigene feste Vergleichspunkte aufstellen. Dazu wählen Sie eine Story aus dem Produktrückstand aus, die alle gemeinsam für klein halten (entweder in Bezug auf Größe oder Komplexität), und eine, bei der alle der Ansicht sind, dass es sich um eine umfangreiche Story handelt. Ich halte es für sinnvoll, wenn die kleine Story eine 2-Punkt-Story ist, denn falls ich eine kleinere Größe benötige, ist das noch möglich (beispielsweise, wenn ich einen Zwerg-Chihuahua entdecke). Wenn ich die kleinste bekannte Story als 1-Punkt-Story festlege und eine kleinere Angabe benötige, geht das nicht mehr. Die anderen Storys können dann in Relation zu diesen eingeordnet werden.

Wenn es daran geht, Zahlen für diese Größenangaben auszuwählen, finde ich die Fibonacci-Folge am sinnvollsten. Fibonacci ist die Summe der beiden Vorgängerzahlen. Also 1 und 2, die nächste ist 3. Dann 3 und 2, die nächste ist also 5. Es folgen 5 und 3, die nächste lautet folglich 8 usw. Ich bevorzuge die Fibonacci-Folge vor z. B. dem T-Shirt-Sizing oder exponentiellem Wachstum (4/8/16/32/64/128/256 usw.), da wir Menschen gut mit dem Dezimalsystem rechnen können. Wenn dieser Bereich verlassen wird, sogar wenn Größen wie XS, S, M, L, XL vorliegen, wird es verwirrend. Die Fibonacci-Zahlen sind einfach, leicht verständlich und bieten genügend Genauigkeit, um relative Schätzungen bereitzustellen. Sie können einen anderen Zahlensatz auswählen, denken Sie nur daran, dass die Beständigkeit ein sehr wichtiger Punkt ist.

Storypunkte sind relative Werte, keine festen. Es gibt keine direkte Korrelation zwischen Stunden und Punkten. Beispielsweise lässt sich nicht mit Sicherheit sagen, dass eine Story mit zwei Punkten 12,2 Stunden entspricht. Das liegt daran, dass die Anzahl der Stunden, die zum Fertigstellen von Storys im 2-Punkt-Bereich nötig sind, sehr stark variieren können. Ebenso können die Storypunkte eines Teams nicht mit Sicherheit mit denen eines anderen Teams verglichen werden. Storypunkte sind nur für das Team spezifisch, das die Schätzung vorgenommen und die Storypunkte erstellt hat, sie weisen vermutlich eine Komplexität auf, die nur von diesem Team nachvollzogen werden kann, und sie sind nicht absolut.

Planning Poker

Nachdem Sie eine Maßeinheit ausgewählt und die Skala erstellt haben, erfolgt die Schätzung. Die meisten agilen Teams nutzen die Planning-Poker-Methode, um die relative Größe der Storys zu schätzen. Sie wird bei agilen Teams häufig verwendet, da sie ein objektives Maß mit mehreren subjektiven Schätzverfahren, darunter Analogie und Sachverständigenurteil, bietet. Das wichtigste Element bei Planning Poker besteht in der Beteiligung. Jeder im Team muss sich beteiligen, ja, jeder. Funktionstester schätzen Aufgaben des Entwicklungsteams und umgekehrt. Funktionale Projektmanager schätzen möglicherweise ebenfalls Aufgaben des Entwicklungsteams. So wird sichergestellt, dass in den objektiven Zahlen möglichst viele subjektive Schätzungen enthalten sind.

Beginnen Sie mit einem Satz Planning-Poker-Karten. Die Planning-Poker-Karten können einfach aus Karteikarten oder umgeänderten Spielkarten hergestellt und auch gekauft werden – Visual Studio stellt sie sogar her. Jede Karte stellt eine der Zahlen in dem von Ihnen ausgewählten Storypunktbereich (1, 2, 5, 8, 13 usw.) dar. Jedem Teilnehmer wird ein „Blatt“ gegeben, das den vollständigen Bereich der verfügbaren Storypunkte abdeckt.

Nachdem die Karten verteilt sind, beginnt das Spiel.

1. Der Scrum-Master stellt dem Team das oberste Element im Produktrückstand vor.

2. Das Team bespricht die Story.

3. Der Produktbesitzer klärt Fragen, Annahmen und Unbekanntes ebenso wie die Akzeptanzkriterien.

4. Jedes Teammitglied entscheidet für sich allein, wie umfangreich diese Story in Relation zu einer Referenzstory, einer Reihe von Referenzstorys oder allen Storys im Produktrückstand ist.

5. Es wird bis drei gezählt, dann zeigen alle gleichzeitig die ausgewählte Karte.

Wenn alle die gleiche Karte zeigen, kann das Team die Schätzung erfassen und mit der nächsten Story weitermachen.

Gibt es große Unterschiede (wenn beispielsweise die gezeigten Zahlen von eins bis acht reichen), wird die Story vom Team erörtert. Um diese Erörterung zu fokussieren, sollten die Teammitglieder, die jeweils den niedrigsten und den höchsten Zahlenwert gezeigt haben, die Gründe für ihre Schätzung darlegen. Hier ist das Gespräch wichtig, nicht die Zahl, denn hier findet der Lernvorgang statt, und jedwede Annahmen werden aufgedeckt. Nach einem kurzen Gespräch (30 Sekunden bis eine Minute) wiederholt das Team die Schritte 4 und 5. Dieses Verfahren wird so lange fortgesetzt, bis sich das Team auf eine Schätzung für die Story einigt.

Das scheint relativ einfach, aber es ist wichtig, einige grundlegende Regeln zu kennen. Zunächst einmal gilt, wenn das Team keine Einigung erzielt, sollten Sie nicht weitermachen. Angenommen, ein Teammitglied wählt die Zahl acht, alle anderen entscheiden sich für die Zahl fünf. Wenn der Besprechungsleiter sagt: „Das reicht aus. Wir nehmen hier die Zahl fünf und machen weiter.“, was wird dann das Teammitglied machen, das sich für die Zahl acht entschied? Meiner Erfahrung nach trägt dieses Teammitglied jede Entscheidung des Teams mit, hört aber auf, sich selbst vollständig einzubringen. Die Planung geht dann schneller voran, aber Sie haben etwas Wertvolles verloren. Nicht nur, dass dieses Teammitglied die Arbeit nicht mehr nachvollziehen kann, sondern das Team verliert auch noch den Beitrag und den Blickwinkel eines Teammitglieds. Außerdem ist es in Ordnung, eine andere Meinung zu haben. Aus Diskussionen darüber, warum ein Teammitglied eine höhere Zahl gewählt hat als alle anderen, folgen wertvolle Erkenntnisse. Wenn eine Pattsituation vorliegt, kann der Besprechungsleiter die „Fist-to-Five“-Methode (null bis fünf) anwenden. Sie bewirkt Wunder dabei, Besprechungen voranzubringen, ohne einen der Teilnehmer vor den Kopf zu stoßen.

Da bei der Planning-Poker-Methode die Schätzungen in Punkten ausgedrückt werden, ist sie perfekt für die Schätzung des Produktrückstands geeignet. Der Sprintrückstand sollte jedoch in Stunden geschätzt werden. Nachdem das klargestellt ist, wird und wurde Planning Poker erfolgreich zum Schätzen von Sprintrückständen verwendet. Die Zahlen auf den Karten geben dann anstelle von Punkten Stunden an. Die Regel ist einfach:

• Schätzungen des Produktrückstands erfolgen in Punkten.

• Schätzungen des Sprintrückstands erfolgen in Stunden.

Sie können Planning Poker zu Beginn eines jeden Projekts und in dessen gesamten Lebenszyklus, wenn sich neue Informationen ergeben, Prioritäten ändern und Unklarheiten beseitigt werden, einsetzen.

Wandschätzverfahren

Planning Poker ist ein großartiges Tool zum Schätzen von User Storys. Allerdings würde es mit der Planning-Poker-Methode unglaublich lange dauern, Hunderte Storys eine nach der anderen zu schätzen. Wenn Sie einen unbearbeiteten Rückstand mit Hunderten von Storys haben, die noch nicht geschätzt oder mit Prioritäten versehen sind, benötigen Sie eine schnellere Methode der Schätzung.

Das Wandschätzverfahren ist so konzipiert, dass Diskussionen von zwei versus drei und fünf versus acht wegfallen. Stattdessen werden – zumindest am Anfang – die Elemente rein auf relativer Basis in einer kontinuierlichen Größe gruppiert. Dies bietet den Beteiligten auch die Möglichkeit, einer großen Gruppe an Storys eine generelle Priorisierung zuzuweisen, ohne sich damit befassen zu müssen, ob eine Story vielleicht etwas wichtiger ist als eine andere.

Zum Durchführen eines Wandschätzverfahrens müssen die User Storys zunächst auf Karten ausgedruckt werden. Dann rufen Sie das Team und die Beteiligten in einem Raum mit einer großen leeren Wand (etwa 4 m lang und 2,5–3 m hoch) zusammen. Für diese Wand gibt es zwei Grundregeln:

• Die Höhe bestimmt die Priorität. Oben angeordnete Storys haben eine höhere Priorität, unten angeordnete Storys eine niedrigere. Die Priorität einer Story kann auf der Rendite, dem Geschäftswert oder etwas ganz Einfachem wie „es ist einfach wichtig, ich weiß nicht, warum“ basieren.

• Die Breite ist der Größe vorbehalten. Storys auf der linken Seite sind kleiner, Storys auf der rechten Seite sind umfangreicher. (Sie können das auch umkehren und von rechts nach links vorgehen, wenn Sie z. B. in Japan sind, ist das logischer.) Wichtig hierbei ist, sich eine horizontale sowie eine vertikale Linie vorzustellen. Die Teammitglieder und Beteiligten sollen sich die Frage stellen, wo sich diese Story in Relation zu den anderen einordnen lässt.

Das Team nutzt die Wand, um alle Storys nach ihrer Größe anzuordnen. Die Beteiligten verwenden die Wand, um Storys zu priorisieren. Wie bei Planning Poker wird die relative Größe herangezogen. Aber anstatt zwei Referenzstorys als Vergleich zu nutzen, wird die Wand als Konstante betrachtet. Kleine Story? Nach links verschieben. Große Story? Nach rechts verschieben. Wichtige Story? Oben positionieren. Eine Story, auf die vorerst verzichtet werden kann? Unten platzieren.

Die Anwesenheit der Beteiligten beim Schätzen der Storys ist nicht erforderlich, die Anwesenheit des Teams bei der Priorisierung ist jedoch unbedingt nötig. Der Scrum-Master und der Produktbesitzer müssen sowohl bei den Schätzungs- als auch den Priorisierungsaktivitäten anwesend sein.

Wenn Ihr Rückstand bereits geschätzt ist, können Sie einfach den Übungsabschnitt für die Priorisierung durchführen. Haben Ihnen die Produktbesitzer und Beteiligten bereits einen priorisierten Rückstand bereitgestellt, können Sie einfach den Übungsabschnitt für die Schätzung durchführen. (Der Produktbesitzer wird vermutlich die Priorisierung nach erfolgter Schätzung erneut prüfen wollen. Schließlich haben die Kosten einen erheblichen Einfluss auf die Priorität.) Nun erfahren Sie detailliert, wie das Verfahren vonstatten geht. Zuerst steht die Rolle des Teams im Vordergrund.

Schätzung

Geben Sie dem Team den unbearbeiteten Rückstand, und beginnen Sie mit der Schätzung. Weisen Sie das Team an, links außen an der Wand die kleinstmöglichen Storys und rechts außen die größtmöglichen Storys anzugeben, und zwar unabhängig von Zahlen. Das Team platziert die Storys auf Grundlage dieser beiden Vorgaben irgendwo an der Wand. Der Vorteil dieser Vorgehensweise liegt darin, dass es keinen vorgefassten Begriff davon gibt, was eine Story mit zwei Punkten oder mit drei Punkten ausmacht. Diese Methode ist wahrhaft relativ basierend darauf, wie groß die Wand ist; deswegen ist eine wirklich große Wand hier sehr praktisch.

Wenn das Team Schwierigkeiten mit dieser Aktivität hat, können Sie der Wand mehr Struktur geben. Stellen Sie dazu zusätzlich Referenzstorys mit einer Schätzung von eins bis acht Punkten bereit. Machen Sie sich keine Gedanken, eine größere Referenzstory zu erstellen. Wenn große Storys in der Priorität steigen, werden sie in der Regel in kleinere Elemente untergliedert. Nachdem das Team die fünf Storys identifiziert hat, positionieren die Teammitglieder diese an einer Stelle an der Wand, die der Storygröße entspricht (wieder von links nach rechts verschieben). Lassen Sie für Storys mit mehr als acht Punkten etwas Platz auf der rechten Seite der Wand. Positionieren Sie die Storys an der Wand, und weisen Sie das Team an, die verbleibenden Storys in Relation zu diesen Referenzstorys an der Wand zu platzieren. Dabei soll bedacht werden, dass kleinere Storys auf der linken und größere Storys auf der rechten Seite Platz finden.

Nachdem die Storys an der Wand sind, soll das Team die logischen Zäsuren zwischen den Storygrößen identifizieren. Ziehen Sie zwischen den Storygruppen mit Klebeband eine vertikale Linie, um diese Zäsur zu verdeutlichen. Bald sieht Ihre Wand in etwa wie die hier dargestellte aus. Allen Storys in der ersten Gruppe könnte die Zahl 2 zugeordnet werden, alle in der zweiten Gruppe erhalten die Zahl drei, alle Storys in der dritten Gruppe werden mit fünf bewertet, und allen in der letzten Gruppe wird die Zahl acht zugewiesen. Die Zahlen sind nicht so sehr von Bedeutung wie die Tatsache, dass nun alle Storys in Relation zueinander geschätzt sind.

Nachdem die Storys geschätzt sind, müssen Sie die Beteiligten einbeziehen, damit den Storys eine Priorität zugeordnet werden kann.

Priorisierung

Die Kunden und Beteiligten werden die Größe einer Story wissen wollen, damit sie die Priorität einfacher ermitteln können. Aber sie werden sich viel stärker darauf konzentrieren, die zugehörigen Storys zu dieser Story zu finden und sicherzustellen, dass diese fertig gestellt werden. Rechnen Sie damit, dass die Beteiligten bei den Prioritäten nicht die gleiche Meinung haben. Der Produktbesitzer wird diese Informationen als Hilfe bei der Entscheidung der letztendlichen Priorität heranziehen.

Erklären Sie den Beteiligten die Wand. Teilen Sie ihnen mit, dass die Karten an der Wand alle Funktionen widerspiegeln, die sie im Endprodukt sehen möchten. Legen Sie dar, dass das Team bereits jede Story geschätzt hat, und dass sie die Punktschätzung für eine Story abhängig davon vornehmen können, in welcher Spalte sich die Story an der Wand befindet. Erinnern Sie alle daran, dass den Teammitgliedern bei der Priorisierung keine aktive Rolle zukommt. Das Team soll beobachten und Notizen zum Verhalten, zu Interaktionen sowie zu den Begründungen machen, warum die Priorität bestimmter Storys steigt oder fällt. Bei Bedarf kann das Team auch Fragen von den Beteiligten beantworten. Falls das Team die Größe von einer oder mehreren Storys nicht mit Sicherheit einordnen kann, da noch Antworten von einem bestimmten Beteiligten nötig sind, kann das Team die Fragen zu diesen Storys stellen (sofern die Zeit dies zulässt).

Bitten Sie die Projektbeteiligten, bei der Ermittlung der relativen Priorität aller Storys zu helfen, indem sie diese innerhalb der mit Klebeband erstellten Spalten nach oben oder nach unten verschieben. Rufen Sie den Beteiligten ins Gedächtnis: Je höher eine Story an der Wand angeordnet wird, desto höher ist ihre Priorität für das Geschäft. Legen Sie die folgenden Regeln fest:

• Wenn Sie eine Story ganz oben platzieren, sollten Sie diese Positionierung begründen können.

• Sie können sich gegenseitig fragen, warum eine Story wichtiger als eine andere ist. Sie können sich gerne gegenseitig fragen: „Wer hat diese Story nach oben (unten) verschoben?“ Oder Sie können laut sagen: „Ich denke, diese Story muss verschoben werden. Wer ist anderer Meinung?“ Dadurch werden Gespräche zwischen den interessierten Parteien ohne Leitung gefördert.

• Wenn Sie eine Story niedriger an der Wand anordnen als jemand anders, markieren Sie diese mit einem farbigen Punkt, um darauf aufmerksam zu machen.

Wenn die Priorisierung von einer Gruppe vorgenommen wird, besteht der größte Vorteil darin, dass alle Beteiligten die Prioritäten der verschiedenen Storys besser nachvollziehen können. Verläuft eine Diskussion zu lange ergebnislos, sollte der Produktbesitzer die Karten einsammeln, die beiden nicht zustimmenden Beteiligten ermitteln und sich notieren, später noch einmal mit diesen zu sprechen.

Die Übung kann zwei bis sechs Stunden in Anspruch nehmen, das ist abhängig von der Anzahl der Storys und der Anzahl von Beteiligten. Wenn Sie fertig sind, sieht die Wand in etwa aus wie das angezeigte Bild.

Die Wand wird grob in vier Quadranten unterteilt sein. Die oben links angeordneten Storys sind klein und weisen eine hohe Priorität auf, sie werden also im Produktrückstand ganz oben stehen. Die Storys, die oben rechts eingeordnet sind, weisen eine hohe Priorität auf, sind aber auch sehr umfangreich. Diese Storys sollten demnächst untergliedert werden, damit sie in die kommenden Sprints einbezogen werden können.

Der linke untere Quadrant umfasst kleine Storys mit geringerer Priorität. Sie werden wahrscheinlich am Ende des Rückstands angeordnet. Der rechte untere Quadrant ist mit großen Storys gefüllt, die ebenfalls eine niedrigere Priorität aufweisen. Diese Storys sind die Epen oder Themen. Sie müssen letztlich in kleinere, besser überschaubare Storys aufgegliedert werden; dies erfolgt jedoch erst, wenn sie in der Prioritätenliste nach oben steigen.

Verbringen Sie einige Zeit damit, die Wand als Ganzes mit der Gruppe zu betrachten. Befindet sich eine Story im falschen Quadranten, verschieben Sie diese. Muss eine Story mit hoher Priorität aufgegliedert werden, und es ist noch Zeit dafür, dann machen Sie es, während alle im Raum sind.

Am Ende des Wandschätzverfahrens halten Sie den Anfang eines Versionsplans in der Hand. Wenn Ihnen die historische Geschwindigkeit des Teams bekannt ist, können Sie sogar in einem ungefähren Bereich vorgeben, welche der Storys im oberen linken Quadranten fertig gestellt werden.

Eine Schätzung ist schwierig, da es zu Beginn sehr viele Unsicherheiten gibt. Produktbesitzer und agile Projektmanager versuchen, den Wert durch frühes Lernen zu maximieren, indem sie Gespräche mit den Produktbesitzern und Beteiligten führen, funktionierende Software herstellen und Feedback zu dieser Software integrieren, um einen auslieferbaren Zustand zu erzielen. Aber auch bei agilen Projekten muss geschätzt werden, wann eine Reihe von Funktionen freigegeben werden kann.

Ich empfehle das Schätzverfahren Planning Poker (geeignet für kleinere Storysätze) und das Wandschätzverfahren (gut zum Verwalten von großen und unbearbeiteten Rückständen geeignet). Mit beiden erhalten Sie alle Daten, die Sie zum Bilden eines Plans benötigen, und das ist das letztendliche Ziel der Schätzung.

Siehe auch

Konzepte

Zusammenarbeit [umgeleitet]

Zusammenarbeit (weiter vertiefen) [umgeleitet]

Erstellen Ihres Backlogs

Bereinigen und Schätzen des Backlogs

1. Mike Cohn, Agile Estimating and Planning, Seite 36

2. Consensus decision-making: hand signals (Wikipedia)