Warum Story Points statt Stunden zum Schätzen verwenden?

Die Verwendung von Punkten ist eine Version dessen, was oft als „ relative Größenbestimmung “ bezeichnet wird. Für eine sehr empfehlenswerte erste Perspektive schauen Sie sich dieses Video an und kommen Sie dann zurück. Die meisten Anwendungen der Story-Point-Schätzung beschränken Sie auf das untere Ende der Fibonacci-Reihe: 1, 2, 3, 5, 8, 13, da das Ziel darin besteht, Dinge mit ähnlicher Gesamtgröße zu gruppieren, anstatt eine hochpräzise Schätzung zu verfolgen.

Story Points berücksichtigen beim Schätzen oft drei verschiedene Aspekte: Komplexität, Aufwand und Zweifel. Auf diese Weise können sie die Quellen von Schwankungen, die eine stundenbasierte Schätzung falsch machen, effektiver erfassen.

Komplexität ist das „Zeug, das wir herausfinden müssen“. Wir wissen, dass wir das Problem lösen können, und wir haben wahrscheinlich ein gutes Gefühl dafür, wie wir es angehen werden, aber wir müssen es immer noch herausfinden.

Anstrengung ist die schiere Menge an Dingen, die erledigt werden müssen. Für mich ist dieses Beispiel das Konfigurieren von SharePoint-Listen, weil ich genau wusste, wie ich alles lösen musste, und ich wusste, wie viele es waren, aber es dauerte trotzdem Zeit, sie durchzugehen.

Bei Zweifeln geht es um Dinge, von denen wir eigentlich nicht wissen, ob sie machbar sind. Wir vermuten vielleicht, dass wir auf dem falschen Weg sind, dass die Technologie dem nicht gewachsen ist, oder ein anderer Faktor, der uns eine Weile abwandern lassen würde, bevor wir herausfinden, ob wir die Arbeit tatsächlich erledigen können.

Die meisten Geschichten enthalten eine Kombination aus allen dreien, und daher ist es nützlich, eine gemeinsame Sprache zu haben, damit ich, wenn ich sage "es ist eine Acht", mit "wegen der Komplexität des foobar-Algorithmus" oder "weil ich es nicht bin" folgen kann sicher, ob unser Cache schon dafür eingerichtet ist."

Die abschließende Punktschätzung ist nur eine Art zu sagen: " Wenn man all diese Dinge berücksichtigt, denke ich, dass dies größer ist als die meisten Dinge, die wir eine Drei genannt haben, und kleiner als die meisten Dinge, die wir eine Acht genannt haben. also muss es eine fünf sein "

Ich würde nicht sagen, dass die Punkte besser sind. Dies ist eine Technik, die sich auf einen anderen Aspekt der Schätzung konzentriert. Es kann sich herausstellen, dass Ihre Punktschätzung mehr saugt. Denken Sie daran.

1. Beim Schätzen in Stunden konzentrieren Sie sich auf die Beantwortung der Frage „Wie lange können wir dafür brauchen?“. Im Grunde ist es also mehr oder weniger eine Vermutung, basierend auf Ihren bisherigen Erfahrungen.

2. Wenn Sie in Punkten schätzen , konzentrieren Sie sich auf die relative Größe oder Komplexität der geschätzten Aufgaben / Geschichten / was auch immer. Also nehmen Sie normalerweise einige Ihrer Aufgaben und wenden einen der Punktwerte darauf an, und später versuchen Sie, für jede andere Aufgabe die Frage zu beantworten: "Wie groß ist sie im Verhältnis zu den bereits geschätzten?".

Das Wichtigste bei der Punkteschätzung ist, dass Sie tatsächlich messen müssen, wie sich die Schätzungen auf die Zeit beziehen. Nach einer gewissen Anfangszeit im Projekt (insbesondere wenn Sie mit Punktschätzungen beginnen) erfahren Sie, wie viele Punkte Sie in jeder Iteration oder in einem festgelegten Zeitraum liefern können. Damit haben Sie die Grundlage für die Planung zukünftiger Releases.

Wenn Sie dieses Forum durchsuchen, werden Sie auch mindestens einige Methoden zum Schätzen in Punkten finden. Probieren Sie es aus und sehen Sie selbst, ob es für Sie genauer wird.

Das Wesentliche beim Schätzen in Punkten ist, dass es auf einer relativen Größe basiert, während die Stunde ein absolutes Maß ist. Meine 10-Stunden-Aufgabe könnte Ihre 5-Stunden-Aufgabe sein, aber wir sind uns beide einig, dass das Erstellen einer normalen Benutzerregistrierungsseite im Vergleich zum Erstellen eines Warenkorbmoduls eine kleinere Aufgabe ist, sodass dieser Ansatz die Schwankungen bei den Schätzungen verringert.

Vergeben Sie Punkte basierend darauf, wie groß/komplex die Aufgabe/Geschichte ist und wie viel davon vorhanden ist, zum Beispiel gibt es eine Aufgabe, die ziemlich einfach ist, aber mehrmals erledigt werden muss, dann würde diese Aufgabe/Geschichte mehr Punkte erhalten .

Zu Beginn müssten Sie ein paar Aufgaben/Geschichten auswählen, die von mittlerer/durchschnittlicher Komplexität/Größe sind. Weisen Sie ihnen einige Punkte aus Ihrem ausgewählten Punktebereich zu (normalerweise Fibonacci-Reihen). Diese Aufgaben/Geschichten werden zu Ihren Referenzaufgaben/Geschichten. Weisen Sie nun den restlichen Aufgaben Punkte zu, je nachdem, wie komplex/groß jede Aufgabe im Verhältnis zu Ihren Referenzaufgaben ist. Größere Aufgaben erhalten mehr Punkte als Referenzaufgaben. Am Ende der Schätzungsübung (normalerweise mit Planning Poker durchgeführt) summieren Sie alle Punkte, um die geschätzte Gesamtpunktzahl für dieses Projekt zu erhalten.

Nach Abschluss einiger Projekte hätten Sie eine Historie darüber, wie viele Punkte Ihr Team in einem bestimmten Zeitintervall abdeckt. Dies ist die Geschwindigkeit des Teams. Der entscheidende Punkt dabei ist, dass Sie die Teamgröße nicht ändern. Teammitglieder können ersetzt, aber nicht bevorzugt werden.

Es geht darum, von einer falschen Realität weg zu abstrahieren.

Punkte sind besser als Stunden, weil sie alle Beteiligten, insbesondere nicht technische Beteiligte, dazu zwingen, zu verinnerlichen, dass das Erstellen Ihrer eigenen Software nicht mit dem Einkaufen von Funktionen in einem Geschäft vergleichbar ist.

Zum Guten oder zum Schlechten wollen Geschäftsbeteiligte fast immer wissen, „wie viel jede meiner Funktionen kosten wird“. Natürlich beginnen sie normalerweise mit so hochrangigen Beschreibungen von Funktionen, dass jede Preisschätzung in Stunden oder Dollar lächerlich ist.

Agilität im Allgemeinen und das Punktesystem im Besonderen zwingen die Stakeholder dazu, in den Prozess zu treten und von einer Geschäftsanfrage auf hoher Ebene zu einer iterativ verfeinerten Implementierung zu gelangen.

Wie immer gibt es auf diese Frage keine einfache Antwort. Ich würde sagen, Sie sollten wählen, was für Sie am besten funktioniert . Wie Sie jedoch sagen, funktioniert das Arbeiten mit Stunden nicht für Sie.

In meinem Team war es der psychologische Aspekt bei der Arbeit mit Punkten. Wenn die Leute in Punkten schätzen, fühlen sie sich wohler, weil es kein einfaches Maß gibt, dass 1 Punkt = 1 Stunde ist, also werden sie nicht bestraft, wenn sie mehr Zeit brauchen, um die Aufgabe zu erledigen, als sie angegeben haben.

Eine andere Sache ist, dass Sie beim Arbeiten mit Punkten (1,2,3,5,8,13,20) oder Größen (S, M, L, XL) nur die Komplexität der Aufgabe definieren. Geschwindigkeit zeigt an, wie viele Punkte Sie in die Iteration einfügen können, aber die Geschwindigkeit ändert sich .

Und das Arbeiten mit Punkten ist weniger frustrierend - wenn Sie schlecht geschätzt haben, wird Ihre Geschwindigkeit sinken.

Obwohl dies wahrscheinlich keine beabsichtigte Funktion ist, besteht einer der Vorteile der Verwendung von Punkten aus der Sicht eines Managers darin, dass Aufgaben nach Komplexität und nicht nach Zeit gemessen werden, wodurch Sie leicht erkennen können, wer im Team schneller arbeitet als alle anderen. Sie wissen zum Beispiel, dass Person A 2 Stunden braucht, um etwas zu tun, aber Person B 10 Stunden braucht (für eine bestimmte Aufgabe; vielleicht ist es für eine andere Aufgabe umgekehrt). Wenn Person A 2 Stunden geschätzt hat und dann krank war, wäre Person B 8 Stunden hinter der Schätzung zurück, bevor sie überhaupt angefangen hat. Aber wenn Sie ihm Punkte geben und dann für das Team mitteln, ist es wahrscheinlicher, dass Sie insgesamt Ihr Ziel erreichen.

Es gibt zwei Gründe, warum ich Punkte über Stunden mag.

Stunden haben eine implizite Genauigkeit und werden in der Regel als 100% genau angesehen. Alle Menschen verstehen, was eine Stunde ist. Wenn Sie also 10 Stunden sagen, müssen es zehn Stunden sein. Um dies zu kompensieren, wird der Schätzer etwas "zusätzliche Zeit" einplanen, um die Unbekannten auszugleichen. Es liegt in der Natur des Menschen, dass sie nicht für eine Schätzung verantwortlich gemacht werden wollen, wenn sie nicht über alle erforderlichen Daten verfügen.

Das Problem dabei ist, je größer die Aufgabe/Geschichte, desto größer die Komplexität und desto länger würde es dauern, eine wirklich genaue Schätzung zu entwickeln. Irgendwann lohnt es sich einfach nicht mehr. Vor allem, wenn es um Arbeiten geht, die mehrere Monate nicht erledigt werden.

Punkte hingegen haben eine „akzeptable“ implizite Ungenauigkeit, da sie nur relativ zueinander sind.

Durch die Verwendung der Fibonacci-Reihen: 1, 2, 3, 5, 8, 13 usw. ist das Team in der Lage, sowohl die Komplexität eines Projekts als auch den zu erwartenden Aufwand zu kompensieren. Wenn die Zahlen größer werden, wird die Unschärfe der Schätzung eingebaut. Es wird keine Zeit verschwendet, um festzustellen, ob es eine 9 oder 10 oder 11 ist, ob es größer ist als das, was das Team eine 8 nennt, und kleiner als das, was das Team als a bezeichnet 20, dann ist es eine 13. Je näher die Geschichte der Aufnahme in eine Iteration kommt, desto weiter wird sie zerlegt und verfeinert, und die Genauigkeit der Schätzung verbessert sich.

Durch die Verwendung dieser Methode kann die kurzfristige Arbeit mit einem hohen Maß an Sicherheit eingeschätzt werden, je weiter man im Zeitplan voranschreitet, desto mehr sinkt die Zuversicht, aber das Team hat immer noch eine gute Vorstellung von dem Aufwand, der erforderlich ist, ohne übermäßig viel Zeit mit Unterbrechungen zu verbringen eine Geschichte niederschreiben, die aufgrund sich ändernder Prioritäten möglicherweise nie fertiggestellt wird.

Jeff

Mein Team hängte sich häufig auf, wenn es darum ging, Stunden zu schätzen, um kleinste Details absolut korrekt zu finden, aber bei anderen Aufgaben wilde Vermutungen anzustellen. Das Ergebnis war eine sehr hohe Variabilität in der Lieferung von Geschichten. Als wir zu Punkten übergingen, begann das Team, Schätzungen ganzer Geschichten basierend auf der Gesamtkomplexität vorzunehmen, und ihre Geschwindigkeit wurde viel vorhersehbarer.

Geschätzte Stunden können normalerweise in Punkte umgerechnet werden, aber geschätzte Punkte können normalerweise nicht zurück in Stunden umgerechnet werden.

Seien Sie vorsichtig, sobald Sie zu Punkteschätzungen wechseln, gibt es keinen einfachen Weg zurück zur Verwendung von Stunden.

Wann würden Sie zu Punkten und anderen relativen Systemen wechseln? Wenn Stunden aufhören, für Sie zu arbeiten. Wenn Sie feststellen, dass Stundenschätzungen Ihnen keinen guten Überblick über die Zeit geben, die für die Fertigstellung eines Projekts benötigt wird, können Sie sich dennoch eine Vorstellung von der relativen Komplexität mit Punkten und anderen Systemen machen. Dadurch können Sie die Zeitdimension ignorieren und einige Informationen zur Komplexität erhalten.

Meiner Erfahrung nach muss man jedoch irgendwann auf Zeitschätzungen zurückgreifen, egal was man tut. Wenn Sie also zu Punkten wechseln, finden Sie eine Möglichkeit, auch die Zeit zu schätzen.

Das ist alles ziemlich irreführend. Tatsache ist, dass wir in unserem Kopf dazu neigen, die Punkte wieder in Stunden umzuwandeln, sobald wir unsere Geschwindigkeit kennen. Puristen können den ganzen Tag über Punkte reden, aber es sind nur Leute, die versuchen, hochmütig zu sein. Wirklich, der Schlüssel hier ist, Menschen, die schätzen, zu ermutigen, in relativen Begriffen zu denken; Dieses Projekt ist beispielsweise ungefähr so ​​komplex wie dieses Projekt und dieses Projekt hat gedauert x hours, also sollte dieses Projekt dauern y hours.

Du denkst vielleicht, dass du einen coolen Psycho-Trick abziehst, aber wenn deine Leute irgendetwas wert sind, machen sie bereits die Kopfrechnen in ihrem Kopf.

Story Points funktionieren am besten, wenn die folgenden Bedingungen erfüllt sind:

1. Die Organisation hat eine hohe Risikotoleranz, die zu Beginn eines neuen, schwer abzuschätzenden Projekts große Abweichungen zwischen Plan und Ist zulässt.
2. Teams arbeiten in einem geschlossenen System, in dem alle Teams agil und Teams stabil sind. Es werden keine Ressourcen geteilt und Teams müssen nicht mit anderen Methoden (z. B. Wasserfall) mit Teams interagieren.
3. Teams haben einen engagierten Product Owner oder Endbenutzer als Teil des Teams
4. Eine dedizierte Testressource, Automatisierung oder beides ermöglicht relativ stabile Testschätzungen
5. Das Team koordiniert die Priorisierung der technischen Schuld bei jedem Sprint zusammen mit den Prioritäten des Kunden.
6. Die Planung umfasst nur Stores, die bis zur Fertigstellung übertragen werden, oder Storys, die als „gut genug“ definiert sind, um sie zu schätzen (z. B. gute User Story, Geschäftsregeln, die universell oder spezifisch für den Akteur sind, Annahmebedingungen/Testkriterien können innerhalb von 24 Tagen nach Beauftragung festgelegt werden).
7. Nach der Planung mit dem Product Owner haben die Teams „Zeit für sich allein“ und technische Anleitung, um die Aufgaben zu besprechen und zu priorisieren.
8. Während des Sprints bewertet das Team täglich den Fortschritt, arbeitet zusammen und beseitigt Hindernisse. Teams halten sich an Aufgaben, denen sie sich verpflichtet haben.
9. Sie müssen keine standardmäßige oder traditionelle Dokumentation wie BRD oder SRS ausfüllen, bevor die Arbeit beginnen kann.
10. Projektverpflichtungen oder andere Elemente, die das Team nicht kontrollieren kann, treiben die Sprint-Priorisierung nicht voran, werden aber in die Planung miteinbezogen.
11. Teams demonstrieren und korrigieren innerhalb des Sprints als Eingaben für die Geschwindigkeit
12. Teams würdigen die mit einem Sprint abgeschlossene Arbeit, obwohl die Geschichte möglicherweise nicht vollständig ist, der Code jedoch produktionsreif ist – zumindest teilweise.
13. Die Teams nehmen sich die Zeit, Abweichungen in der Velocity zu analysieren, was sie im Nachhinein verbessern müssen, definieren einen Plan und messen ihren Erfolg.
14. Qualitativ hochwertiger, fehlerfreier Code wird pünktlich bereitgestellt, der sonst nichts kaputt gemacht hat und die Akzeptanz- und Testkriterien erfüllt und keinen Rückstand hinterlassen hat, der mit massiven Mengen an technischer Schuld übersät ist.

Wenn ein Team nicht jedes dieser Kästchen ankreuzen kann, "ja, das machen wir", wird Ihr Management zurückdrängen und ein Gleichgewicht zur Verwaltung des Geschäfts wird der nächste Schritt sein. Wie bereits in einer früheren Antwort erwähnt, sollten Teams damit beginnen, Punkte und Stunden einzuplanen, um dieses Szenario anzugehen. Das Management weiß, dass jeder Story Point einem gewissen Wert in Personenstunden entspricht. Identifizieren Sie es als Team oder seien Sie vorbereitet, wenn es für Sie durch die Geschäftsweise definiert wird.

Vor einiger Zeit schrieb ich einen relevanten Blog-Beitrag: „Stunden verbleibender Aufwand“

Das Wesentliche ist, dass wir nicht in der Lage sind, die tatsächliche Zeit zu schätzen und stattdessen denken, dass wir in „idealen Stunden“ schätzen, aber wir können nicht von der Wahrnehmung der Zeit abstrahieren. Es kann auch der falsche Eindruck erweckt werden, dass es sich bei der Anzahl der verbleibenden Stunden um „Uhrzeitstunden“ und nicht um „idealisierte Stunden“ handelt.

Ich stimme dem Kommentar Blaze ein wenig zu, aber ich werde versuchen, einen glücklicheren Fall dafür zu machen:

Um ehrlich zu sein, ist es normalerweise die Zeitdauer für eine Aufgabe, an der Sie interessiert sind, sodass Sie abschätzen können, wie lange zukünftige Projekte ähnlicher Komplexität dauern werden.

So verwenden Sie am Ende die Geschwindigkeit wie erwähnt. Nach ein paar Entwicklungsiterationen, die x Zeit in Anspruch nehmen und y Punkte zugewiesen haben, können Sie Ihre Geschwindigkeit ermitteln und diese dann verwenden, um für die Zukunft zu planen.

Es ist eine großartige Sache, dies tun zu können, und ein wirklich nützliches Tool für Entwickler, Management und Product Owner.

Story Points funktionieren aufgrund der Denkweise der Methode am besten in Scrum.

Meiner Erfahrung nach ist Scrum eine der wenigen Methoden, die dies zulässt, denn in Scrum muss das Management die Hände frei haben. Scrum gibt dem Entwicklungsteam eine gewisse Freiheit, alle Backlogs ohne Einmischung des Managements (und der PMs) bis zum Ende des Sprints abzuschließen. Die Frage, wie lange die Entwicklung einer einzelnen Story dauern wird, ist also irrelevant.

Zum Beispiel benötigt Story A schätzungsweise etwa 5 Story Points, und die Gesamtzahl der Story Points im nächsten 2-Wochen-Sprint beträgt etwa 20. Wenn Sie als PM wissen müssen, wie lange Story A bis zum Abschluss brauchen wird, nun ja. 2 Wochen ist Ihre Antwort. Parallel zu den anderen Stories im Sprint.

Am Ende können Sie immer versuchen, das Verhältnis von Manntagen pro Story Point zu berechnen. Im obigen Fall benötigen 20 Story Points 2 Wochen (10 Tage). Das heißt, es könnte 5 Story Points dauern, die Aufgabe dauert 2,5 Tage. Aber in Scrum packen Sie die Freigabe nicht nach 2,5 Tagen. Sie müssen warten, bis der Sprint beendet ist, was 2 Wochen sind. Was das Verhältnis von Manntagen pro Story Point ziemlich unbrauchbar macht.

Vergessen Sie nicht, dass Sie als PM die Geschwindigkeit des Teams überwachen und sicherstellen müssen, dass das Team über eine konstante Gesamtmenge an Story Points verfügt, um an jedem Sprint zu arbeiten.

Das Punktesystem basiert auf dem Verhalten des „Chunking“ und während es die Leute dazu bringt, am Ende des Tages die Gesamtdauer vs Sequenzvorhersage sehen oder nicht).

Es gibt hier ein Gefahrenelement, da ich sehe, dass viele Teams davon ausgehen, dass sie die Entwicklung "auf den Kopf gestellt" haben, sie haben endlich das Geheimnis der Vorhersage durch Mathematik geknackt! - Es ist ein Fehlalarm, denn wenn jemand eine Geschichte mit "klein" (Ansatz in T-Shirt-Größe) zuweist und diese Person dann 20 Aufgaben dekomprimiert, um diese Geschichte zu vervollständigen, dann weist jede dieser Aufgaben der Gleichung immer noch Zeitvariablen zu.

Das ist keine schlechte Sache, da alle Chunking-Sequenzen Parameter dafür festlegen, wie viel das Team nicht nur in Bezug auf Investitionen in die Aufgabe „erlaubt“, sondern auch in Bezug auf die Arten von Entwicklerfähigkeiten, die erforderlich sind, um die Aufgabe zu erfüllen.

Als Teammanager müssen Sie immer noch Zeit + Aufgabe kennen, und es geht nicht darum, einen Entwickler dafür zu bestrafen, dass er sein Zeitbudget nicht einhält. Es ist eher eine Möglichkeit, ihr Wachstum zu überwachen oder ihnen zu helfen, ein besseres Kommunikationsverhalten zu fördern – „Sam bittet nicht gern um Hilfe“, so dass es der Führungskraft ermöglicht, das Verhalten zu rehabilitieren in Richtung „Sei ok mit Misserfolg, Misserfolg lehrt dich die Lektionen des Lebens". Es ermöglicht Ihnen auch, einen Junior-Entwickler mit einer Senior-Aufgabe zu beauftragen, weil Sie sehen möchten, wie gut er abschneidet ... ja, er wird die Schätzungen des Punktesystems überschreiten, aber das ist Teil des Trainings für das Jobwachstum und so weiter.

Wie gesagt, Sie können die Prognosemodellierung mit Abstraktionstechniken wie dem Punktesystem "spielen", aber wenn es um die Zuordnung und sogar um die Geschwindigkeit geht, lauert die Zeit immer noch. Das ist der Grund, warum die meisten Teams die x-Anzahl von Wochen als Sprint bezeichnen, wenn es aber wirklich eine abstrakte Methodik wäre, wäre es „dies ist ein 45-Sprint und der nächste ist ein 24-Sprint“ oder so ähnlich … der Sprint wäre in Länge und Zeit variabel sein. Stattdessen befinden Sie sich in dieser kognitiven Dissonanz um die schnöde Abstraktion von Punkten in die relative Zeit? aber willkürliche Basislinien verwenden, um die Daten irgendwie zu quantifizieren?

Ein weiterer Punkt, der hinzugefügt werden muss, ist, dass das Team die Arbeit oft im Voraus schätzt. Zeitbasierte Schätzungen gelten speziell für die Personen, die die Arbeit erledigen. Die relative Größe (Story Points mit Planning Poker) ist die Größe des Teams. Es ist nicht personenspezifisch.

Grundsätzlich sind Zeit- und Storypunkte nicht gleichwertig .

Punkte fügen aus psychologischen Gründen eine Abstraktion von der Zeit hinzu, implizit um Programmierer-Burnout zu verhindern. Irgendjemand muss die Abstraktion noch in einen Zeit-/Finanzaufwand umwandeln. Es geht einfach in der Kette nach oben, bis jemand bereit ist, die Verantwortung dafür zu übernehmen.

Meine eigene Ansicht ist, dass Burnout bei Programmierern nicht durch den Versuch einer rechtzeitigen Schätzung verursacht wird, sondern durch unangemessene Reaktionen des Managements, wenn Dinge länger als erwartet dauern.

Wenn Sie sich Abstraktionen ausdenken, um eine wirtschaftlich brauchbare Schätzung zu vermeiden, weil Sie so viel Angst vor Bestrafung haben, liegt das Problem in Ihrer Managementkultur.

Es ist besser, ein unterstützendes Umfeld zu haben, in dem aufrichtige und hart arbeitende Menschen einige Fehler machen, aber wo es transparentes Feedback gibt, anstatt abstrakte Schichten hinzuzufügen, damit sie sich nicht mit Realitäten wie „Ich dachte, das würde einen Tag dauern“ auseinandersetzen müssen und es hat über eine Woche gedauert'. Meiner Meinung nach behandelt man Ingenieure wie Kinder.

Die kurze Antwort wäre, dass "Stunden bestenfalls nur geschätzt werden können". Aber wenn Sie sich Story-Points ansehen – nennen Sie sie, wie Sie wollen –, betrachten Sie die Aktivitätskarte (und die natürlich vorkommenden Abhängigkeiten innerhalb dieser Karte), die letztendlich dazu führen werden, dass diese abrechenbaren Stunden ausgegeben werden.

Insbesondere "Computersoftware" ist ein Rattennest ineinandergreifender Abhängigkeiten. Wenn Sie die Software auf diese Weise aus funktionaler Sicht untersuchen, möchten Sie wirklich die Komplexität und gegenseitigen Abhängigkeiten aufdecken, die ein Projekt so oft auf einen "Todesmarsch" bringen.

Story Points sollten nicht für die Projektplanung verwendet werden. Es gibt keinen Zweck. Schätzungen sollten in Mannwochen oder Mannmonaten erstellt werden. Story Points stellen nicht ohne Weiteres Informationen dar, auf die reagiert werden kann. Eine Geschichte wird mit 10 gewichtet. Was ist 10? Sind das 10 für 1 Person, sind das 10 für 100 Entwickler, die an dem Projekt arbeiten?

Die Verwendung von Mannwochen ist einfach.

Am Ende ist die Schätzung, ob es um Punkte oder Zeit geht, eine Schätzung. Sie basiert auf der Erfahrung der Person, die die Schätzung erstellt hat. Indem Sie die Zeit direkt verwenden, haben Sie eine viel bessere Möglichkeit, den Erfolg Ihrer Schätzungen zu messen. Der Vergleich von Story Points mit Story Points ist bestenfalls verschwommen und im schlimmsten Fall bedeutungslos.

Zu guter Letzt, wie baut man ein System mit Story Points auf? Wie viele Teammitglieder brauchen wir? Wann wird es fertig sein? Zeit und Geld sind Geschäft. Die Projektplanung soll dem Unternehmen Informationen darüber geben, wie es seine Zeit und sein Geld am besten einsetzt, Story Points sind beides nicht.