Haftungsausschluss: Ich bin Entwickler, also behaupte ich nicht, dass ich mich mit agilen Praktiken auskenne, daher verwende ich möglicherweise nicht immer die richtigen Wörter und Begriffe. Bitte korrigieren Sie mich ggf.
Agile Teams verwenden häufig die Metrik „Story Points“, um den Aufwand einer Aufgabe abzuschätzen. Ich habe jedoch festgestellt, dass ich mich nicht ganz wohl dabei fühle, eine "Story Point" -Schätzung abzugeben, da dies zu spekulativ erscheint. Stattdessen ziehe ich es vor, die Story Points zuerst in Arbeitsvolumen , Risiko , Komplexität und Ungewissheit (zB wie hier erwähnt ) zu disaggregieren und diese vier dann zu einer „Story Point“-Schätzung zu kombinieren. Leider habe ich keine eindeutige Möglichkeit, dies zu tun (einfacher Durchschnitt scheint zu ... einfach), also habe ich mir ein paar Fragen ausgedacht:
Verwenden Sie in Ihrer Praxis die oben genannte Disaggregation? Warum oder warum nicht?
Ich ermutige die Teams, sich auf die Schätzungskonsistenz zu konzentrieren , anstatt einen komplizierten Schätzungsansatz zu verfolgen.
Dafür gibt es eine Reihe von Gründen, darunter:
Relative Schätzungen (Punkte) sind nützlich, da sie tendenziell eine bessere Annäherung liefern als absolute Schätzungen und einfacher zu handhaben sind. Punkte sind jedoch nur eine Annäherung, und sie sind am sinnvollsten, wenn sie insgesamt und über einen bestimmten Zeitraum betrachtet werden. Ich frage mich, ob Sie zu sehr auf die Details eingehen. Einige Vorschläge unten.
Ich berücksichtige sicherlich alle Faktoren, die Sie erwähnt haben, aber ich neige dazu, es im relativen Vergleich zu zuvor abgeschlossenen Geschichten zu tun ("diese ist ungefähr so groß/schwierig/unsicher wie diese"). Ein paar vertraute "Basisgeschichten" zum Vergleich im Hinterkopf zu haben, macht die Schätzung viel einfacher.
Verwenden Sie Fibonacci oder eine modifizierte Fibonacci-Reihe für Schätzungen. Bei den größeren Geschichten müssen Sie nicht so genau sein, da die Abstände zwischen den Zahlen groß sind. Für kleinere Geschichten spielen ein oder zwei Punkte so oder so kaum eine Rolle.
Schätzen Sie im Team (Wideband Delphi / Planning Poker) und streben Sie einen Konsens an. Die Schätzungen des Teams dienen als gegenseitige Überprüfung. Teams neigen dazu, zu einem gemeinsamen Verständnis darüber zu gelangen, was Punktgrößen bedeuten.
Schätzungen müssen wirklich nur so genau sein, dass Sie entscheiden können, ob eine Story in einen Sprint passt oder ob sie aufgeteilt werden muss.
Eigentlich ist "Story Points" genau dafür da, nicht das zu tun, was Sie versuchen zu tun :) Die Idee dahinter ist folgende;
Es gibt ein Missverständnis, dass jeder Story Point mit einer aufwandsbasierten Metrik wie Stunden, Minuten, Tage usw. übereinstimmen sollte. Das ist falsch. „3“ Story Point kann 5 Stunden dauern, um diesen Sprint abzuschließen, aber derselbe Punkt kann 2 Stunden dauern, um den nächsten Sprint abzuschließen.
Alles, was wir versuchen, ist, die Geschichten relativ zueinander zu dimensionieren. Wir vertrauen unseren Sinnen und sagen „Hey, wenn ISSUE-1234 3 ist, dann sollte ISSUE-4321 definitiv 8 sein!“; das ist es.
Ich glaube nicht, dass es eine mathematische Funktion gibt, die Aufwand, Risiko, Komplexität und Unsicherheit berücksichtigen muss, um einen einzigen Wert in Story Points zurückzugeben. Ich finde diese Vorgehensweise auch nicht sinnvoll.
Eine Möglichkeit, darüber nachzudenken, besteht darin, die Faktoren zu reduzieren. Unsicherheit ist eine Form von Risiko, also müssen Sie nicht beide identifizieren. Im schlimmsten Fall würden Sie sich drei Faktoren ansehen – Aufwand, Risiko und Komplexität. Ich vermute auch, dass es oft (aber nicht unbedingt) einen Zusammenhang zwischen Aufwand und Komplexität gibt, da komplexe Arbeit mehr Aufwand erfordert, um sicherzustellen, dass alles stimmt. Wir können jedoch mit drei Faktoren arbeiten.
Ich glaube, dass es weitaus schlimmer ist, die Arbeit zu unterschätzen als zu überschätzen, sodass eine Erhöhung eines der drei Faktoren zu einer Erhöhung der Story Points führt. Wenn ich mir die Beschreibung anschaue und denke, dass es ungefähr eine 5 für den Aufwand gibt, aber es gibt noch ein paar offene Fragen, die sich auf die Arbeit auswirken können, dann geht es zu einer 8. Wenn es bekannte Risiken gibt, die nicht gemindert wurden , es könnte bis zu 13 oder 20 gehen. Es wird Arbeit (Anstrengung) erfordern, Fragen durchzuarbeiten, um Antworten zu erhalten oder Risiken zu mindern, daher ist dies konzeptionell sinnvoll. Der zu erhöhende Betrag hängt davon ab, wie viele Fragen, wie viel Arbeit zur Beantwortung dieser Fragen erforderlich ist und wie viele nicht geminderte Risiken bestehen.
Wenn es jedoch zu viele offene Fragen oder zu viele unverminderte Risiken gibt, sollte das Item zurück in das Product Backlog gehen und nicht als bereit für die Auswahl in einem Sprint betrachtet werden. Wenn Sie Scrum verwenden, gibt es einen Mindeststatus, der erforderlich ist, damit ein Product Backlog Item für einen Sprint ausgewählt wird – das Team glaubt, dass es die beschriebene Arbeit innerhalb eines einzigen Sprints erledigen kann. Wenn das Team unsicher ist, ob es den Gegenstand einbringen und alle unbeantworteten Fragen beantworten oder alle Risiken handhaben kann, die wahrscheinlich durch die Übernahme der Arbeit entstehen, muss es weiter verfeinert werden. Eine Verfeinerung kann verwendet werden, um diese Fragen zu beantworten oder diese Risiken zu mindern.
Am Ende gibt es aber einen einzigen Wert für die Schätzung der Arbeit. Dies gilt für Story Points, ideale Stunden oder jede andere Messmethode. Das Team gibt eine Erklärung über den Aufwand ab, der für die Fertigstellung der Arbeiten erforderlich ist.
Story Points basieren nicht auf irgendeiner greifbaren Formel, und sie sind nicht der Punkt der Schätzung.
Während des Sprint Plannings muss sich das Team auf die Arbeit einigen, die in das Sprint Backlog aufgenommen werden soll. Dies basiert auf zwei Dingen:
Welche Elemente der Product Owner an die Spitze des Product Backlog gesetzt hat, was bedeutet, dass deren Fertigstellung die höchste Priorität hat; Und
Wie viel Arbeit die Entwickler glauben, dass sie innerhalb des Sprints bequem liefern können.
Lösung 1 kommt von der PO, die mit Stakeholdern spricht und versteht, was den größten Wert liefert. Lösung 2 kommt von den Entwicklern, die ihre eigenen Kapazitäten und Fähigkeiten verstehen.
Story Points sind ein Werkzeug, um dieses Verständnis zu erleichtern, indem sie einen Vergleichspunkt zwischen der Arbeit, die das Team bereits geleistet hat, und der Arbeit, die sich noch im Backlog befindet, bieten. Sie lassen sich nicht genau in Zeit- oder Aufwandsmaße übersetzen, und sie sind insgesamt viel nützlicher - zwei Mitglieder des Teams sind sich möglicherweise nicht einig, ob ein PBI 1 oder 2 Story Points ist, aber sie sind sich eher einig, ob a Sammlung von PBIs beträgt 40 oder 80 Story Points (und was noch wichtiger ist, sie sind sich wahrscheinlich einig, ob letzteres für einen Sprint zu ehrgeizig ist).
Als solche werden Story Points immer spekulativ sein und sie werden immer relativ zu anderen PBIs gemessen und sie werden immer subjektiv sein, aber hoffentlich wird es im Team einen allgemeinen Konsens darüber geben, wie viele PBIs in den Sprint davor passen können beginnt wackelig auszusehen. Wenn es keinen Konsens gibt, brauchen Sie kein genaueres Maß für den Umfang der Arbeit, Sie müssen sich bemühen, die Unterschiede zu verstehen und zu lösen (z. B. durch eine Diskussion, um einen Teil der Komplexität aufzulösen, Teile abzubrechen mit größerer Unsicherheit, Verwendung von Praktiken wie Paarprogrammierung, um Wissen innerhalb des Teams zu teilen usw.).
Um eine Analogie zu verwenden: Wenn ich 1000 Dateien unterschiedlicher Größe über mehrere Pfade von einem Server auf einen anderen kopieren möchte, muss ich nicht unbedingt wissen, dass eine Datei 1,44 MB und eine andere 1,43 MB groß ist, aber es könnte hilfreich sein zu wissen dass die größte Datei etwa 1 TB und die kleinste etwa 1 MB groß ist. Ich muss auch nicht wissen, dass die Übertragung der 1-MB-Datei auf Verbindung A genau 0,5 s dauert, aber 0,6 s auf Verbindung B, aber ich möchte wahrscheinlich wissen, dass die Gesamtbandbreite etwa 20 Mbit / s beträgt. Und noch besser, wenn ich die Dateiübertragung in Blöcken einrichten kann, damit ich nicht versehentlich versuche, die 1-TB-Datei über die langsamste Verbindung zu senden, und lange warten muss, bis sie fertig ist, nachdem alles andere bereits übertragen wurde.
Was Sie fühlen, ist normal, wenn ein neues Team an den Start geht oder Sie frisch in ein Team einsteigen.
Die aktuelle (2020) Version des Scrum Guides erwähnt nicht einmal mehr Story Points oder Aufwand; Am nächsten kommt es diesem Thema in einem kurzen Klappentext im Abschnitt Sprint-Planung:
Die Auswahl, wie viel innerhalb eines Sprints abgeschlossen werden kann, kann eine Herausforderung darstellen. Je mehr die Entwickler jedoch über ihre bisherige Leistung, ihre bevorstehende Kapazität und ihre Definition of Done wissen, desto sicherer werden sie in ihren Sprint-Prognosen sein.
IIRC, das war früher anders. Als ich vor vielen Jahren meine Scrum Master-Zertifizierung gemacht habe, wurde definitiv über Story Points gesprochen, wir bekamen unsere Planning Poker-Karten und es wurde viel darüber gesprochen, wie man eine tatsächliche Zahl für jede Story erreicht. Ich erinnere mich, dass viel Wert darauf gelegt wurde, dass die Story Points nicht direkt nach Aufwand (dh Zeit oder Geld) skaliert werden sollen, aber es war unklar, was sie sind.
In jedem Scrum- oder anderweitig agilen (dh Kanban, Scrumban, Zombie-Scrum, Scrum-but, ...) Projekt, an dem ich jemals beteiligt war, verwendeten die Teams eine andere Methodik und einen anderen Maßstab für den Aufwand für jede Geschichte. T-Shirt-Größen, Fibonacci-Zahlen usw. Dahinter steckt keine Magie. Für mich ist die einzige Bedeutung der Fibonacci-Zahlen, dass sie die Anzahl der zu wählenden Zahlen reduzieren, dh Diskussionen darüber, ob die Geschichte 11 oder 12 Punkte "wert" ist, beseitigen, während sie etwas granularer sind als gerade Exponentialzahlen 2, 4 , 8, 16, 32...
Am Ende des Tages spielt es keine Rolle. Nach einigen Sprints hat jedes Teammitglied eine Vorstellung davon, was die Zahlen bedeuten. In einem meiner aktuellen Projekte denken wir, dass 13 oder 15 Punkte ungefähr die Menge an Arbeit sind, die ein Mitglied pro Sprint leisten kann; Wir vermeiden Geschichten mit mehr als 8 Punkten (wenn wir denken, dass sie größer sind, teilen wir sie in mehrere kleinere auf). In anderen Projekten verwenden wir S, M, L, XL ohne besondere Zuordnung zur tatsächlichen Zeit.
Das Agile Manifest erwähnt Aufwand, Zeit, Geld oder Story Points überhaupt nicht und kann auch als Inspiration dienen, warum dies im agilen Kontext so sein mag.
Es gibt keine besonders nützliche Möglichkeit, Story Points in die anderen von Ihnen erwähnten Dimensionen (Volumen, Risiko, Komplexität ...) umzuwandeln. Es ist völlig in Ordnung, es etwas nebulös zu lassen. Wenn Ihr PO oder jemand anderes zufällig ein getarnter PL ist, steht es ihm frei, die Kosten des Teams in Arbeitsstunden/Geld durch die Geschwindigkeit zu teilen, um zu einem Preis von €/Punkt zu kommen, wenn es ihn glücklich macht, aber diese Art Diskussionen sollten besser nicht dort stattfinden, wo es irgendein Teammitglied hört, da es nur die Sache verwirrt und ein Rückschritt in die "gute alte" voragilen Zeit ist.
TLDR: Aus Erfahrung drückt ein Team die Schwierigkeit oder Komplexität einer Aufgabe mit Story Points aus. Ein möglicher Zweck von Story Points ist es, eine grobe Einschätzung darüber zu erhalten, ob ein Sprint-Backlog angesichts der Kapazität in diesem Sprint angemessen ist; und für das Team, diese Dinge an den Product Owner zu kommunizieren, ohne jemanden mit Zeit oder Geld zu belasten. Es ist nicht so wichtig, wenn man bedenkt, dass der offizielle Scrum-Leitfaden sie so gut wie vollständig aus seiner zentralen Broschüre entfernt hat und das Agile Manifest und andere reinere agile Schemata sich bemühen, diese Dinge aus dem Prozess herauszubekommen.
Mir ist aufgefallen, dass ich mich nicht ganz wohl dabei fühle, eine „Story Point“-Schätzung abzugeben, weil es zu spekulativ erscheint.
Ich stimme den anderen Antworten zu, aber ich dachte, ich würde eine etwas andere Einstellung anbieten. Basierend auf dem obigen Zitat geht es nicht um Story Points, sondern um Ihr Unbehagen, eine Schätzung ohne ein festes mathematisches Modell anzubieten.
Aber Story Points sollen zwei Dinge tun
Die große Versuchung des PM besteht darin, unsere Aufgabe, die Dauer zu schätzen, mit der Fähigkeit, die Dauer zu kontrollieren, zu verwechseln. Wir müssen uns darauf verlassen, dass das Team die Dauer schätzt und diese Schätzung einhält. Wir mögen mathematische Modelle und solide Grundlagen; Teams neigen dazu, genau das Gegenteil zu bevorzugen.
Hylle