Story Points vs. Function Points, was ist der Unterschied und warum ist er wichtig? Story Points sind willkürliche Indikatoren für den erwarteten Aufwand. Sie sind inkonsistent und für die Verwendung als primäre Metrik in Softwareprojekten ungeeignet. Wir empfehlen Ihnen, auf ISO-Standard-COSMIC-Funktionspunkte umzusteigen und 14 Gründe dafür anzugeben.
Story Points vs. Function Points, was ist der Unterschied und warum ist er wichtig? Story Points sind willkürliche Indikatoren für den erwarteten Aufwand. Sie sind inkonsistent und für die Verwendung als primäre Metrik in Softwareprojekten ungeeignet. Wir empfehlen Ihnen, auf ISO-Standard-COSMIC-Funktionspunkte umzusteigen und 14 Gründe dafür anzugeben.
Was sind Story Points?
In agilen Softwareprojekten ist ein Story Point (SP) der vereinbarte Aufwand eines Teams für die Erledigung einer Arbeit. Aufgaben werden anhand der Anzahl der SP geschätzt, die zur Erledigung der Arbeit erforderlich sind. Story Points sind eine willkürliche „lokale Währung“. Es gibt keine festen Regeln dafür, wie groß ein Story Point sein sollte. Sie sind nicht einmal Teil des Scrum Guide. Die Größe eines Story Points variiert von Team zu Team. Es kann auch im Laufe der Zeit variieren. Ein Story Point und die Schätzung des Umfangs einer Arbeit in SPs ist lediglich die „kollektive Schätzung“ des Teams zu einem bestimmten Zeitpunkt unter Verwendung einer inkonsistenten Metrik. Im Wesentlichen sind Story Points stundenlang ein unzuverlässiger Proxy laut Mike Cohn. Weitere Herausforderungen mit SP finden Sie unter Probleme mit Story Points.
Woher kommen Story Points?
Story Points waren die Idee einiger Unterzeichner des Agile Manifests. Sie werden nur von agilen Softwareentwicklungsteams verwendet. Eines der Grundprinzipien der agilen Softwareentwicklung ist die Selbstorganisation von Teams. Daher ist es gängige Praxis, auch eigene Leistungsindikatoren zu entwickeln. Die Story Points unterscheiden sich von Team zu Team und ändern sich auch im Laufe der Zeit. Infolgedessen sind sie für jegliche Managementzwecke inkonsistent und unzuverlässig. Jeder Verweis auf „Agile Geschwindigkeit“, der auf den gelieferten Story Points basiert, hat als Indikator für die Fortschrittsgeschwindigkeit nur einen bescheidenen Wert.
Dem Team die Möglichkeit zu geben, seinen eigenen Maßstab für Größe/Aufwand festzulegen, ist für die Verbesserung des Teamzusammenhalts von gewissem Wert. Darüber hinaus ist es nützlich, über ein Mittel zur Schätzung der Nebenarbeit zu verfügen (Aufgaben, die nicht spezifisch für die Bereitstellung von Funktionen sind), obwohl auch eine einfache Schätzung in Stunden verwendet werden könnte.
Die Probleme mit Story Points
- Story Points sind inkonsistent, im Laufe der Zeit und von Team zu Team.
- Sie kann nicht als Basismetrik verwendet werden bei Projekten
- Sie sind ungeeignet für Verträge
- Sie sind im Allgemeinen zur Prozessverbesserung ungeeignet
Story Points vs. COSMIC Function Points
| Zweck/Nutzen | KOSMISCHE Funktionspunkte | Story-Punkte |
|---|---|---|
| Gut für die Sprintschätzung | Ja | Ja |
| Gut für die Anwendungsdimensionierung | Ja | NEIN |
| Der Zeitaufwand für die Dimensionierung von User Stories verbessert die Qualität | Ja | Ja |
| Teamübergreifend konsistent | Ja | NEIN |
| Konsistent über Organisationen und Branchen hinweg | Ja | NEIN |
| Geeignet für Entwicklungsverträge | Ja | NEIN |
| Entwicklungsverträge mit ungewissem Umfang. | Ja | NEIN |
| Geeignet für organisatorisches Lernen | Ja | NEIN |
| Hilft, die Kosten für ausgelagerte Entwicklung zu senken | Ja | NEIN |
| Geeignet für die Vorhersage und Berichterstattung über Qualität | Ja | Etwas |
| Geeignet für eine frühzeitige Größen- und Kostenschätzung | Ja | Etwas |
| Gut für die Projektschätzung | Ja | Etwas |
| Gut für die Dimensionierung nichtfunktionaler Arbeiten | NEIN * | Ja |
| Gut für die Dimensionierung des Software-Portfolios und die Planung auf hohem Niveau | Ja | NEIN |
| Die Größenbestimmung kann automatisiert werden | Ja | NEIN |
| Gut für die Berichterstattung auf Vorstandsebene (von Entwicklungs- und Wartungsaktivitäten) | Ja | NEIN |
| Gut zum Vergleich der Teamproduktivität | Ja | NEIN |
* Viele nichtfunktionale Anforderungen können tatsächlich in funktionale Anforderungen umformuliert werden.
Der wichtigste Faktor bei der Bestimmung eines Softwareprojekts ist die Größe der zu liefernden Software. Es gibt auch viele andere wichtige Faktoren. Aber Größe ist die #1. Ohne eine gemeinsame Währung für die Softwaregröße sind Projekte schwer abzuschätzen, sie sind noch schwieriger zu messen, und wenn man sie nicht messen kann, sind sie sehr schwer zu verwalten.
Inkonsistent
Story-Point-Schätzungen sind spezifisch für das Team, das die Arbeit ausführt. Ein Story Point ist eigentlich ein Indikator für den geschätzten Arbeitsaufwand. Normalerweise gibt es nur ein „Gefühl“ für die Größe. Wenn Teammitglieder kommen und gehen, kann die Meinung über den Arbeitsaufwand schwanken, sodass sich die Bedeutung eines Story Points ändern kann. Folglich sind Schätzungen der Größe in Story Points für Vergleiche mit einem anderen Team, geschweige denn mit einem anderen Projekt, einer anderen Organisation oder einer anderen Branche, bedeutungslos.
Unzeitgemäß
Agile Teams schätzen die Größe in Story Points typischerweise nur wenige Wochen vor der Arbeit ab. Dies erschwert die längerfristige Planung des Projektmanagers erheblich.
„Der wichtigste Faktor bei einem Softwareprojekt ist die Softwaregröße. Und der beste Weg, die Softwaregröße zu messen, sind COSMIC-Funktionspunkte. „
Organisationen müssen sich verbessern
In den meisten Organisationen ist es praktisch unmöglich, einen Blick nach vorn oder zurück auf ein Projekt zu werfen und Story Points zum Vergleich oder zum Erlernen der Merkmale eines Projekts im Vergleich zu einem anderen zu nutzen. Story Points hemmen das Lernen.
Die Hauptmetrik für ein Softwareprojekt
Die wichtigsten Aspekte bei der Verwaltung eines Softwareprojekts sind: Softwaregröße, Aufwand, Zeit, Qualität und Risiko. Für all dies benötigen Unternehmen konsistente Kennzahlen. Wenn Sie die Größe kennen, können Sie schnell geeignete Kennzahlen für Qualität, Zeitplan und Ressourcen ermitteln. Größe ist die entscheidende Messgröße. Story Points verknüpfen Softwaregröße und -aufwand und können daher beides nicht richtig messen.
Organisationen benötigen unbestreitbare Maßnahmen zum Schätzen und Lernen.
Wenn Sie die zu liefernde Softwaregröße konsistent abschätzen können und über Leistungsdaten zu früheren vergleichbaren Projekten verfügen, können Sie schnell den geschätzten Aufwand und Zeitplan und damit die benötigten Ressourcen ermitteln. Dies ist mit Story Points nicht möglich, wenn nicht klar ist, ob sie Größe oder Aufwand messen. Was das Projektmanagement wesentlich einfacher und effektiver macht, ist die Verfügbarkeit unbestreitbarer Kennzahlen, mit denen man arbeiten kann. Sich allein auf Story Points zu verlassen, hemmt das Lernen und die Verbesserung der Organisation.
Story Points sind für eine ausgelagerte Entwicklung ungeeignet
Story Points haben in ausgelagerten Entwicklungsverträgen keinen Platz. Sie können beispielsweise keinen Vertrag über die Lieferung von 100 Story Points abschließen, da es kein absolut einheitliches Verständnis der Größe eines Story Points gibt. Dies hat zur Folge, dass der Kunde das Preis-Leistungs-Verhältnis weder einschätzen noch kontrollieren kann.
Qualität leidet
Agile-Verträge sind in der Regel durch Unsicherheit und einen Mangel an detaillierten Anforderungen vor der Beauftragung eines Entwicklungsauftragnehmers gekennzeichnet. Daher handelt es sich bei den meisten Verträgen zur Entwicklung von Software im Wesentlichen um Verträge Zeit und Materialien basierend. In einem T&M-Vertrag ist es schwierig, einen Preis für Funktionalität in einer bestimmten Qualität und zu einem bestimmten Preis auszuhandeln. Viele Anbieter sind bereit, ein Team zusammenzustellen, das alle vom Kunden gewünschten Funktionen bereitstellt. In vielen Fällen, die der Autor gesehen hat, ist die Entwicklungsorganisation auch berechtigt, den Aufwand zur Behebung von Fehlern in der von ihr gelieferten Software in Rechnung zu stellen. Sie können mit der Behebung ihrer eigenen Fehler genauso viel Geld verdienen wie mit der Entwicklung der Funktionalität. Um dieses Problem anzusprechen. Wir schlagen Verträge vor, die auf einem festen Festpreis pro Funktionspunkt basieren, mit Qualitätsbeschränkungen, die auf pro Funktionspunkt entdeckten Mängeln basieren.
Story Points können die Kosten in die Höhe treiben
Bei einem ausgelagerten Entwicklungsauftrag kommt es häufig zu Verzögerungen und Kostenüberschreitungen, die auf mangelhafte Arbeitsqualität zurückzuführen sind. Oft werden die Qualitätsprobleme dadurch verursacht, dass der Kunde schlechte Qualitätsanforderungen gestellt hat. Es liegt möglicherweise nicht im kommerziellen Interesse der Entwicklungsorganisation, die Qualität der Anforderungen in Frage zu stellen oder auch nur auf die Gefahren einer Fortsetzung hinzuweisen. Unabhängig davon, welche Partei die Mehrarbeit verursacht hat, liegt es oft im kommerziellen Interesse der Entwicklungsorganisation, zuzulassen, dass die Qualitätsprobleme die Verzögerung verursachen, und dann für die Durchführung der Reparaturarbeiten eine zusätzliche Vergütung zu erhalten. Sie fragen sich: Warum ist das an den Story Points schuld? Story Points halten die Unklarheit aufrecht, und diese Unklarheit führt zu T&M-Verträgen statt zu einem Vertrag, der auf einem festen Stückpreis für die gelieferte Funktionalität basiert.
„Die alleinige Verwendung von Story Points in ausgelagerten Verträgen führt zu schlechter Qualität und höheren Kosten.“
STOP, es gibt einen besseren Weg, und den gibt es schon immer.
COSMIC Function Points – der beste Freund des Entwicklungsmanagers
Nur wenige Softwaremanager sind sich tatsächlich bewusst, dass es bewährte universelle Standards zur Messung der Softwarefunktionalitätsgröße gibt. Die Idee, die funktionale Größe zu messen, gibt es schon seit langem. Der Funktionspunkt ist das Software-Äquivalent zur Gewichtsmessung in Kilo.
Die aktuellste Ausgabe ist der COSMIC Function Point (CFP). Es ist die moderne Weiterentwicklung einer bewährten Technik. Es ist frei (Open Source) und basiert auf grundlegenden Softwareprinzipien und ist daher universell einsetzbar.
Der Prozess der Messung wird als funktionale Dimensionierung bezeichnet und ist eine Möglichkeit, die Größe der Softwarefunktionalität mithilfe einer Metrik zu messen, die immer gleich und daher über Teams, Projekte, Organisationen und Branchen hinweg vergleichbar ist.
- Warum ist es besser?
- Es überwindet alle oben erwähnten Einschränkungen von Story Points.
- Es ist bewährt und ausgereift (ein ISO-Standard)
- Warum habe ich noch nie davon gehört?
- Kurz gesagt, es war nicht in Mode
- Bisher war die Durchführung der Messarbeiten zeitaufwändig.
- Sollte ich sowohl CFP als auch Story Points verwenden?
- Ja, Sie können weiterhin Story Points neben CFP verwenden.
- Story Points funktionieren für mich. Sollte ich etwas ändern?
- Es kommt darauf an, wen Sie mit „mich“ meinen. In einigen (ausgereiften und stabilen) internen Softwareteams können Story Points recht gut für die Schätzung von User Stories und Sprints funktionieren, und für ein einzelnes Team gibt es kaum einen Grund, etwas zu ändern. Doch aus allen oben aufgeführten Gründen bleiben die Schwächen auf Organisationsebene bestehen. Diese Schwächen werden nie überwunden, wenn Sie weiterhin nur Story Points verwenden.
„Der wichtigste Faktor bei einem Softwareprojekt ist die Größe. Und der beste Weg, die Größe zu messen, ist die Verwendung von KOSMISCHEN Funktionspunkten.“
Lesen Sie mehr für zusätzliche Beweise für die erfolgreiche Verwendung und hohe Vorhersehbarkeit von CFP bei agilen Projekten
Schlussfolgerung und Empfehlung
Wir empfehlen jedem Team, das bereits Story Points nutzt, dies auch weiterhin zu tun. Daneben sollten sie ihre Software auch in kosmischen Funktionspunkten messen. Beschränken Sie die Verwendung von SP auf die Arbeit innerhalb des Entwicklungsteams. Wenn Sie Schätzungen, Vertragsmetriken, Sprintkapazität und Projektmanagement betrachten, verwenden Sie ausschließlich CFP. Mit der Zeit werden Sie möglicherweise feststellen, dass Sie SP nicht mehr verwenden und sich stattdessen auf den Funktionsumfang der gelieferten Software konzentrieren.
Erfahren Sie mehr über COSMIC Function Points: Die gesamte umfassende Dokumentation der COSMIC-Methode steht zum kostenlosen Download unter zur Verfügung www.cosmic-sizing.org. Wir empfehlen Ihnen, damit zu beginnen Lesen Sie diese Einführung in die COSMIC-Größenbestimmung . Die Dimensionierungsmethode basiert auf grundlegenden Prinzipien der Softwareentwicklung und ist sehr einfach zu erlernen.
Von Colin Hammond, CEO von ScopeMaster Ltd und Charles Symons, Mitbegründer von COSMIC
