Die Schätzung der Arbeit in Scrum und die Einschätzung, wie viel Zeit die Umsetzung aller Elemente und aller User Storys des Produkt-Backlogs in Anspruch nehmen wird, ist äußerst mühsam.
Diese Aufgabe kann für viele Teams schwierig sein, insbesondere für solche, die keine Erfahrung mit agilen Methoden und Frameworks (Agile, Scrum) haben.
Das Problem der Schätzung von Arbeitszeiten ist komplex. Wir haben über dieses Thema in dem Artikel "Wie man die Arbeit von Backlog-Elementen schätzt" geschrieben.
Wenn das Entwicklungsteam versucht, die Arbeitszeit abzuschätzen, muss es sich bewusst sein, dass die Genauigkeit und Zuverlässigkeit dieser Schätzung nicht nur von Wissen und Erfahrung abhängt, sondern auch von einer Reihe von Faktoren, einschließlich externer Faktoren, die nicht immer berücksichtigt werden.
Natürlich ist die Situation nicht hoffnungslos. Es gibt viele Techniken zur Schätzung der Arbeitszeit, die für die Umsetzung der verschiedenen Elemente des Produkt-Backlogs benötigt wird.
In dem oben erwähnten Artikel finden Sie Beschreibungen einiger von ihnen.
In diesem Artikel werden wir uns jedoch auf eine sehr beliebte und nützliche Technik konzentrieren, die aufgrund ihrer Vorteile gerne von Entwicklungsteams genutzt wird.
Wenn Sie nicht wissen, was Story Points sind (die Agile-spezifischen Messeinheiten), dann sollten Sie unbedingt diesen Artikel lesen.
Was sind die Story Points? Warum sind sie so beliebt, und warum werden sie von Teams, die mit agilen Methoden arbeiten, so eifrig genutzt? Wie schätzt man Story Points?
Warum lohnt es sich, Story Points für die Schätzung von Arbeit zu verwenden? Wie sieht die Schätzung der Arbeitszeit mithilfe von Story Points aus?
In Kürze erhalten Sie die Antworten auf diese Fragen und erfahren mehr über eine der beliebtesten Techniken zur Schätzung der Arbeitszeit.
Wir laden Sie herzlich ein, weiterzulesen!
Sind Sie an dem Produktkonzept interessiert?
Warum ist die Schätzung der Arbeitszeit so problematisch?
Beginnen wir mit dem Thema, das ganz offensichtlich scheint, aber gleichzeitig alles belastet. Sie wirkt sich auf Fristen, Effizienz, Endqualität und Wettbewerbsfähigkeit des digitalen Produkts aus.
Die Fähigkeit, eine möglichst genaue und wahrheitsgetreue Schätzung der Arbeitszeit vorzunehmen, ist für den Projekterfolg entscheidend.
Das bedeutet, dass sie innerhalb des vorgegebenen Zeit- und Budgetrahmens und in Übereinstimmung mit den komplexen und vielfältigen Erwartungen der Beteiligten durchgeführt werden muss.
Die Genauigkeit jeder Schätzung der Arbeitszeit hängt von Folgendem ab:
- Menge der Daten, über die das Scrum-Team verfügt.
- Inwieweit sind diese Daten vollständig?
- Inwieweit sind diese Daten wertvoll, nützlich und entscheidend?
- Wie stabil sind diese Daten, wie aktuell sind sie, und wie schnell ändern sie sich im Laufe der Zeit?
- Angenommene Referenz-Story und Points.
- Die Fähigkeit, Analogien, Unterschiede und Beziehungen zu erkennen.
- Erfahrung mit Analysen, Schätzungen und Vorhersagen.
- Äußere und innere Bedingungen, die den Verlauf, das Tempo und den reibungslosen Ablauf der Arbeit beeinflussen.
- Wissen über die wesentlichen Risiken, die in agilen Projekten auftreten.
- Wissen über die Variabilität und Regelmäßigkeit von Prozessen.
- Ob die Schätzung individuell oder kollektiv durchgeführt wird und ob sie von Fachleuten vorgenommen wird, die dann die entsprechenden Arbeiten ausführen.
- Und nicht zuletzt wird es von den getroffenen Annahmen abhängen: Es ist von entscheidender Bedeutung, den Umfang, die Komplexität und die Relevanz der getroffenen Maßnahmen genau zu definieren.
Eine weitere wichtige Variable ist der Maßstab, mit dem Sie versuchen, die Arbeit auszudrücken. Die traditionelle Messgröße ist natürlich die Zeit (unterteilt in Monate, Wochen, Tage oder manchmal sogar Stunden).
Dabei sollten Sie sich bewusst sein, dass die in einer bestimmten Einheit ausgedrückte Zeit, auch wenn sie objektiv, unvoreingenommen und leicht vergleichbar zu sein scheint, nicht unbedingt ein problemloses Instrument zur Schätzung ist.
Die Zeit als Einheit in agilen Projekten erlaubt das nicht:
- Berücksichtigen Sie die Arbeit außerhalb des Projekts (z. B. Sitzungen, Gespräche und Schriftverkehr), die sich oft zeitlich überschneiden.
- Betrachten Sie die spezifische Arbeit eines bestimmten Teams.
- Konzentrieren Sie sich auf bedeutendere und wichtigere Erfolge als den Abgabetermin (z. B. die Lösung eines technischen Problems von zentraler, strategischer oder geschäftlicher Bedeutung).
Nehmen wir an, Sie haben einmal an dem Prozess der Schätzung der Arbeitszeit für die Elemente des Produkt-Backlogs teilgenommen. In diesem Fall wissen Sie, dass verschiedene Entwickler dieselbe Aufgabe (z.B. User Story) sehr unterschiedlich bewerten werden.
Das liegt daran, dass das subjektive Zeitempfinden dazu führt, dass eine Stunde für jeden Spezialisten etwas anderes bedeutet.
Natürlich sind es objektiv immer noch 60 Minuten und 3600 Sekunden, aber wie viel Arbeit man in diesen 60 Minuten und 3600 Sekunden erledigen kann, ist gelinde gesagt problematisch.
Die verschiedenen Einschätzungen haben ihren Ursprung in unterschiedlichen Erfahrungen und Kompetenzen.
Sie resultieren aber auch aus rein menschlichen Aspekten wie Gewohnheiten, Veranlagungen, Motivationen, bevorzugten Werten oder, allgemeiner ausgedrückt, der bevorzugten Arbeitskultur.
Wenn also Mehrdeutigkeit unvermeidlich ist, wie können Sie dann genau einschätzen und bestimmen, wie viel Zeit eine bestimmte Aufgabe in Anspruch nehmen sollte oder wie viel Aufwand sie erfordern wird?
Absolute Schätzungsmethoden (z. B. Zeit) sind nicht immer die effektivsten, während relative Methoden gut funktionieren.
Sie basieren nicht auf der Definition des Beginns oder des Endes einer Arbeit, sondern auf der Angabe von Ähnlichkeiten zwischen ähnlichen Aufgaben in Bezug auf ausgewählte Kriterien.
Vergleiche und Schätzungen, über die wir im oben genannten Artikel mehr geschrieben haben, sind für den Menschen ganz natürlich.
Wir können Analogien erkennen und darauf aufbauend Vorhersagen machen.
Und wir müssen zugeben, dass wir darin ziemlich gut sind. Diese Fähigkeit, die angeboren ist und sich im Laufe der Entwicklung der Art und des Individuums herausgebildet hat, ermöglicht es uns, genaue Schätzungen vorzunehmen.
Story Points sind eine Technik, die sich aus der natürlichen Veranlagung des Menschen ergibt. Sie ermöglicht es uns, abzuschätzen, wann Ergebnisse zu erwarten sind, und zwar nicht anhand spezifischer Zeitmaße, sondern anhand von Story Points.
Sie bestimmt nicht das Datum, sondern die Geschwindigkeit, mit der das Produkt-Backlog fertiggestellt wird. Wir müssen jedoch nachdrücklich betonen, dass sich Story Points nicht auf die Zeit reduzieren lassen.
Story Points messen die Geschwindigkeit, nicht die Ausführungszeit.
Story Points in Scrum — was sind sie?
Story Points werden in Agile/Scrum als Maßeinheiten verstanden, um den Aufwand für die Fertigstellung einer User Story abzuschätzen, bei der es sich z.B. um eine neue Funktionalität oder eine Aktualisierung einer bereits implementierten Funktionalität handeln kann.
Story Points sind definiert als die:
- Komplexität einer Aufgabe.
- Umfang der Arbeit.
- Unsicherheit bei der Arbeit.
Story Points werden bei der Sprintplanung und/oder beim Grooming verwendet.
Mit anderen Worten, basierend auf dem, was User Storys in Agile und Scrum sind, sind Story Points eine Art von Metrik.
Sie helfen Ihnen festzustellen, wie einfach/schwer es sein wird, eine bestimmte User Story zu implementieren, oder anders ausgedrückt, wie viele Story Points es braucht.
Dank des Zahlenwerts, der, wie wir betont haben, keine Zeitangabe ist, können Sie den Schwierigkeitsgrad bestimmen.
Story Points sind abstrakte Maßnahmen, aber sie sind gleichzeitig auch hilfreich. Eine User Story mit 3 Points ist doppelt so leicht zu bearbeiten wie eine Story mit 6 Points.
Wie Sie sehen können, bestimmen die Story Points den Aufwand, die Geschwindigkeit und die Entfernung, die eine Aufgabe von der anderen trennt.
Auch wenn sie die Frage nicht beantworten werden: Wann ist das Ende der Optimierung zu erwarten? Sie ermöglichen es Ihnen, den Prozess, die Arbeit und die Auswirkungen mehrdimensional zu betrachten.
Story Points sind Maßnahmen, die die Komplexität einer Aufgabe, den dafür erforderlichen Aufwand und das damit verbundene Risiko berücksichtigen.
Sie sind also viel umfassender als die Zeit, die nur einen Wert angibt und mit diesem arbeitet.
Die Story-Point-Schätzung bezieht sich auf die folgenden Punkte:
- Risiko, weil agile Projekte immer mit einer großen Variabilität der Anforderungen und Bedingungen verbunden sind, weshalb sie bei der Schätzung problematisch sind.
- Komplexität, ihre Folgen und Bedingungen sind aus Theorie und Praxis bekannt; es geht also nicht um Komplexität im technologischen Sinne, sondern um die reine Programmierung und auch um die Komplexität des Projektmanagements.
- Erfahrung und Wiederholbarkeit der Aufgaben (z. B. der ausgeführten Funktionen), was gleichzeitig eine Vorstellung von ihrer Problematik, Einfachheit, aber auch Langweiligkeit vermittelt (z. B. muss der Effekt der Monotonie berücksichtigt werden, der die Arbeit einfach erscheinen lässt, aber aufgrund dieses Effekts lange ausgeführt werden kann).
Story Points können die folgenden Fragen beantworten:
- Werden Sie in der Lage sein, den Sprint effektiv durchzuführen?
- Verfügt das Team über alle notwendigen Informationen, um das Projekt erfolgreich durchzuführen?
- War die User Story optimal aufgeteilt?
Hinzu kommt, dass sich das Endergebnis aus Zufallsfaktoren und Determinanten zusammensetzt (unerwartete Ereignisse in Form von Störungen, Arbeitsausfällen und Wechsel von Mitgliedern des Scrum-Teams).
Zusammengefasst:
Story Points sind eine Metrik, die im agilen Projektmanagement und in der Programmierung verwendet wird, um die Schwierigkeit der Implementierung einer bestimmten User Story abzuschätzen.
Es handelt sich um eine Zahl, die dem Team Auskunft über den Schwierigkeitsgrad der User Story gibt. Diese Schwierigkeit wird mehrdimensional als ein Merkmal verstanden, das sich auf Komplexität, Risiko und Aufwand bezieht.
Die Story Point-Schätzung ist eine Art der relativen Schätzung, die häufig während der Sprint-Planung und/oder dem Grooming des Produkt-Backlogs durchgeführt wird.
Warum sollten agile Teams Story Points verwenden?
Zunächst einmal ist der Einsatz dieser Technik für beide Seiten von Vorteil. Es bietet sowohl für Scrum-Teams als auch für Produktverantwortliche einen echten Mehrwert.
Story Points ermöglichen es Scrum-Teams:
- Die Bandbreite der Erwartungen genauer verstehen.
- Genaue Planung und effektive Umsetzung.
- Entwicklung eines gleichmäßigen, optimalen Durchführungsrhythmus, der einen zufriedenstellenden Projektfortschritt gewährleistet.
- Schätzung ohne Zeitdruck.
Im Gegenzug ermöglichen Scrum Points den Product Owner:
- Erzielen Sie eine zufriedenstellende Investitionsrendite.
- Erzielen Sie ein zufriedenstellendes Preis-Leistungs-Verhältnis.
- Besseres Verständnis der Besonderheiten bei der Erstellung digitaler Produkte, der Bedingungen und der Bestimmungsfaktoren.
- Genauere Vorhersage der langfristigen Implementierung von Funktionalitäten und Aktualisierungen des digitalen Produkts.
Noch wichtiger ist, dass die Story Points den Produktverantwortlichen bewusst machen, dass der Verweis auf eine einzelne Maßnahme zwar klar und schlüssig, aber oft irreführend ist und die Sicht auf die Situation verzerrt.
So kann es zu Entscheidungssituationen kommen, in denen eine einzige Variable berücksichtigt wird, deren Gewicht nicht immer am größten ist und deren Rolle nicht immer Priorität hat.
Story Points messen das Gesamtbild und seine wichtigsten Komponenten: Risiko, Komplexität und Ungewissheit und ermöglichen so eine effektivere Sprint-Planung.
Story Points sind auch "sensibel" für die Unterschiede zwischen den verschiedenen Mitgliedern des Scrum-Teams und die Besonderheiten der einzelnen Mitglieder des Entwicklungsteams.
Darüber hinaus stärken Story Points Teams, unterstützen die Teamarbeit, heben den oft ineffektiven Zeitdruck auf und steigern so die Produktivität von Scrum-Teams.
Wie berechnet man Story Points?
Bei der Berechnung der Story Points ist es wichtig, alle Teammitglieder in diesen Prozess einzubeziehen.
Von Entwicklern und Testern bis hin zu Spezialisten, die für die Bereitstellung verantwortlich sind.
Das Wesentliche an Story Points ist die globale Perspektive, die es Ihnen ermöglicht, den Gesamtaufwand für die Implementierung einer bestimmten Funktionalität zu sehen und abzuschätzen.
Deshalb ist es wichtig, bei der Berechnung der Story Points Folgendes zu beachten:
- Die Komplexität der Arbeit.
- Umfang der Arbeit.
- Technologische Fähigkeiten und Kompetenzen des Teams.
- Risiken und Unsicherheitsbereiche.
- Werkzeuge und Bedingungen, die den Beginn der Arbeit ermöglichen.
- Mögliche Themen und kritische Probleme.
- Kenntnisse über die Durchführung einer bestimmten Funktion und die damit verbundenen Probleme und Risiken.
Story Points werden oft in eigens dafür vorgesehenen Sitzungen mit den vom Team bevorzugten Techniken vergeben.
Ein typisches Treffen, bei dem Schätzungen vorgenommen werden, umfasst:
- Diskussion über ein bestimmtes Element aus dem Produkt-Backlog.
- Erstellung einer Schätzungsmatrix, die Risiken, Wiederholungen und Komplexität berücksichtigt.
- Anzeige der von den Teammitgliedern vorgenommenen Schätzungen.
- Diskussion über extreme Werte, die mit dem Ziel verhandelt werden, einen Konsens zu erreichen.
Story Points, oft abstrakte Werte, können mit verschiedenen Techniken und Skalen ausgedrückt werden.
Wie bestimmt man also den Wert der Story Points?
Zu den am häufigsten verwendeten Techniken zur Bestimmung des Wertes von Story Points gehören:
- Fibonacci-Folge
- Klassische lineare Folge: 1, 2, 3, 4...
- Planning poker.
Bei der Berechnung der Story Points sollten Sie bedenken, dass sie relativ sind. Der Zahlenwert gibt die Schwierigkeit an.
Der Wert von einem Story Point steht für die einfachste Aufgabe, unabhängig von der Art des Projekts oder dem Charakter der User Story.
Der doppelte Basiswert — zwei Story Points — steht für den doppelten Schwierigkeitsgrad einer Aufgabe und zeigt an, dass doppelt so viel Aufwand nötig ist, um sie zu erledigen. Der dreifache Basiswert — drei Story Points — steht für die dreifache Schwierigkeit einer Aufgabe.
Die Genauigkeit der Schätzungen hängt weitgehend von der Erfahrung bei der Umsetzung der jeweiligen Funktion und der Erfahrung bei der Schätzung selbst ab.
So ist es beispielsweise nicht dreimal so komplex und arbeitsintensiv, eine Kontaktseite mit drei Feldern zu erstellen und eine zweite, analoge Seite, die sich nur durch die Anzahl der Kontaktfelder unterscheidet und neun Felder benötigt.
Auch in Bezug auf die Komplexität gibt es keine wesentlichen Unterschiede. Sie ist nicht dreimal so komplex oder dreimal so riskant.
Der Unterschied ist nicht grundlegend, sondern bezieht sich nur auf einen engen Bereich.
Wenn Sie der ersten Seite einen Wert von 2 Story Points zuweisen, werden Sie der zweiten Seite natürlich keine 6 Story Points zuweisen, weil ein solcher Unterschied zwischen den beiden Seiten einfach unrealistisch wäre. Oder genauer gesagt, unzureichend.
Denken Sie bei der Schätzung von Story Points immer daran, dass der gemeinsame Nenner für die Summe aus Arbeit, Risiko, Komplexität und Unsicherheit der Aufwand ist.
Der Aufwand, der mit der zu erledigenden Arbeit verbunden ist, dem Risiko entgegenzuwirken, die Komplexität zu bewältigen und die Unsicherheit zu reduzieren, ist die Essenz der Story Points-Technik in Agile/Scrum.
Was sind Scrum Story Points? Zusammenfassung
- Die Schätzung des Arbeitsaufwands in der Scrum User Story ist recht mühsam.
- Die Fähigkeit, eine möglichst genaue und wahrheitsgetreue Schätzung der Arbeitszeit vorzunehmen, ist für den Projekterfolg entscheidend.
- Auch wenn sie objektiv, unvoreingenommen und leicht vergleichbar erscheinen mag, ist die Zeit als Instrument der Schätzung nicht unbedingt unproblematisch.
- Absolute Schätzungsmethoden (z. B. Zeit) sind nicht immer die effektivsten.
- Story Points in Agile/Scrum bestimmen den Aufwand, die Geschwindigkeit und die Distanz, die eine Aufgabe von einer anderen trennt.
- Story Points sind Maßnahmen, die auch die Komplexität einer Aufgabe und die damit verbundenen Risiken berücksichtigen.
- Story Points machen den Produktverantwortlichen bewusst, dass der Verweis auf eine einzelne Maßnahme zwar klar und schlüssig, aber oft irreführend ist und die Sicht auf die Situation verzerrt.
- Die Erstellung von Story Points ist eine Teamleistung.
- Story Points sind auch "sensibel" für die Unterschiede zwischen den verschiedenen Mitgliedern des Scrum-Teams und die Besonderheiten der einzelnen Mitglieder des Entwicklungsteams.
- Am häufigsten werden die Fibonacci-Folge, Planungspoker und eine klassische lineare Folge verwendet: 1, 2, 3, 4, werden verwendet, um den Wert der Story Points zu bestimmen.
