Was sind Story Points in Agile und wie werden sie geschätzt?

Was sind Story Points in Agile?

Die Story Points sind ein Maß, um die Arbeit abzuschätzen, die durch die Implementierung agiler Frameworks wie Scrum und eXtreme Programming geleistet wird.

Die Implementierung einer User Story ist eine schwierige Aufgabe. Das Team könnte Risiken ausgesetzt sein; Komplexitäten etc. während des Entwicklungsprozesses. Dieser Schwierigkeitsgrad wird vom Entwicklungsteam mithilfe eines abstrakten Maßes gemessen, das als Story Point bezeichnet wird. Daher werden Story Points in Agile als Metriken in der agilen Entwicklung verwendet. Es erzählt dem Team, wie schwierig die Umsetzung der Geschichte ist.

Die Product Backlog Grooming Sessions führen die Schätzung der Story Points durch, die dann von der Produktentwicklung und dem Testteam bewertet werden. Dies geschieht, um die Effizienz der Sprintplanung zu steigern. Das Product Backlog Grooming ist die grobe Schätzung, die Folgendes überprüft:

• Ob der Sprintplan bereit ist, um effizient durchgeführt zu werden.
• Reichen die Informationen aus, um die Angelegenheit abzuschließen.
• Ob der auf der User Story basierende Sprintplan sinnvoll ist.

Es gibt drei Hauptkomponenten in der agilen Story-Point-Schätzung:

• Risiko: Für einen bestimmten Artikel sind die damit verbundenen Risiken vage Anforderungen, Änderungen während des Prozesses und Abhängigkeit von Dritten.
• Komplexität: Sie repräsentiert den Schwierigkeitsgrad bei der Entwicklung eines Features.
• Rezeption: Sie bestimmt, wie bekannt das Feature bei den Teammitgliedern ist und wie eintönig bestimmte Aufgaben innerhalb der Entwicklung sind.

Die Einbeziehung der drei Punkte ermöglicht die genaue Planung von Sprints, einschließlich eines Polsters für Unsicherheiten, Probleme im Zusammenhang mit einer besseren Schätzung und der Vermeidung von zu starkem Lernen bei Zeitverpflichtungen.

Schätzung von Story Points in Agile

Schritte zur Schätzung agiler Story Points

Die Einbeziehung der Entwickler, Designer, Tester usw. wird als Schlüsselfaktor bei der Schätzung von agilen Story Points angesehen. Da jedes Teammitglied unterschiedliche Perspektiven hat, die Arbeit voranzubringen und das Produkt zu liefern, ist eine effektive Zusammenarbeit wichtig. Beispielsweise erfordert jede Designänderung nicht nur die Bemühungen eines Designteams, sondern auch die Einbeziehung der Entwicklungs- und der QA-Abteilung.

Um mit der Schätzung von Story Points in Agile zu beginnen, sollte das Team eine Baseline Story haben, die nicht unbedingt klein sein muss, aber innerhalb des Teams gut ankommen kann. Darauf folgt die Dimensionierung der Storys basierend auf der Baseline-Story. Mit Hilfe der Referenzgeschichten sollen Punkte für die Geschichte vergeben werden. Jeder Geschichte wird ein Punktwert zugeordnet.

Vorteile der Dimensionierung

Das agile Delivery-Team führt den einfacher abzuschätzenden Prozess der Dimensionierung durch. Durch Dimensionierung

• Die Übersicht über den Leistungsumfang kann eingesehen werden.
• Die Größe der Arbeit kann durch mehrere Perspektiven bestimmt werden.
• Jede falsche Annahme kann korrigiert werden.
• Dinge, die nicht genau sein können, werden ausgeräumt.

Die Dimensionierung erfolgt unter Berücksichtigung der folgenden Punkte:

• Die Menge der zu erledigenden Arbeit
• Die Komplexität der Arbeit
• Risiko oder Ungewissheit bei der Ausführung der Arbeit
• Zeitdauer

Die Sprints können genauer geplant werden, indem Sie dem aufgeführten Prozess folgen:

Ein dreistufiger Prozess zur Schätzung von Story Points ist:

1. Verwendung von Fibonacci-Folgenreihen.

• Die traditionelle menschliche Tagesbewertung wurde ersetzt, um Story Points durch die Fibonacci-Zahlen zu schätzen, dh 1, 2, 3, 5, 8, …
• Eine lineare Skala wird nicht verwendet, da sie Items anbietet, die nicht differenziert genug sind, um eine Schätzung zu definieren. Die Fibonacci-Reihe kann jedoch die kleinen Sprünge in einem Problem abschätzen.
• Die Fibonacci-Reihe stellt eine Folge von Zahlen dar, bei der die nächste Zahl in der Folge die Summe der beiden vorhergehenden Zahlen ist. Um Story Points in Agile zu schätzen , wird die Fibonacci-Folge auf 0,5, 1, 2, 3, 5, 8, 13, … modifiziert.

2. Bestimmung einer Matrix

• Für jeden Story Point wird eine Baseline bestimmt.
• Die Baseline ist in der Matrix mit dem Wert 1 enthalten. Dies wird als Standard für das geringste Risiko, die geringste Wiederholung usw. festgelegt.

3. Planungspoker

Durch den Planungspoker einigt sich das Team auf die richtige Näherung der Story Points für jeden Gegenstand.

Die Funktionsweise von Planungspoker ist

• Während der Sprintplanung erhält jeder Entwickler und Tester einen Kartensatz. Die Karten zeigen eine Fibonacci-Seriennummer.
• Ein Item aus der Rückstandstabelle wird herausgesucht, um die Items zu hinterfragen und die Eigenschaften der Items zu klären.
• Am Ende der Diskussion wird eine Karte, die die Schätzung des Artikels widerspiegelt, privat vom Tester und dem Entwickler ausgewählt.
• Die Karten werden dann von den Schätzern aufgedeckt. Sie gehen zum Nettoelement über, wenn ein Konsens erreicht wird. Bei unterschiedlichen Karten wird die Diskussion von den Anführern fortgesetzt, bis ein Konsens erzielt wird.

Eine ausgefüllte Matrix ist nützlich, damit die Schätzer sie während des Planungspokers als Referenz verwenden können. Dies ermöglicht eine größere Konsistenz über die Aufgaben hinweg. Außerdem ist die maximale Grenze der Schätzung 13, wenn es mehr als 13 ist, dann ist es effektiv, dass die Aufgabe in kleinere Elemente aufgeteilt werden sollte. Auch wenn die Aufgabe kleiner als 1 geschätzt wird, ist es ratsam, sie in eine andere Aufgabe zu integrieren.

Weitere 8 Schätzschritte zur erfolgreichen Schätzung von Story Points in Agile sind:

1. Identifizieren der Basisgeschichten

• Einer der wichtigen Schritte zum Schätzen von Story Points in Agile besteht darin, eine Base Story zu identifizieren, die als Referenz für die relative Größe des Backlogs verwendet wird.
• Die Baseline Story wird aus einer früheren Story ausgewählt, die vom Entwicklungsteam durchgeführt wurde, oder aus einem aktuellen Product Backlog.
• Das Verständnis der Grundgeschichte sollte bei allen Teammitgliedern gleich sein. Mit anderen Worten, das Team sollte Vertrauen in die Basisgeschichte haben.

2. Besprechen Sie die Anforderungen

• Die Details der Story müssen besprochen und Erläuterungen zur User Story vom Product Owner oder einem Business Analyst bereitgestellt werden.

3. Notieren Sie wichtige Dinge

• Alle wichtigen Dinge, die wichtig sein sollen, sollten notiert werden.
• Der Scrum Master erledigt diese Aufgabe am besten während der laufenden Diskussionen.

4. Wichtige Fragen, die gestellt werden müssen

Einige Fragen sind zu wichtig, als dass sich das Entwicklungsteam selbst stellen müsste.

• Was müssen die Teammitglieder lernen, bevor sie mit dem Design beginnen?
• Was ist die Anforderung an den Code für die Geschichte? Wie viel Länge ist erforderlich und gibt es ähnliche Codes, die früher vom Entwicklungsteam geschrieben wurden?
• Wie hoch ist der Aufwand für die Akzeptanz beim Kunden?
• Gibt es externe Abhängigkeiten, die die Geschichte hat?
• Hat jemand im Team Fachwissen oder Erfahrung in der Arbeit an derselben Geschichte?
• Hat die Geschichte eine Einfachheit oder damit verbundene Komplexität, entweder aus Sicht der Geschäftslogik oder aus technischer Sicht?
• Wie viel Sicherheit gibt es, um die Abhängigkeiten rechtzeitig zu bekommen?

5. Punkte zum relativen Vergleich

• Der Geschichte sollten relative Vergleichspunkte zugeordnet werden.
• Die gleiche Punktzahl sollte der Geschichte zugeordnet werden, dh 1 für Geschichten, die den gleichen Arbeitsaufwand haben wie bereits bemessene Geschichten.
• Für schwierigere Geschichten sollte ein proportional höherer Wert zugewiesen werden.
• Wenn die Geschichte aufgrund der Erkenntnisse aus der vorherigen Geschichte weniger komplex ist, aber dieser Geschichte fast ähnlich ist, ist ein niedrigerer Wert zu vergeben.

6. Je nach Größe der Story ist ein Konsens im gesamten Team zu erreichen.
7. Es sollte eine Validierung der Tatsache geben, dass es eine interne Konsistenz zwischen den Geschichten gibt.
8. Es sollte in wiederholten Abständen darauf geachtet werden, dass alle 1er gleich sind oder alle 2er übereinstimmen usw.

Vorteile der agilen Story-Point-Schätzung

Die Anwendung von Schätzungen auf die Story Points in Agile bietet sowohl den Entwicklern als auch den Product Ownern Vorteile.

Den Entwicklern gebotene Vorteile sind:

• Die Anwendung der Schätzung ermöglicht es den Entwicklern zu wissen, wie viel Planung für einen Sprint erforderlich ist, und kann daher die Arbeit in einem nachhaltigen Tempo vorantreiben.
• Eine Überplanung des Sprints wird vermieden.
• Die Implementierungsstrategie und Anforderungen, die in einem Produkt benötigt werden, werden durch die Diskussionen und Ausarbeitungen gut verstanden.

Folgende Vorteile werden den Product Ownern geboten:

• Die längerfristige Lieferung des Produkts kann fokussiert werden.
• Das „Preis-Leistungs-Verhältnis“ oder der „Return of Investment“ der Artikel können beurteilt werden.
• Die technischen Risiken großer Artikel sind für die Product Owner sichtbar.

Lernen Sie Softwarekurse online von den besten Universitäten der Welt. Verdienen Sie Executive PG-Programme, Advanced Certificate-Programme oder Master-Programme, um Ihre Karriere zu beschleunigen.

Zusammenfassung

So wie die agile Methodik Übung beinhaltet, ist die Schätzung selbst eine Übung, die mit der Zeit besser wird. Die Implementierung der Schätzung agiler Punkte kommt sowohl den Entwicklern als auch dem Eigentümer zugute, was letztendlich zu einer effektiven Lösung führt.

Wenn Sie Ihre Hände in der Softwareentwicklung beherrschen wollen, dann kommen Sie vorbei und prüfen Sie den von upGrad angebotenen Kurs Executive PG Program in Software Development – ​​Specialization in Full Stack Development.

Der Spezialisierungskurs hilft dabei, die verborgene Kreativität aller Berufseinsteiger in ihre Zukunft der Softwareentwicklung umzuwandeln. Wenn Sie Hilfe benötigen, können Sie sich an unser Assistenzteam wenden.