Beispiele für Story Points: eine Referenzskala von 1 bis 13
Sechs Backlog-Beispiele, um Ihrem Team zu helfen, Arbeit zu vergleichen, Annahmen zu hinterfragen und eigene Referenz-Stories auszuwählen.
Eine Story-Point-Schätzung drückt die relative Größe der Arbeit für ein Team aus und berücksichtigt dabei Aufwand, Komplexität und Unsicherheit. Dadurch wird ein abgeschlossenes, vertrautes Element zu einer nützlichen Referenz für die Diskussion des nächsten. Der Atlassian-Schätzleitfaden erklärt diesen relativen Ansatz.
Zum Beispiel könnte ein Team einer vertrauten Änderung an den Einstellungen 2 Punkte geben und einem neuen Benachrichtigungsworkflow 5. Die hilfreiche Frage lautet: Welche zusätzliche Arbeit erklärt den Unterschied?
Die folgenden Beispiele stammen von einem fiktiven Team, das an einem gemeinsamen Dokumentarbeitsbereich arbeitet. Sie sind Ausgangspunkte für eine Diskussion, keine verbindlichen Vorgaben für Funktionen. Ihr Team kann vernünftigerweise andere Werte wählen.
Sechs Beispiele auf der Skala eines Teams
Gehen Sie davon aus, dass dieses Team bereits über eine Komponentenbibliothek, Berechtigungen für den Arbeitsbereich, einen Benachrichtigungsdienst und automatisierte Prüfungen der bestehenden Arbeitsabläufe verfügt. Jede Schätzung umfasst Implementierung, Review und die Prüfungen, die erforderlich sind, um die Definition of Done des Teams zu erfüllen.
| Punkte | Backlog-Item | In diesem Beispiel enthalten | Warum das Team es hier einsortiert |
|---|---|---|---|
| 1 | Einen leeren Aktivitätsfeed erklären | Genehmigter Text und vorhandene Komponente für den Leerzustand; kein neues Verhalten | Eine kleine, vertraute Änderung mit wenigen betroffenen Zuständen |
| 2 | Arbeitsbereichs-Admins erlauben, den gemeinsamen Anzeigenamen zu ändern | Vorhandenes Einstellungsformular, API- und Admin-Berechtigungsprüfung; Validierung und gespeicherte/Fehlerzustände | Ein vertrauter Pfad mit einigen Verhaltensüberprüfungen; das Referenz-Item des Teams |
| 3 | Dokumente nach ihrem Besitzer filtern | Vorhandene Filterkomponente und API-Unterstützung; Reset-Verhalten und leere Ergebnisse | Mehr interaktive UI-Zustände als die Referenz, mit bekanntem Datenpfad |
| 5 | Benachrichtige den Dokumentenbesitzer, wenn jemand Zugriff anfordert | Vorhandener Lieferservice; Berechtigungsprüfungen, Benachrichtigungsinhalt, Umgang mit Duplikaten und Link zurück zur Anfrage | Mehrere bestehende Teile müssen korrekt zusammenarbeiten |
| 8 | Eigentumsübertragung von Dokumenten innerhalb eines Arbeitsbereichs | Neue Transferoperation; Berechtigungsänderungen, gleichzeitige Bearbeitungen und ein Audit-Eintrag | Ein umfassenderer Zustandsübergang mit Fehlerfällen, der sorgfältige Abstimmung erfordert |
| 13 | Einen Ordner und seine Dokumente in einen anderen Arbeitsbereich verschieben | Zielberechtigungen, Verknüpfungen, Teilfehler und Wiederherstellungsverhalten | Zu viele verknüpfte Entscheidungen, als dass das Team es als ein bequemes Item behalten könnte; Splittung besprechen |
Die Infrastrukturannahmen sind wichtig. Ein Team ohne Benachrichtigungsdienst würde im 5-Punkte-Beispiel zusätzliche Arbeit schätzen. Ein Team mit einer bewährten Eigentumsübertragungsoperation könnte diesen Punkt niedriger einstufen.
Diese Zahlen sind keine Formel. Das Zählen von UI-Bildschirmen, Endpunkten oder Akzeptanzkriterien reproduziert die Schätzungen nicht zuverlässig.
Wie der Umfang die Schätzung verändert
Betrachten Sie „Ändere den Anzeigenamen eines Arbeitsbereichs“. Die Tabelle geht davon aus, dass ein Admin das gemeinsame Label in den Einstellungen bearbeitet, mit vorhandenem Update-Endpunkt und Berechtigungsprüfung.
Ändern Sie nun die Akzeptanzbedingungen:
| Version | Umfang | Illustrative Schätzung |
|---|---|---|
| A | Ändere das in den Arbeitsbereichseinstellungen angezeigte Label; benutze die vorhandene Speicherfunktion | 2 |
| B | Aktualisiere auch Einladungstexte und gecachte Navigation; halte diese Oberflächen konsistent, falls ein Update nur teilweise gelingt | 5 |
| C | Der Name bestimmt auch die öffentliche URL des Arbeitsbereichs; alte Links bewahren und Kollisionen behandeln | Anhalten zur Klärung, dann eventuell 8 oder aufteilen |
Version C wirft zuerst eine Produktfrage auf, bevor es eine Größenfrage gibt: Sollte die Umbenennung überhaupt die URL ändern? Die Entscheidung für eine stabile URL könnte viel zusätzliche Arbeit einsparen.
Wenn ein Teilnehmer 2 und ein anderer 8 stimmt, bitten Sie jeden, das einbezogene Verhalten zu beschreiben. Beide könnten konsistent zu unterschiedlichen Versionen argumentieren. Formulieren Sie die Akzeptanzbedingungen neu, bevor erneut abgestimmt wird.
Wählen Sie Referenz-Stories, an die sich Ihr Team erinnert
Wählen Sie zwei bis drei abgeschlossene Items mit klaren Grenzen. Eine kleine vertraute Änderung, ein mittlerer Workflow und eine größere, aber verstandene Änderung bieten dem Team nützlichere Vergleichsmöglichkeiten als eine einzelne abstrakte Zahl.
Führen Sie für jede Referenz eine kurze Notiz:
- Welches Benutzerergebnis wurde erzielt?
- Welche Systeme und Zustände änderten sich?
- Welche Review- und Verifizierungsarbeiten waren enthalten?
- Welche Annahmen machten es einfach oder schwierig?
Vergleichen Sie dann neue Arbeit mit der nächstliegenden Referenz. „Ähnlich unserer Einstellungänderung, aber mit zwei zusätzlichen Berechtigungspfaden“ gibt den Beteiligten etwas Konkretes zum Hinterfragen.
Hat das Team keine gemeinsame Delivery-Historie, wählen Sie ein gut verstandenes Item als vorläufige Referenz. Überarbeiten Sie es nach der Lieferung und halten Sie die Annahmen transparent. Es ist nicht notwendig, vor dem gemeinsamen Lernen eine perfekte Skala zu erfinden.
Kopieren Sie diese Schätznotiz in ein Backlog-Item
Verwenden Sie Folgendes als Diskussionshilfe in Ihrem Backlog oder den Teamnotizen:
Benutzerergebnis:
Enthaltenes Verhalten:
Explizit ausgeschlossen:
Nächstliegende abgeschlossene Referenz:
Warum fällt es kleiner oder größer aus:
Unbekannte Faktoren, die den Umfang ändern könnten:
Entscheidung: schätzen / aufteilen / untersuchen
Vereinbarte Schätzung, falls bereit:
Nächste Klärung und Verantwortlicher, falls nötig:
Hier ein ausgefülltes Beispiel für das Access-Benachrichtigungs-Item:
Benutzerergebnis: Der Dokumentenbesitzer erfährt, dass ein Mitglied des Arbeitsbereichs Zugriff angefordert hat und kann die Anfrage öffnen.
Enthalten: Nutzung des bestehenden Benachrichtigungsdienstes, Überprüfung der Berechtigungen des Empfängers, Verlinkung zur ausstehenden Anfrage und Vermeidung doppelter Benachrichtigungen bei erneutem Zustellversuch.
Ausgeschlossen: Erinnerungs-E-Mails, Tageszusammenfassungen und automatische Zugriffsgewährung.
Referenz: Unsere 2-Punkte-Einstellungsänderung nutzt einen bekannten Speicherpfad. Dieses Item kombiniert Anfrage-, Berechtigungs- und Zustellpfade, was mehr Koordination und Fehlerfälle erfordert.
Offene Frage: Verhindert der Dienst bereits doppelte Zustellungen? Der Verantwortliche des Benachrichtigungsdienstes wird das vor der endgültigen Schätzung bestätigen.
Im fiktiven Szenario der Tabelle bestätigt diese Prüfung wiederverwendbare Zustellunterstützung, und das Team stimmt 5 zu. Ohne diese Bestätigung muss das Team die zusätzliche Arbeit erst besprechen, bevor dieselbe Zahl verwendet wird. Die Referenz erklärt den Vergleich, berechnet aber nicht das Ergebnis.
Für die Sitzungsabfolge verwenden Sie den Schritt-für-Schritt-Planning-Poker-Leitfaden. Er behandelt geheime Abstimmungen, Diskussionen über Unterschiede und die Auswahl des Ergebnisses für die nächste Runde.
Wenn eine Zahl noch nicht hilfreich ist
Kehren Sie zur Klärung zurück, wenn eine Unbekannte die Art der Arbeit verändert. „Welchen Text soll die Benachrichtigung verwenden?“ ist eine andere Unsicherheit als „Erlaubt der Ziel-Arbeitsbereich externe Nutzer?“
Beim Beispiel „Ordner verschieben“ könnte das Team zunächst einem kleineren Benutzerergebnis zustimmen: Ein Dokument zwischen Arbeitsbereichen verschieben, die der Nutzer verwaltet. Dieser erste Schritt benötigt weiterhin klare Zielberechtigungen, erhaltene Zugriffsregeln und ein sicheres Fehlermanagement, damit bei einer unterbrochenen Bewegung das Dokument nicht verloren geht oder falschen Personen zugänglich wird. Das Verschieben von Dokumenten in Batches kann ein separates Item sein. Die Verkleinerung der Batchgröße reduziert den Umfang, beseitigt aber nicht die Notwendigkeit des Umgangs mit Fehlern.
Nach der Aufteilung sollte jedes Item separat geschätzt werden. Die neuen Zahlen müssen nicht wieder 13 ergeben: Das Team hat den Umfang geändert und mehr über die Arbeit gelernt.
Häufig gestellte Fragen von Teams
Wie viele Stunden entspricht eine 3-Punkte-Story?
Es gibt keine universelle Umrechnung. Die hier gezeigten Beispiele vergleichen die Arbeit innerhalb eines fiktiven Teams. Wenn Sie eine Lieferprognose benötigen, verwenden Sie Ihre eigene Lieferhistorie und aktuelle Kapazität und besprechen die Unsicherheit getrennt vom Punktwert.
Ist jeder Fehler ein 1-Punkte-Item?
Nein. Ein reproduzierbarer Darstellungsfehler mit bekanntem Grund unterscheidet sich von einem intermittierenden Datenverlust mit unbekannter Ursache. Klären Sie, was Sie schätzen: die Behebung, eine Untersuchung oder beides.
Muss jedes Team eine 13-Punkte-Story aufteilen?
Nein. Hier kennzeichnet 13 Arbeit, die dieses bestimmte Team genauer untersuchen und aufteilen möchte. Die Grenze Ihres Teams hängt von dessen Referenzen und Fähigkeit ab, ein Item zu verstehen und zu liefern.
Bringen Sie Ihre Referenzen ins Planning Poker ein
Wählen Sie einige anstehende Items, schreiben Sie deren Akzeptanzkriterien auf und bewahren Sie die Referenz-Stories daneben auf. Verwenden Sie Agilo Planning Poker für die Schätzsitzung des Teams.
Erstellen Sie einen Planning Poker-Raum, wenn die Items zur Diskussion bereitstehen.
