Agile Story Points vs. Stunden: So schätzen Sie die Softwareentwicklung besser ein

Es kann schwierig sein, sich mit Softwareentwicklungsprozessen zu beschäftigen. Wenn Sie eine Idee haben und damit an Entwickler herantreten, fragen Sie sich zunächst, wie viel die Implementierung kosten wird und wie lange die Erstellung dauert . Die Schätzung ist einer der ersten Schritte in der App-Entwicklung.

In diesem Artikel vergleichen wir die beiden beliebtesten Schätzmodelle in der modernen Softwareentwicklung: Agile Story Points vs.

Lesen Sie weiter, um zu erfahren, wie Sie Zeit in Agile schätzen, erhalten Sie den Kern der beiden Schätzmodelle, verstehen Sie ihre Unterschiede und sehen Sie, warum Entwickler sich für eines entscheiden könnten.

Stunden sind ziemlich einfach zu verstehen und seit langem das wichtigste Schätzmodell in der Softwareentwicklung. Stunden, auch als Mannstunden oder Arbeitsstunden bezeichnet, sind die Stunden, die ein Entwickler für das Projekt aufwendet.

Was sind also Story Points und warum sind sie entstanden, wenn wir bereits ein einfaches und unkompliziertes Schätzmodell haben?

Inhalt:

1. Was genau sind Storypoints?
2. So werden Story Points in Agile berechnet
3. Vorteile der Schätzung in Story Points
4. Nachteile der Schätzung in Story Points
5. Vorteile der Schätzung in Stunden
6. Nachteile der Schätzung in Stunden
7. Können Sie Story Points in Stunden umwandeln?
8. Story Points vs. Stunden: Was ist für die Softwareentwicklung zu wählen?

Was genau sind Storypoints?

Story Points sind ein in Agile und Scrum natives relatives Schätzmodell. Sie schätzen den Aufwand für die Entwicklung eines Produkts, indem sie drei Aspekte der Entwicklung adressieren:

• der Arbeitsaufwand, den das Produkt erfordert

• die Komplexität der Produkteigenschaften

• Risiken und Unsicherheiten, die die Entwicklung beeinflussen könnten

Ganz zu Beginn der Projektbewertung wählen Entwickler die kleinste und einfachste User Story eines Produkts aus – zum Beispiel eine Sign-Up User Story – und legen sie als 1-Punkt-User Story fest. Das ist die Basisgeschichte : eine User Story, die für Komplexitätsvergleiche verwendet wird. Allen anderen User Storys wird eine Anzahl von Story Points zugewiesen, je nachdem, wie komplex sie im Vergleich zur Basisstory zu entwickeln sind.

Sieht oberflächlich ganz einfach aus, aber wer entscheidet über die Anzahl der Story Points in jeder Story?

So werden Story Points in Agile berechnet

Wie bei den Stunden schätzen die Leute, die an dem Produkt arbeiten, normalerweise Story Points für die Entwicklung. Bei Story Points ist der Schätzprozess jedoch etwas anders.

Um einer User Story Story Points zuzuordnen, sind mehrere Entwickler beteiligt. Es sollten mindestens zwei sein, aber das Unternehmen kann alle seine Entwickler bitten, einen Beitrag zu leisten, indem sie das spielen, was die Branche Planning Poker nennt. Hier die Spielregeln:

1. Jeder Entwickler erhält einen Satz Planning Poker-Karten.

2. Entwickler wählen eine User Story aus und diskutieren deren Komplexität und den erforderlichen Entwicklungsaufwand.

3. Jeder Entwickler legt eine Karte vor, die der Anzahl der Punkte entspricht, die er der Geschichte zuordnen würde.

4. Wenn die Story-Punkt-Schätzungen gleich sind, wird der Story die geschätzte Anzahl von Punkten zugewiesen.

5. Weichen die vorgeschlagenen Story Points voneinander ab, diskutieren die Entwickler die User Story, bis sie eine Anzahl von Punkten finden, die von der Mehrheit angenommen werden.

6. Entwickler wählen die nächste User Story.

7. Wiederholen Sie die Schritte 3 bis 5.

Als unsere Aktivitäten alle in die Ferne gingen, wurde dieser Prozess geändert. Statt Karten und Meetings werden die Story Points in Online-Diskussionen, bei Zoom-Meetings oder in Messengern entschieden.

Es sieht ungefähr so ​​aus:

Dies bedeutet natürlich nicht, dass alle Entwickler, die an der Schätzung von Story Points beteiligt sind, an dem Projekt arbeiten werden. Ein wesentlicher Vorteil des Story-Point-Systems ist jedoch, dass es einen mehr oder weniger universellen Rahmen schafft, der nicht nur für das jeweilige Projekt, sondern auch für zukünftige Projekte mit ähnlichen Eigenschaften verwendet werden kann.

Es gibt zwei häufig verwendete Optionen zum Schätzen von Story Points. Sie können Punkte vergeben:

• mit beliebigen ganzen Zahlen (1, 2, 3… 13,14,15 usw.)

• Verwenden von Zahlen in der Fibonacci-Folge (1, 2, 3, 5, 8, 13… 55, 89, 144 usw.)

Die Fibonacci-Folge ist eine bequemere Option zur Schätzung der Entwicklung, da sie einen gewissen Spielraum für die Annäherung lässt. Das numerische Ordnungsmodell ist für bequeme Vergleiche etwas zu präzise.

Wenn die User Story während der Entwicklung und zwischen Projekten mehr oder weniger komplex ist als ursprünglich geschätzt, können zugewiesene Story Points geändert werden.

Vorteile der Schätzung in Story Points

Wenn das Zuweisen von Story Points etwas komplex aussieht, lassen Sie sich davon nicht abschrecken. Die Kapazitätsplanung mit Story Points hat Vorteile.

1. Story Points sind entwicklerunabhängig

Story Points für jede Story werden von mehreren Entwicklern in Verhandlungen vergeben , und das liegt daran, dass die Anzahl nicht nur für ein bestimmtes Produkt und einen bestimmten Entwickler vergeben wird, sondern „im Durchschnitt“. Warum ist das gut?

Dinge passieren. Manchmal kann der Entwickler Ihres Projekts Ihr Projekt verlassen und ersetzt werden. Vielleicht werden sie krank, entscheiden sich für Elternzeit oder ein Sabbatical oder verlassen einfach das Unternehmen. Vielleicht erweisen sie sich als unter- oder überqualifiziert für das Projekt.

Wenn sie ersetzt werden, hat ein neuer Entwickler möglicherweise eine andere Arbeitsgeschwindigkeit , was dazu führt, dass die Arbeitsstunden , die zum Erstellen des Produkts erforderlich sind, neu geschätzt werden.

Story Points minimieren dieses Problem . Sie wurden von mehreren verschiedenen Entwicklern zugewiesen und bieten einen allgemeinen Überblick darüber, wie komplex eine bestimmte User Story ist. Story Points funktionieren für alle Entwickler in einem bestimmten Unternehmen. (Bitte beachten Sie jedoch, dass die Schätzungen der Story Points für verschiedene Unternehmen nicht korrekt sind.)

2. Story Points erleichtern die Neuberechnung der Entwicklungszeit

Bei der agilen Zeitschätzung mit Story Points verwenden Teams den Begriff Velocity, um sich auf die Anzahl der Story Points zu beziehen, die in einem einzelnen Sprint veröffentlicht werden.

Teams überwachen ständig ihre Geschwindigkeit, und sie ist zu Beginn ziemlich variabel. Ein Team kann in einer Woche Features im Wert von fünf Story Points und in der nächsten zwanzig Story Points veröffentlichen. Aber das ist nur am Anfang. Mit fortschreitendem Projektverlauf gleicht sich die Geschwindigkeitskurve aus .

Wenn sich ein Teammitglied bei Stunden ändert, muss jede Aufgabe, an der es beteiligt ist, neu geschätzt werden, um die Fristen anzupassen. Bei Story Points ist dies unnötig – das Team kann die Projektfrist nach dem nächsten Sprint anpassen, indem es die Änderung der Gesamtgeschwindigkeit kennt.

Story Points bewerten die Teamleistung als Ganzes und machen eine Neubewertung nach Aufgabe überflüssig.

3. Story Points sind gut, um die Teamleistung zu überwachen

Wenn Teams zu unterschiedlichen Zeiten an ähnlichen Projekten und/oder Aufgaben arbeiten, kann Ihnen Velocity leicht den Fortschritt jedes Teams anzeigen. Haben sie sich verbessert und um wie viel? Welches Team oder Entwickler hat Schwierigkeiten und benötigt möglicherweise zusätzliches Training? Wie ist die Lernkurve? Vielleicht schneidet ein anderes Team besser ab?

Velocity ist ein großartiges Werkzeug, um die Leistung Ihres Teams nicht nur vor Ort, sondern kontinuierlich zu bewerten.

4. Die Schätzung der Startzeit mit Story Points ist genauer

Durch das Tracking der Velocity weiß das Team mit hoher Präzision, wie viele Story Points es in einem Sprint freigeben kann. Das App-Entwicklungsteam benötigt zwar einige Zeit, um die Geschwindigkeit zu berechnen, aber sobald sie berechnet wurde, ist das voraussichtliche Startdatum leicht vorherzusagen .

Darüber hinaus verursachen Änderungen bei Teammitgliedern, Anforderungen oder der Anzahl/Komplexität von Funktionen nicht viele Probleme mit der Neubewertung.

5. Sie können Story Points für zukünftige Projekte wiederverwenden, um die Schätzung zu beschleunigen

Es ist nicht ungewöhnlich, dass ein Unternehmen in einer bestimmten Nische (oder mehreren) gut versiert ist und mehr als ein Produkt mit ähnlichen Funktionen entwickelt. Nach Abschluss auch nur eines in Story-Punkten geschätzten Projekts können sich Entwickler für neue Projekte auf diese Schätzung beziehen . Dies verkürzt die Zeit für die Schätzung.

Es ist jedoch wichtig, die Geschwindigkeit für jedes Projekt zu verfolgen, da sich die Umstände ändern können.

6. Story Points verbessern die Teamarbeit

Traditionell haben Entwicklungsunternehmen mehrere Entwicklerteams, die jeweils an separaten Projekten arbeiten. Bei der Schätzung in Stunden ist es der Entwickler, der an dem Projekt arbeitet, der eine Schätzung vornimmt. Das ist im Allgemeinen eine gute Sache, denn wer weiß besser, wie lange etwas dauert als die Person, die es tut?

Die Schätzung der Komplexität in Story Points bietet Entwicklern im gleichen Bereich jedoch die Möglichkeit, zusammenzuarbeiten – etwas, das sonst selten vorkommt. Diese Art der Teamarbeit bietet eine gute Gelegenheit, Erfahrungen auszutauschen und sich gegenseitig zu motivieren.

Nachteile der Schätzung in Story Points

Es gibt immer die andere Seite des Arguments, nämlich wie großartige Systeme geboren werden. Die komplexitätsbasierte Schätzung hat auch ihre Nachteile , und jedes Team muss für sich selbst entscheiden, ob es die Vorteile überwiegt.

1. Story Points sollten von mehr als einem Entwickler zugewiesen werden

Das Verkaufsargument des Story-Point-Modells ist seine Objektivität und sein Wert für zukünftige Schätzungen. Aber damit das stimmt, muss die Schätzung von mehr als einem Entwickler durchgeführt werden . Für kleine Unternehmen mit einem einzigen Team oder Unternehmen, in denen es nur einen Spezialisten auf einem Gebiet gibt (dh nur einen Designer oder iOS-Entwickler), bringen Story Points nicht so viele Vorteile. Solche kleinen Unternehmen wählen traditionell die Arbeitsstunden als Schätzmodell.

2. Die Schätzung in Story Points erfordert einen erheblichen Rückstand

Um das volle Potenzial von Story Points auszuschöpfen, muss Ihr Team viel Zeit aufwenden . Wenn Sie an einem Projekt mit Funktionen arbeiten, an denen das Team noch nie gearbeitet hat (oder nicht in Vollzeit gearbeitet hat), sind die ersten zwei bis drei Sprints leistungsmäßig schwer vorherzusagen. Zugegeben, je mehr Backlog-Elemente Ihre Teams haben, desto genauer können ihre Schätzungen aufgrund der Fülle an statistischen Daten sein. Aber Story Points ist kein System, das sofort einsatzbereit ist.

3. Story Points sind komplexer für die Budgetierung

Story Points eignen sich hervorragend, um genaue Fristen und Starttermine festzulegen, die für Entwickler und das Marketing des Kunden wichtig sein können. Wenn es um die Schätzung der Kosten für die App-Entwicklung geht, sind sie jedoch weniger bequem .

Die Sache ist die, Entwickler verbringen Zeit mit einem Projekt nicht nur mit dem Schreiben von Code (oder dem Erstellen von Designs oder dem Testen). Einige Zeit wird für Recherchen, Diskussionen – innerhalb des Teams und mit dem Kunden – für Änderungen usw. aufgewendet. Die Zeit, die für das Schätzen von Story Points aufgewendet wird, ist auch Zeit, die für das Projekt aufgewendet wird, aber sie ist nicht in den Punkten pro Story enthalten.

Die Budgetierung bei der Schätzung in Story Points ist möglich, aber es ist normalerweise schneller und einfacher, Geld mit der für das Projekt aufgewendeten Zeit gleichzusetzen.

4. Die Geschwindigkeit wird pro Team berechnet

Dies bedeutet, dass Sie, wenn Teams zwischen Projekten mischen, die Geschwindigkeit für jede Kombination von Entwicklern separat berechnen müssen. Daher gilt die Schätzung für ein Team nicht unbedingt für ein anderes Team, und selbst die Änderung eines einzelnen Teammitglieds kann frühere Schätzungen möglicherweise ungültig machen.

Andererseits können Sie die Komplexitätsschätzung verwenden, um die leistungsstärksten Kombinationen zu finden. Es wird jedoch dauern.

Vorteile der Schätzung in Stunden

Während einige agile Teams Story Points verwenden, müssen viele noch von den Arbeitszeiten umsteigen. Dafür gibt es wichtige Gründe. Lassen Sie uns sie auch behandeln.

1. Stunden ist ein bekanntes Modell

Innovation ist großartig, aber es braucht Zeit. Entwickler und ihre Kunden sind gleichermaßen mit der Schätzung der Arbeitsstunden vertraut. Für viele lautet die Idee: "Wenn es nicht kaputt ist, repariere es nicht." Solange das System praktikable Schätzungen bietet, warum zu etwas anderem wechseln?

Der Unterschied in der Genauigkeit der Schätzungen ist für einige Entwickler möglicherweise nicht groß genug, um ihre Vorgehensweise zu ändern.

2. Kunden zahlen normalerweise für Stunden

Dies bedarf nur geringer Ausarbeitung. Für Kunden kann die komplexitätsbasierte Schätzung verwirrend sein . Wenn für den Kunden außerdem das Budget wichtiger ist als das Startdatum (was oft der Fall ist), sind Story Points für ihn nicht relevant.

3. Eine stundenbasierte Schätzung kann von einem Entwickler durchgeführt werden

Für kleine Teams oder Freiberufler sind Story Points weitgehend nutzlos, da sie mehrere Sichtweisen erfordern. Ohne jegliche Referenz ist das Schätzen in Story Points ein unnötiger Aufwand.

Stunden hingegen bieten dem am Projekt arbeitenden Entwickler die Möglichkeit, selbst relativ genaue Schätzungen vorzunehmen.

Das gleiche gilt für die Teamgeschwindigkeit. Wenn sich Teams jedes Mal ändern, wie es bei Freelancern oder teilweisem Outsourcing der Fall ist, ist die Überwachung der Geschwindigkeit sehr wenig sinnvoll. Die stundenbasierte Schätzung ist hier die bessere Wahl.

Nachteile der Schätzung in Stunden

Hier sind die Gründe, warum Teams entscheiden könnten, Stunden nicht mehr als Schätzmodell zu verwenden.

1. Alleine für die Schätzung verantwortlich zu sein, bedeutet viel Druck

Einerseits kann die Einschätzung des eigenen Zeitbedarfs einfacher sein, da Sie sich nur auf sich selbst verlassen.

Auf der anderen Seite ist es ein schwerer Schlag, wenn Sie Ihre Schätzungen nicht einhalten. Dies gilt umso mehr, wenn das Team, das darauf wartet, seine Aufgaben zu beginnen, darauf angewiesen ist, dass Sie Ihre Aufgaben erledigen.

Darüber hinaus kann der Stress, der durch den Druck verursacht wird, das zu liefern, was Sie selbst versprochen haben, eine ansonsten gut laufende Aufgabe stören.

2. Die Schätzung eines Entwicklers ist immer weniger genau als die eines Teams

Individuelle Schätzungen sind subjektiv und an die emotionalen und psychologischen Umstände des Schätzers gebunden.

Einige Entwickler neigen dazu, sich selbst zu überschätzen und Zeitrahmen festzulegen, die sie später nur schwer einhalten können. Dies stört nicht nur die Entwicklung (und verursacht bei Bußgeldern zusätzliche Kosten für das Team), sondern verursacht auch Stress und Burnout bei den Entwicklern .

Andere unterschätzen ihre eigenen Fähigkeiten und verlängern die Entwicklung mehr als objektiv notwendig. Unsicherheit und die Angewohnheit, Arbeit zu überdenken, zu überprüfen und erneut zu überprüfen, führen oft dazu, dass Entwicklungsfristen auf spätere Termine gesetzt werden – und Aufgaben werden selten vor Fristende abgeschlossen . Der Input des Teams ermöglicht eine objektivere Einschätzung.

3. Je größer die Aufgabe, desto schwieriger ist die Stundeneinschätzung

Dies korreliert auch mit Nichtentwicklungssituationen. Es ist leicht zu sagen, wie lange es dauert, eine dreiseitige Universitätsbroschüre zu lesen, aber schwerer einzuschätzen, wie lange es dauern wird, um Krieg und Frieden zu beenden.

Das gleiche gilt für die Entwicklung. Kleine Aufgaben sind für Entwickler mit etwas Erfahrung leicht abzuschätzen . Je größer die Aufgabe jedoch, desto mehr Dinge – die sowohl innerhalb als auch außerhalb des Projekts passieren – können die Entwicklung beeinflussen. Stundenbasierte Schätzungen bieten nicht die Margen, die Story Points haben, was die Schätzungen rauer macht.

4. Wenig Flexibilität

Die stundenbasierte Schätzung ist entwicklerbasiert. Wenn ein Teammitglied, das an dem Produkt arbeitet, während des Projekts ändert, muss das Team jede betroffene User Story neu berechnen, die sich noch in der Entwicklung befindet oder für zukünftige Sprints geplant ist. Das kann viel Arbeit bedeuten, je nachdem, in welcher Phase sich das Projekt befindet und wie unterschiedlich die Fähigkeiten zwischen dem ursprünglichen und dem neuen Entwickler sind. Die stundenbasierte Zeitschätzung ist ziemlich starr.

Können Sie Story Points in Stunden umwandeln?

Kunden können ein Team, das Schätzungen in Story Points vornimmt, bitten, die Zuordnung von Agile Story Points in Stunden umzuwandeln . Die meisten Leute, die nicht mit den neuesten Softwareentwicklungstrends vertraut sind, wissen nicht, was sie von Story Points halten sollen.

Wenn ein Kunde jedoch fragt, wie viele Stunden ein Story Point entspricht, ist es unmöglich, definitiv zu antworten. Eine der Schlüsselkomponenten der komplexitätsbasierten Schätzung ist der Aufwand, der aufgewendet wird, um die Story zu vervollständigen. Aber Aufwand bedeutet nicht direkt Zeitaufwand . Stunden sprechen Unsicherheit vage an als Story Points.

Je komplexer die Aufgabe, desto mehr Unsicherheiten und Risiken bestehen. Die einfache Umrechnung von Story Points in Stunden und das alleinige Verlassen auf die Geschwindigkeit berücksichtigt viele dieser Risiken nicht, da die stundenbasierte Schätzung in Bezug auf Risiken und Unsicherheiten näherungsweise ist als Story Points .

Bis zu einem gewissen Grad wird die Verwendung der Fibonacci-Folge bei der Zuweisung von Story Points die Unsicherheit in den Entwicklungszeiten berücksichtigen, aber sie ermöglicht nicht genau eine direkte Konvertierung.

Hier ist ein Beispiel.

Eine einstöckige Punktgeschichte (Basisgeschichte) dauert, sagen wir, zwei Stunden.

Eine 13-stöckige Point-Story kann im besten Fall 26 Stunden dauern – wenn nichts schief geht oder im Weg steht. Wenn beispielsweise die verwendete API nahtlos von Endpunkt zu Endpunkt passt. Aber wenn dies nicht der Fall ist, kann die Geschichte zwischen 30 und 50 Stunden dauern – je nachdem, wie viele Diskrepanzen es gibt. Niemand kann vorher sagen, wie es weitergeht, wenn der Entwickler noch nicht mit der betreffenden API gearbeitet hat.

Bei der Übersetzung von Story Points in Stunden muss es also einen Multiplikator für exponentielles Wachstum geben , um die Unsicherheit zu bewältigen. Und dieser Multiplikator wird sich von einem Team zum anderen unterscheiden.

Story Points vs. Stunden: Was ist für die Softwareentwicklung zu wählen?

Wie Sie sehen können, sind sowohl Story Points als auch Stunden gültige Entscheidungen für einen Entwickler, um Projekte zu schätzen.

Alles in allem würden wir sagen, dass sich mehr Produktunternehmen für Story Points entscheiden, während Outsourcer eher zu Stunden neigen.

Unternehmen, die mit einem Festpreismodell arbeiten, gehen in der Regel zu einer stundenbasierten Schätzung. Teams, die Scrum bevorzugen, wählen oft Story Points, da sie buchstäblich aus Scrum geboren wurden und in dieser Methodik gebürtig sind.
In unserer langjährigen Erfahrung sehen wir das so:

• Wenn es wichtiger ist, das Startdatum genau zu schätzen, als das Budget anzupassen, sollten Sie sich für Story Points entscheiden.

• Wenn das Budget wichtiger ist als ein genaues Startdatum, ziehen Sie Stunden in Betracht.

Oder kombinieren Sie am besten beides.

Story Points sind sehr praktisch für Entwicklungsteams, die an langen Projekten arbeiten, bei denen die Überwachung der Geschwindigkeit einen Unterschied macht.

Stunden sind wichtig für Kunden, die sich Sorgen machen, ihr Budget zu sprengen. Außerdem sind Stunden bei kurzfristigen Projekten sinnvoller.

Das komplexitätsbasierte System ist noch relativ jung, ebenso wie Scrum selbst, und es befindet sich noch in der Entwicklung. Die Kombination beider Schätzmodelle und die Ausarbeitung eines Systems zum schnellen Ändern jedes Story-Points in Stunden bietet Vorteile beider Modelle, während die Nachteile minimiert werden.