Die Frage, die sich viele stellen, lautet: Sollten wir Product Backlog Items in Story Points oder in Stunden/Zeit angeben? Und wenn man Aufgaben in Story Points ausdrückt, kann man sie dann nicht auch in Stunden zurückrechnen? In diesem Beitrag geht es um Story Points, um die Vor- und Nachteile und um die Antworten auf all Ihre anderen Fragen zu Story Points.
Was ist ein Story Point?
Beginnen wir am Anfang: Story Points sind ein Werkzeug, das in Agile und in Scrum verwendet wird, um abzuschätzen, wie hoch der „Aufwand“ für die Fertigstellung des Product Backlog Items aus dem Product Backlog ist. Ein Story Point wird einem Product Backlog Item zugewiesen und ist somit eine Kombination aus:
Die Komplexität des Product Backlog Items
- Wie komplex ist das Item im Vergleich zu anderen Product Backlog Items?
- Handelt es sich um eine einfache oder komplexe Aufgabe?
- Gibt es irgendwelche Abhängigkeiten für die Durchführung der Arbeit?
Die Risiken bei der Ausführung des Product Backlog Items
- Über welche Aufgaben wissen wir derzeit nicht Bescheid?
- Was sind die Erfahrungen mit anderen Product Backlog Items?
- Gibt es Unsicherheiten bei der Durchführung der Arbeit?
Aufwand oder Umfang der Arbeit
- Was muss alles getan werden, um das Item zu vervollständigen?
- Ist es klein/groß/durchschnittlich?
- Wie viel Arbeit wird das Product Backlog Item kosten?
Anstatt sich also auf die Anzahl der Arbeitsstunden zu konzentrieren, können Sie mit Hilfe von Story Points objektivere Schätzungen vornehmen und die Verteilung der Arbeit während eines Sprints besser steuern.
Wann werden die Story Points verteilt?
Story Points werden normalerweise in einer Refinement-Sitzung vergeben, in der jedes Teammitglied Story Points für einzelne Aufgaben vergibt. Dies wird in der Scrum-Sprache auch als „Poker“ bezeichnet.
Da jeder für sich Punkte vergibt, kommen frühere Erfahrungen mit ähnlichen Aufgaben sowie die unterschiedlichen Fähigkeiten der einzelnen Teammitglieder ans Tageslicht (wodurch verhindert wird, dass das Gespräch in emotionale Diskussionen ausartet). Durch die Verwendung von Story Points wird die Diskussion auf Dinge wie Komplexität und Machbarkeit gelenkt und nicht auf Diskussionen über Randthemen.
Vorteile von Story Points gegenüber der Schätzung in Stunden
Nachdem wir nun wissen, wie die Story Points verteilt werden, können wir die Vorteile von Story Points gegenüber stundenbasierten Schätzungen betrachten.
Die Schätzung in Story Points ist schneller.
Es klingt verrückt, aber Teams, die Product Backlog Items in Stunden ausdrücken, gehen oft auf eine tiefere Ebene. Untersuchungen haben gezeigt, dass die Schätzung um bis zu 60 % schneller erfolgen kann, denn ohne Story Points ist es unwahrscheinlicher, dass ein Konsens darüber erzielt wird, wie viele Tage es dauern wird.
Story Points sind relativ zueinander.
Es spielt also keine Rolle, ob unsere Schätzungen richtig, leicht falsch oder völlig falsch waren. Wichtig ist nur, dass die Schätzungen konsistent sind und relativ zueinander bleiben.
Die Story Points sind für alle gleich (auch für komplexe Aufgaben).
Es spielt also keine Rolle, ob ein Senior- oder Junior-Entwickler die Story aufgreift. Was zählt, ist, wie viel größer ein Product Backlog Item ist als ein anderes, und auf diese Weise kann auch komplexe Arbeit objektiv richtig eingeschätzt werden.
Story Points ermöglichen einen indirekten Wissensaustausch.
In einem agilen Team kann es viele verschiedene Teammitglieder geben, wie z. B. Programmierer, Tester, Designer, Product Owner usw. Aber durch die gemeinsame Schätzung lernt jeder von der Arbeit des anderen und sorgt indirekt für den Wissensaustausch untereinander.
Objektivere Beurteilungen
Story Points führen im Allgemeinen zu objektiveren Beurteilungen und oft zu weniger hitzigen oder emotionalen Diskussionen.
Kurz gesagt, wenn Story Points verwendet werden, können agile Teams genauere und objektivere Beurteilungen vornehmen, ohne Verpflichtungen einzugehen, und sich stärker auf den Wert und den Wissensaustausch konzentrieren.
Nachteile bei der Verwendung von Story Points?
Die Verwendung von Story Points funktioniert nicht automatisch bei jedem Team reibungslos. Manchmal können bei der Schätzung von Product Backlog Items Probleme auftauchen, nämlich:
Story Points sind weniger intuitiv.
Vielleicht haben Sie es schon einmal gehört: „Diese Aufgabe fühlt sich für mich eher wie 5 Story Points an, während alle anderen denken, es sei eine Nummer 2“.
Das Problem mit Story Points ist, dass sie ab einem bestimmten Punkt nicht mehr intuitiv sind und man sich mehr auf die Anzahl der Story Points konzentriert als auf die Arbeit, die für die jeweilige Aufgabe erledigt werden muss. Kommentare, die ich manchmal höre, sind: „Was ist der Unterschied zwischen 2 oder 3 Story Points?“ oder ,,Warum können wir nicht einen Durchschnitt von 3 oder 5 Punkten bilden?“. Versuchen Sie in solchen Fällen, sich auf die Arbeit zu konzentrieren, die erledigt werden muss.Story Points werden schwierig, wenn sie von einer bestimmten Person ausgeführt werden müssen.
Es kann vorkommen, dass ein Senior-Entwickler aus dem Team einem Product Backlog Item 3 Punkte zuweist, während ein Junior-Entwickler es mit 13 Punkten schätzt. Der Einfachheit halber wird dann oft 3 Punkte gewählt, weil es dann wahrscheinlich am wenigsten Aufwand bedeutet. Aber alle Aufgaben in einem Sprint Backlog sollten von allen abgeholt werden können, sonst kann es zu Problemen führen, wenn der Juniorentwickler sie doch abholen muss.
Story Points können für nicht projektbezogene Aufgaben problematisch sein.
Die meisten Product Backlog Items werden in User Stories übersetzt, aber die Schätzung von Bugfixes, das Schreiben von E-Mails oder andere „normale“ Aufgaben machen es schwierig, dies als Story Point zu schätzen.
Also Story Points in Stunden ausdrücken?
Kurz gesagt, wenn die oben genannten Vor- und Nachteile berücksichtigt werden, können wir die zentrale Frage beantworten. „Ist es eine gute Idee, Story Points in Stunden auszudrücken?“ Die Antwort lautet: Nein. Versuchen Sie, dies zu vermeiden und in Punkten auszudrücken!
Die Angabe von Story Points in Stunden macht den größten Vorteil von Story Points zunichte. Durch die Verwendung von Story Points stellen Sie sicher, dass Teammitglieder, egal ob Junior oder Senior, den Umfang der gemeinsamen Arbeit einschätzen können, indem sie gut miteinander kommunizieren und Wissen austauschen.
Durch die Verwendung von Story Points können die Teammitglieder gemeinsam in einer offenen Diskussion entscheiden, wie viel Arbeit ein Product Backlog Item für das gesamte Team bedeutet. Ein Senior-Entwickler könnte beispielsweise ein bestimmtes Product Backlog Item in einer bestimmten Zeit fertigstellen, während ein Junior-Mitarbeiter dafür 4x so lange braucht: Gemeinsam können sie sich darauf einigen, dass es 2 Punkte als Story Point wert ist.
Dann können sie sich ein anderes Product Backlog Item ansehen und feststellen, wie viel mehr Aufwand/Komplexität/Risiko es im Vergleich zum vorherigen beinhaltet. Schließlich sollten alle Aufgaben in einem Sprint Backlog von jedem übernommen werden können, oder es kann zu Problemen führen, wenn der Juniorentwickler sie trotzdem übernehmen muss.
Zusammenfassend lässt sich sagen, dass die größten Vorteile von Story Points darin bestehen, dass Sie in einer offenen Diskussion abstrakte Zahlen nennen, dass die Story Points für alle Mitglieder eines Teams gelten und dass sie objektivere Schätzungen ermöglichen. Wenn man die Story Points in Stunden ausdrückt, fallen viele Vorteile wieder weg, weshalb der Rat lautet, sich nur an Story Points zu halten.
