Was ist der Zweck der Planung von Poker im Sprint?

Unsere Business Analysten und Projektleiter teilen uns die Anforderungen des Kunden als Stories mit. Bei jeder Sprint-Planung werden wir (Entwickler) gebeten, Planning Poker zu spielen.

Sie baten uns alle, die Komplexität und nicht den Aufwand zu betrachten. Wir sind wirklich verwirrt und verschwenden Zeit bei unseren Besprechungen. Ein Entwickler stellte die Frage: Was sollten wir wirklich beachten? Geht es um die Code- / DDL-Änderung, die wir in dieser Anforderung vornehmen müssen (Zeitschätzung), oder geht es darum, ob wir die Anforderung verstanden haben oder nicht? '

Aber was meinen sie (Business Analyst & Projektleiter) wirklich mit "die Anforderung verstehen" und "eine Karte erheben"?

Außerdem haben wir Slicing-Meetings für einzelne Scrum-Teams, bei denen jeder Entwickler eine Schätzung der Zeit für eine bestimmte Aufgabe für jedes Scrum-Team abgibt. Also, worüber reden sie wirklich in Planning Poker?

Kann jemand dies an einem Beispiel erklären? Versuchen Sie zu differenzieren, wovon sie wirklich sprechen, wenn sie "Komplexität" und "Aufwand" sagen.

Betrachten Sie den Standpunkt des Projektmanagers

Wenn sie nach Komplexität fragen, möchten sie eine Zahl, die sie mit Ihrem nächsten Sprint vergleichen können, um Ihre Geschwindigkeit als Team zu ermitteln. Möglicherweise versuchen sie auch, Ihr Ergebnis mit den Schätzungen anderer Teams zu addieren, um eine Gesamtschätzung zu erhalten, wann alle Storys fertig sind.

Der Projektmanager sucht nach einer Schätzung, wann das Projekt abgeschlossen sein wird oder ob sie auf anderen Seiten des Zeit-Funktions-Kosten-Dreiecks flexibel sind. Welche anderen Abgänge können gezogen werden, um es in die verbleibende Zeit einzufügen. Das ist nicht unvernünftig. Geschäftsentscheidungen müssen auf der Grundlage dieser Schätzung getroffen werden. Das Problem ist, dass es wirklich schwierig ist, dies für Software abzuschätzen. Die Planung von Poker ist eine der Möglichkeiten, um dieses Problem zu lösen. Anstatt es einfach als Addition der Anzahl der Story-Punkte zu betrachten, sollten Sie es als komplexere Funktion der Schätzung betrachten, die Arbeit erledigen, die Zeit messen, iterieren und dann extrapolieren.

Die Diskussion ist wichtiger als eine Zahl

Ich finde, dass der wichtigste Teil von Story-Pointing-Meetings die Diskussionen sind, die anstehen. Wenn jemand im Team nicht sicher ist, eine Nummer vorzuschlagen, versteht er die Geschichte wahrscheinlich nicht ganz und es muss mehr darüber diskutiert werden. Aus dem Agile Manifest "Customer Collaboration over Contract Negotiation". Anstatt nur einen Vertrag als User Story zu spezifizieren und zu sagen, dass das Team gescheitert ist, wenn es nicht genau das tut, was Sie wollen, ist es immer besser, darüber zu sprechen, was der Kunde wirklich will, bis Sie es verstanden haben.

Komplexität vs. Aufwand

Um Ihre spezifische Frage zu Komplexität vs. Aufwand zu beantworten, scheint jeder eine andere Meinung zu haben. Mountain Goat , das sind die Leute, die die Planungspokerkarten mit Ziegen auf dem Rücken herstellen und deren Besitzer Mike Cohn in der Welt von Agile / Scrum groß ist, sagen, dass es Anstrengung und nicht Komplexität sein sollte.

Es wird normalerweise nicht als Zeitmaß angesehen (siehe Beispiel unten für ein Gegenbeispiel), da die Leute die Zeit schlecht einschätzen können. Andere Faktoren beeinflussen, welche Zahl sie vergeben: zB der Druck, die Zahl niedrig zu halten, damit Sie mehr Funktionen anpassen können Druck, eine höhere Zahl anzugeben, um sich Platz zu schaffen, wenn Sie auf ein Problem stoßen. Das Erstellen von Software ist schwierig. Wenn Sie Ihr 100. Haus bauen, können Sie abschätzen, wie lange Sie brauchen, da Sie zuvor 99 Häuser gebaut haben. Wenn die Software, die Sie erstellen, mit den zuvor erstellten Programmen identisch ist, können Sie sie kopieren und einfügen. Dabei ist jedes Softwareprojekt anders und es treten Probleme auf, die Sie am Anfang nicht vorausgesehen haben.

Wie bei Zeitschätzungen, die versteckten Druck enthalten, hat auch ein gewisses Maß an Aufwand Probleme. Wenn ein Junior-Entwickler eine hohe Komplexität einschätzt, hat er möglicherweise das Gefühl, dass er sich für Angriffe offen lässt, da er von anderen, die eine niedrigere Schätzung abgeben würden, nicht gut genug ist. Dies schadet nicht nur Ihren Schätzungen, sondern auch den Mitarbeitern im Team.

Die geplanten Poker-Zahlen sind keine "Anzahl der Tage" oder ein anderes Zeitmaß, sondern ein relatives Maß, um zwei User Stories vergleichen zu können. Das erste, was Sie in einem neuen Team tun müssen, ist eine Grundlinie zu erstellen. Wählen Sie eine User Story aus, die sich in der Mitte des Komplexitätsbereichs befindet, und vereinbaren Sie als Team eine Nummer in der Mitte des Bereichs, den Sie zuweisen möchten. Jetzt können alle anderen User Stories relativ zu dieser nummeriert werden. Ich habe festgestellt, dass das viel einfacher ist.

Gründe, warum Sie keine Schätzung abgeben können

Wenn Projektmanager Sie fragen, wann ein Projekt abgeschlossen sein wird, müssen sie die Komplexität der gestellten Fragen verstehen. Programmierer sind keine Fabrikarbeiter, bei denen ihre Produktivität gemessen werden kann, indem multipliziert wird, wie schnell sie tippen und wie lange sie arbeiten. Sie finden Antworten auf Probleme und das ist schwierig. Indem Sie Planning Poker spielen, identifizieren Sie zuerst, wer im Team das Gefühl hat, die Frage, welche Nummer zugewiesen werden soll, nicht beantworten zu können, und untersuchen dann, warum diese Frage nicht beantwortet werden kann. Ich denke, es gibt mindestens vier Gründe:

1. Die Geschichte ist zu groß. Teilen Sie es in kleinere, spezifischere User Stories auf. Denken Sie daran, dass jede User Story dem Benutzer einen Wert bieten sollte. Eingabe - Prozess - Ausgabe = Wert.
2. Sie verstehen die Problemdomäne nicht gut genug, um sagen zu können, wie lange es dauern wird, oder sogar, um alle Fragen richtig zu stellen. Sprechen Sie mit Leuten, die mehr über den Bereich / die Programmierung dieser Art von Anwendung wissen, unabhängig davon, was Sie zuvor noch nicht gesehen haben. Wenn das nicht möglich ist oder Sie nicht bis dorthin bringt, können Sie einen Design-Spike verwenden. Erstellen Sie einen Prototyp für eine Lösung, jedoch nur für einen begrenzten und festgelegten Zeitraum. Legen Sie fest, wie lange die Prototyping-Phase nicht zu lange dauern soll, und treffen Sie sich dann erneut, um Ihr neues Verständnis mitzuteilen.
3. Ihre Stakeholder sind nicht spezifisch genug. "Build me a cloud" ist keine akzeptable User Story. "Bauen Sie mir ein System auf, in dem ich VMs nach Bedarf hochfahren kann" ist besser, da es weiter unterteilt ist, aber immer noch nicht auf dem Niveau ist, auf dem Sie eine genaue Schätzung abgeben können, wie lange Sie brauchen werden, da es hundert Versteckte geben wird Annahmen in dieser Aussage, die Ihr Stakeholder hat, werden Sie erst herausfinden, wenn Sie ihnen etwas zeigen.
4. Selbst wenn Sie eine Schätzung abgeben können, wird diese letztendlich wahrscheinlich beim ersten Mal falsch sein. Das Schätzen ist ein schwieriges Problem und der beste Weg, schwierige Probleme zu lösen, ist die Anwendung der wissenschaftlichen Methode. Sammeln Sie Daten darüber, welche Zahlen jedes Teammitglied schätzt, und dann, wie lange es wirklich gedauert hat oder wie komplex es wirklich war, obwohl das schwieriger ist, und vergleichen Sie diese über die Zeit. Schließlich werden Sie ein Gefühl dafür bekommen, wer überschätzt und wer unterschätzt, und dann sollten Sie dies mit dem Team teilen. Menschen können sich gegenseitig helfen, besser abzuschätzen. Diese Zahlen können auch in Ihr Tracking-Tool zurückgeführt werden, um besser vorherzusagen, wie lange Geschichten dauern werden.

Fazit

Ich glaube, der springende Punkt sollte in der Diskussion liegen, aber wenn Sie wirklich jemandem eine Nummer geben müssen, versuchen Sie einfach, eine Nummer zu erstellen, die unabhängig davon ist, welches Teammitglied daran arbeitet und in welcher Reihenfolge an den Geschichten gearbeitet wird. Der Punkt ist, zu einem Backlog zu gelangen, das beide priorisiert ist, sodass Sie in der richtigen Reihenfolge und Größe daran arbeiten, sodass der Projektmanager ungefähr sehen kann, wie viele weitere Sie vor Ihrer Deadline einfügen können. Sie sollten in der Lage sein, am Ende einer Iteration anzuhalten und alle Funktionen zu nutzen, die bereits gestartet wurden.

Warnung

Sie können die Zeit für die Erledigung von Aufgaben in Ihrem Team so lange einschätzen, wie Sie möchten, solange Sie die Zahlen für sich behalten. Sobald Sie einer Nummer erlauben, dem Team zu entkommen und von anderen Personen gesehen zu werden, werden sie Dinge mit dieser Nummer tun, die Sie nicht beabsichtigt haben. Sie werden versuchen, es als eine Anzahl von Tagen zu verwenden, um die Aufgaben abzuschließen. Sie werden versuchen, Sie an der relativen Komplexitätsbewertung festzuhalten und Sie zu fragen, warum es länger gedauert hat, eine User Story mit der gleichen Anzahl von Punkten zu beenden als eine andere. Sie addieren Ihre Zahlen und vergleichen sie mit den Zahlen anderer Teams. Sie werden gefragt, warum das andere Team mehr Arbeit leistet, wenn es innerhalb eines bestimmten Zeitraums mehr Story-Punkte erledigt. Du kannst'

Beiseite

Der Planungs-Poker-Satz von Zahlen ist normalerweise so verteilt, dass die Lücken zwischen den Zahlen immer größer werden. Ich glaube, das soll die Leute davon abhalten, darüber zu streiten, ob eine User Story eine 16 oder eine 17 ist. Wenn sie größer als eine 13 ist, dann mache sie einfach zu einer 20.

Beispiel

Ich kenne mindestens ein Team, das nur die Zahlen 1, 2, 3 und 4 für die Planung des Pokers verwendet. Sie definieren diese entgegen der obigen Diskussion als Programmiertage (tatsächlich paarweise Programmiertage, dh wie viele Tage es dauern würde, wenn zwei Programmierer an derselben Maschine zusammenarbeiten, um die User Story fertigzustellen). Wenn das Team der Meinung ist, dass die Fertigstellung einer User Story länger als 4 Tage dauern würde, wird die Story nicht mit einem Verweis versehen, und der Product Owner wird gebeten, mit dem Team zusammenzuarbeiten, um die Story weiter aufzuschlüsseln oder genauer zu spezifizieren, damit dies möglich ist in diesen Bereich für ein zukünftiges Planungstreffen gebracht werden. Aber dies ist fortgeschritten, agil und sollte wahrscheinlich nur von Leuten verwendet werden, die bereits Erfahrung mit den anderen Techniken haben.

Ich denke, Franks und Encaitas Antworten decken es ziemlich genau ab, aber es gibt einige zusätzliche Dinge zu beachten:

Warum Story Points verwenden?

Das Ziel der Schätzung mit Story Points ist es, die relative Komplexität der Entwicklung von Features für Ihre Anwendung anzugeben. Eine einfache Möglichkeit, darüber nachzudenken, besteht darin, eine Geschichte aufzunehmen, die Sie im kommenden Sprint haben, z. B. eine Änderung der URL. Sie wissen, dass dies in Bezug auf die Komplexität einfach ist und klar definierte Akzeptanzkriterien hat, sodass das gesamte Team der Meinung ist, dass es auch beim Testen eine 1 ist (unter Verwendung der Fibo-Skala).

Die nächste zu schätzende Geschichte besteht darin, eine Reihe von Benutzerdaten zu aggregieren und diese am Frontend zu visualisieren. Als Entwickler wissen Sie sofort, dass dies viel komplexer ist als das Ändern einer URL. Sie besprechen die Story und die Akzeptanzkriterien, haben viele Fragen und sehen verschiedene mögliche Lösungen dafür. Die anderen Entwickler und QA sind sich ebenfalls einig, dass es sehr komplex ist. Sie sind sich also alle einig, dass es sich um eine 34-Punkte-Geschichte handelt. Es ist erwähnenswert, dass Sie auf der Fibo-Skala auch angeben können, wie viel Vertrauen Sie in das Esimate haben. Je größer die Lücken zwischen den Zahlen, desto weniger Vertrauen haben Sie in Ihre Schätzung

An diesem Punkt sollte Ihr Scrum-Meister springen und sagen, dass dies als einzelne Story zu groß ist und in kleinere Storys mit weniger Komplexität unterteilt werden muss. Sie können dies erreichen, indem Sie sogenannte SPIKES ausführen. Dies ist nur eine Weile, um etwas zu untersuchen. Für dieses Beispiel stimmen Sie und die anderen Entwickler zu, dass Sie 4 Stunden Zeit haben möchten, um die möglichen technischen Lösungen zu diskutieren und zu untersuchen.

Um es kurz zu machen, Sie teilen diese große Geschichte in vier weitere Geschichten mit 5, 8, 8 und 13 Punkten auf. Nein, denken Sie daran, dass es sich bei diesen Schätzungen nur um relative Komplexität handelt. Sie müssen sich nicht auf die ursprüngliche Schätzung summieren. Außerdem verfügen Sie jetzt über weitere Informationen, um eine genauere Schätzung vorzunehmen.

Anschließend stimmen Sie als Team zu, dass Sie für diesen Sprint die 13-Punkte-Story, eine 8-Punkte-Story und die 1-Punkt-URL-Änderung, die Sie bereits identifiziert haben, erstellen möchten. Also insgesamt 22 Punkte. Beim nächsten Sprint bekommst du 27 Punkte, beim nächsten Sprint bekommst du 18 Punkte. Nach 3 Sprints können Sie beginnen, ein gewisses Vertrauen in Ihre Geschwindigkeit zu bekommen (Geschwindigkeit ist die Menge an Arbeit, die Ihr Team in einem Sprint erledigen kann). Um die Geschwindigkeit zu ermitteln, wird der Durchschnitt der vorherigen Sprints berechnet. In diesem Beispiel ist der Durchschnitt (22 + 27 + 18) / 3 = 22,3, also runden Sie ihn auf der Fibo-Skala auf den nächsten Wert (21).

Für den nächsten Sprint musst du nur 21 Punkte erreichen.

Lassen Sie sich nicht davon abbringen, Ihre Story-Point-Schätzung genau richtig zu machen - es ist keine exakte Wissenschaft. Sie wissen, dass eine URL-Änderung weitaus weniger komplex ist als das Zusammenfassen von Daten, also bewerten Sie sie einfach entsprechend.

Darüber hinaus ist es gut, diese Dinge im Team zu diskutieren. Sehen Sie sich Ihre Schätzungen während der Sprintüberprüfung noch einmal an und besprechen Sie, ob Sie mit ihnen zufrieden waren oder nicht, und geben Sie diese Informationen an die nächste Sprintplanungssitzung weiter.

Das ganze Team schätzt

Das gesamte Team muss sich auf eine einzige Schätzung für jede Geschichte einigen. Ein Feature wird erst fertiggestellt, wenn es produktionsbereit ist. Nur den Code schreiben zu lassen, ist noch lange nicht erledigt. Meiner Erfahrung nach waren Scrum-Teams bei der Arbeit als Team weitaus effektiver. Nehmen Sie ein Beispiel für das Team, mit dem ich gerade zusammenarbeite. Als ich dazukam, machten sie alle Sprint-Meetings und planten Poker, aber während des Sprints war der Prozess 1. BAs / Product Owners definieren die Anforderungen als Storys mit Akzeptanzkriterien und Akzeptanztests Code 3. Der Entwickler hat den Code in den Entwicklungszweig eingefügt, damit QA testen kann. 4. QA-Test, dann beginnen sie, Fragen zu stellen, und die Tests schlagen fehl, sodass die Entwicklung fortgesetzt wird.

Was fehlt hier? Es gibt nicht genug Diskussionen im Vorfeld und jedes Teammitglied hat nur seine eigene Aufgabe gesehen. Jetzt kommen BA / PO, Entwickler und QA zusammen, bevor sie einen Code schreiben, um die Anforderungen im Detail zu besprechen und Fragen vorab zu stellen, und setzen dann die Diskussion während des gesamten Sprints fort. Dies ist weitaus effizienter und führt zu qualitativ besseren Lösungen.

Das Planen von Poker hilft dabei, da das Team gezwungen ist, die Funktion zu diskutieren und sich als Team darauf zu einigen, wie komplex die Bereitstellung dieser Funktion ist. In der traditionellen Softwareentwicklung war der Projektmanager für die Bereitstellung des Projekts verantwortlich, aber jeder, der Erfahrung mit diesem Ansatz hat, weiß, dass es nicht funktioniert, da die Leute häufig nicht die Verantwortung für ihren Anteil an der Bereitstellung der Anwendung übernehmen. In Agile sollten Sie keine Projektmanager benötigen, da das Team die Verantwortung für die Bereitstellung der Anwendung insgesamt übernimmt.

Pünktliche Einschätzung der Aufgaben

Ich bin der Ansicht, dass ich mit Teams gearbeitet habe, die die Zeit für Aufgaben schätzen, und mit Teams, die nur Story Point Esimtates durchführen, NICHT ZEITSCHÄTZUNGEN! Sie sind eigentlich nur Zeitverschwendung. Sie sind nicht so genau wie Story Points, weil sie für Einzelpersonen und nicht für das Team spezifisch sind und jeder Einzelne eine andere Vorstellung von der Zeitschätzung hat (die Flamme entzünden).

Story Points akzeptieren, dass sich Dinge, dh Anforderungen, ständig ändern, sodass Sie wirklich einen Indikator dafür benötigen, was das Team in einem Sprint schaffen kann.

Sobald Sie die Geschwindigkeit verstanden haben, können Sie Ihre Ergebnisse rechtzeitig messen, da Sie wissen, was Sie in jedem Sprint tun können, z. B. alle zwei Wochen, welche Funktionen geliefert werden können. Ihr Scrum Master und Ihre Produktbesitzer sollten Schätzungssitzungen abhalten, um einen Ausblick auf zukünftige Sprints zu erhalten. Dann können Sie einen Indikator dafür erhalten, wie viel Arbeit Sie in den kommenden Monaten erledigen werden. Auf diese Weise können Produktbesitzer Prioritätsentscheidungen darüber treffen, welche Funktionen in die endgültige Anwendung aufgenommen werden sollen.

Ich habe Entwickler gebeten, die Zeit für die Planung von Aufgaben zu schätzen, aber ich bin mit diesem Ansatz überhaupt nicht einverstanden (in der Tat bin ich mit diesem Ansatz überhaupt nicht einverstanden), weil er nicht genau ist. Ein Entwickler kann nur die Zeit für die eigentliche Aufgabe angeben, ein anderer fügt möglicherweise Zeit für das Zubereiten von Tassen Tee hinzu!

Zeitschätzungen werden immer zu Berichtszwecken an eine andere Person weitergegeben und es werden auch die einzelnen Elemente der Bereitstellung eines Features im Vergleich zum gesamten Teamaufwand überbetont.

Schätzung ist nicht das größte Problem

Abgesehen davon ist es meines Erachtens nicht das größte Problem, die Schätzung herauszufinden. Das Wichtigste ist, als Team zusammenzuarbeiten, um die Dinge während des Sprints zu erledigen, damit Sie nicht alles am letzten Tag zum Testen übergeben. Sie möchten während des 2-wöchigen Sprints eine stetige Menge an Funktionen sehen. Die Teamdynamik, die ich oben erklärt habe, ist ein großer Teil davon. Die Geschichtspunktschätzung hilft Ihnen dabei, dies zu planen, da Sie sehen, welche großen Geschichten in kleinere zerlegt werden müssen, die regelmäßig getestet werden können.

Wikipedia erklärt die Planung von Poker sehr gut. Lassen Sie mich einen kurzen Überblick über den aktuellen Stand geben, wobei ich mich auf Ihren Fall konzentriere:

Warum Poker planen?

Zuallererst sollten Sie alle an Bord sein, um herauszufinden, warum Sie im Gegensatz zu einer "normalen" Schätzung ein Planungspoker betreiben. Der Grund ist eigentlich ganz einfach: Wir alle haben viel zu tun, wenn es darum geht, die Zeit für eine Aufgabe abzuschätzen. So ziemlich jede Studie hat gezeigt, dass das menschliche Gehirn einfach nicht in der Lage ist, Aufgaben abzuschätzen, die einen angemessenen Zeitraum in Anspruch nehmen. (Auch ein Grund, warum Tickets, deren Schätzung über 2-3 Tage hinausgeht, im Hinblick auf ihre Schätzung so gut wie wertlos sind.)

Warum Komplexität statt Aufwand?

Dies geht einher mit dem oben Gesagten. Anstrengung bedeutet normalerweise Zeit , und wir saugen daran. Komplexität hingegen ist schwer objektiv zu quantifizieren, was in diesem Fall gut ist. Es ist dein Bauch, der dir sagt, dass diese Geschichte komplex sein wird. Für jemanden anderen mag es weniger komplex sein. Aber Sie müssen nicht genau quantifizieren, wie komplex es wirklich ist. Sie müssen diese XKomplexität nicht erreichen - im Gegensatz zu einer zeitgesteuerten Anstrengung, bei der Sie sich schließlich darauf einigen müssen, dass dies XTage oder Ähnliches dauert .

Warum die Karten verstecken?

Die Karten mit Ihrer Komplexität guestimate werden versteckt gespielt und dann auf einmal aufgedeckt. Dies geschieht, um sicherzustellen, dass Sie nicht von den Meinungen anderer beeinflusst werden, bevor Sie Ihre eigene anfängliche Schätzung abgeben. Wenn jeder in Bezug auf Komplexität ungefähr das gleiche Bauchgefühl hat, dann sind Sie fertig. Wenn wild unterschiedliche Zahlen vorkommen, wissen Sie, dass dort etwas zu besprechen ist. Auf diese Weise können Sie sehr schnell mit Geschichten umgehen, für die jeder die gleiche Vorstellung von der erforderlichen Komplexität / dem erforderlichen Aufwand hat.

Warum Fibonacci-Zahlen?

Die Zahlen auf Ihren Karten sind normalerweise Fibonacci-Zahlen oder eine andere Folge mit vielen Lücken in den Zahlen. Dies soll Sie dazu zwingen, Ihrem Bauchgefühl voll zu vertrauen. Wenn Sie zwischen 8 und 13 wählen müssen, ist dies eine weitaus größere Aussage als bei 9 oder 10. Wie bereits erwähnt, liegen die großen Unterschiede darin, wo die versteckten Probleme liegen. Wenn Sie also die Lücken vergrößern, erhöhen Sie die Chance auf erkennen diese Probleme besser.

Warum funktioniert das überhaupt?

Interessanterweise funktioniert es nicht, wenn Sie das erste Mal planen, Poker zu spielen. So einfach ist das. Was bedeutet "3" oder "5" überhaupt? Es gibt keine Definition für die Bedeutung jeder Zahl (absichtlich!) Und es liegt an Ihrem gesamten Team, die tatsächliche Bedeutung hinter jeder dieser Zahlen zu ermitteln. Erst wenn Sie es akzeptiert haben, Ihre Geschichten in diesen Zahlen zu schätzen - und nachdem Sie mehrere davon erkannt haben -, können Sie besser abschätzen, wann Sie eine 5 erhöhen sollten und wann es eher eine 8 ist.

Wenn Sie dies mit dem Konzept der Geschwindigkeit kombinieren und Ihre Sprintfortschritte über diese Story Points messen, haben Sie eine völlig neue Effizienzskala, die mehr oder weniger unabhängig von herkömmlichen Zeitschätzungen ist.

Für mich persönlich ist der wichtigste Punkt bei der Planung des Pokers jedoch, dass Sie durch die Verwendung von Fibonacci-Zahlen anstelle von Zeitschätzungen Unsicherheiten leichter erkennen können. Bei klassischen Zeitschätzungen sind Sie nicht gezwungen, solche "extremen" (aufgrund der Anzahl der Lücken) Entscheidungen zu treffen. Daher können Schätzungen sehr eng zusammenliegen und das Team kann fälschlicherweise glauben, dass sie die Geschichte gut genug verstanden haben.

Beispiel

Ein einfaches Beispiel dafür, was normalerweise passiert, ist, dass eine Geschichte präsentiert wird und dann Person A einen Einspruch erhebt. Es ist in etwa so: "Bitte vergessen Sie nicht, dass dieses Feature X betrifft und dies bedeutet, dass es teurer ist als bisher angenommen." Das Hauptproblem ist, dass immer diese Person A am Tisch ist. Es gibt immer etwas, worüber sich jemand Sorgen macht. Wenn Sie eine offene Diskussion führen, haben Sie keine Ahnung, wie groß die Sorge ist, dass dieses Ding X ist.

Wenn Sie versteckte Schätzungen basierend auf der Zeit vornehmen, wird es ein bisschen besser. Dennoch ist eine Person A mit einem gültigen Einwand möglicherweise noch kein klarer Ausreißer in ihrer Schätzung. Andererseits muss Person A bei der Planung des Pokers mehr darüber nachdenken, wie sehr ein tatsächliches Problem X ist. Bei zwei verschiedenen Problemen können Sie ihre Wichtigkeit nicht durch den obigen "gesprochenen Text des Einspruchs" unterscheiden. Sogar mit Zeitschätzungen ist es ziemlich schwer zu erkennen, welches ein größeres Problem ist. Die Hoffnung, Poker hier zu planen, ist, dass Sie am Ende einen Einwand haben, der nur 2-3 Punkte von den Schätzungen der anderen abweicht, aber der andere Einwand, der 5 oder 8 Punkte vom Median entfernt war, ist möglicherweise die wichtigste Unsicherheit Ihrer Sprintplanung.

Nach Dutzenden von Iterationen in meinem Team haben wir herausgefunden, dass es in den Story Points hauptsächlich um die mittelfristige Projektsteuerung geht. Sie ermöglichen es der Produktbesitzerin, sich zwei oder drei Sprints vorauszusagen und im Wesentlichen auf der Grundlage einer Durchschnittsgeschwindigkeit geschäftliche und bereichsspezifische Entscheidungen über eine Veröffentlichung zu treffen.

Wir haben festgestellt, dass Story Points auf Sprint-Ebene nicht so nützlich sind, da keine zwei Sprints ähnlich sind und es unmöglich ist, vorherzusagen, wie viel Arbeit erledigt wird. Aus diesem Grund haben wir beschlossen, uns nicht von der Einschätzung zu verunsichern und die Planung von Pokersitzungen nur als Vorwand für Gespräche über Features zu nehmen.

Dies stimmt mit einem Punkt überein, den Mike Cohn hier gemacht hat .

Als Randnotiz gilt dies für ein bestimmtes Team, aber es gibt keine Regel, wie Story Points Ihnen helfen. Ich empfehle Ihnen, zuerst an der Methodik festzuhalten, aber versuchen Sie schnell selbst herauszufinden, ob und wie sie nützlich sind. Retrospektiven helfen Ihnen, darüber nachzudenken.

Das grundsätzliche Problem dabei ist, dass es kaputt ist. Der Premierminister möchte Planning Poker nutzen, um sich ein Bild von der Komplexität jeder Story zu machen, mit der Absicht, ungefähr zu wissen, wie viele Storys in einen Sprint passen (die Geschwindigkeit des Teams).

Infolgedessen ist es ein "nicht basierend auf der Zeit", das "basierend auf der Zeit" ist. Kein Wunder, dass alle verwirrt sind.

Es gibt Möglichkeiten, dies für Sie zu erledigen. Vergessen Sie zunächst den Aufwand und konzentrieren Sie sich auf die Komplexität. Vergessen Sie, wie lange es dauern könnte, sich zu entwickeln, und konzentrieren Sie sich stattdessen auf die Bereiche, auf die sich jede Geschichte auswirkt. Wenn Sie eine Story haben, die die Datenbank, den Servercode, den Clientcode und die Clientdokumentation aktualisiert, können Sie sagen, dass dies eine 4-Punkte-Story ist. Wenn es sich nur um eine Änderung der DB-SQL handelt, ist dies eine 1-Punkt-Story. Dies gibt Ihnen eine verständlichere Möglichkeit, die relative Komplexität zwischen den Geschichten herauszufinden. (Sie müssen sich Metriken einfallen lassen, die für Ihre Umstände sinnvoll sind, z. B. Testabdeckungsanforderungen oder Komplexität der Benutzeroberfläche.)

Generell bin ich jedoch der Meinung, dass es eine sinnlose Zeitverschwendung ist, die einfach die Sprintplanung fördert, als wären es Mini-Wasserfallprojekte. Wen kümmert es wirklich, wie viele Story Points Sie in einen Sprint einbauen können? Wenn du am Ende eines Sprints noch Geschichten übrig hast, machst du sie einfach im nächsten. Vor diesem Hintergrund können Sie Ihren Rückstand genauso gut auf die Größe jeder herausragenden Story reduzieren, die Sie haben, und diese mit der Zeit schrittweise reduzieren. Die Zustellung dauert so lange wie nötig (aber es geht schneller, wenn Sie nicht 20% Ihrer Zeit in Besprechungen zur Planung von Rückständen und Sprints verschwenden). Am Ende des Projekts kümmert es niemanden, wie viele Story Points geliefert wurden. Was die Leute interessieren, ist das gelieferte Projekt.

Das Zeigen von User-Storys gibt dem Unternehmen einen Vorsprung in Bezug darauf, ob etwas neu verhandelt werden muss. Wenn Sie einen Monat Zeit haben, um einige Arbeiten abzuschließen, die Sie mit 100 bewertet haben, sind Sie möglicherweise in Schwierigkeiten. Es gibt Ihnen auch die Möglichkeit, eine epische Geschichte in etwas Kleineres zu zerlegen, das noch Wert hat und im Sprint abgeschlossen werden kann.