Wie setzt man Story Points, wenn zwei Personen gemeinsam an demselben Gegenstand arbeiten?

Umgang mit Punkten im folgenden Szenario:

Wir haben eine Story auf 4 Punkte gesetzt, weil das Team glaubt, dass der Arbeitsaufwand insgesamt 4 Punkte beträgt. Um diese Geschichte vervollständigen zu können, müssen zwei Personen mit ihrem Spezialwissen zusammenarbeiten.

Dies bedeutet nicht, dass die erste Person die erste Hälfte macht, dann die nächste Person die zweite Hälfte, sie müssen alle vier Punkte zusammen machen, zum Beispiel durch Paarprogrammierung.

Es scheint unfair zu sagen, dass wir, wenn beide Personen in einem Sprint jeweils 8 Punkte haben, vier 4-Punkte-Geschichten einfügen können. Da beide zusammenarbeiten werden, passen nur 2 Vier-Punkte-Geschichten.

Wie geht man damit um? Sollen die Punkte der Geschichte erhöht oder die Kapazität der Leute irgendwie gesenkt werden?

Antworten (2)

Erstens ist es wichtig zu erkennen, dass Velocity nicht pro Person gemessen wird, sondern ein Maß für die Fähigkeit des Teams ist, Arbeit in einem Sprint zu liefern. In jedem Sprint vervollständigt Ihr Team so viele Story Points. Sie verwenden dies, um zu bestimmen, wie viele Elemente in den nächsten Sprint eingebracht werden sollen, basierend auf der Historie und unter Berücksichtigung des Aufwands der Mitarbeiter.

Jedes Element im Product Backlog hat eine vom Team geschätzte Anzahl von Story Points. Sie sollten die Größe eines Elements im Product Backlog nicht danach schätzen, wie lange es dauern wird oder wie viele Personen dafür benötigt werden, sondern anhand der relativen Komplexität. Eine User Story, die per Definition zwei Personen mit Spezialwissen erfordert, ist komplexer als eine, die dies nicht tut. Daher sollte sie mehr Punkte wert sein als eine User Story, die kein Fachwissen erfordert oder eine, die weniger Fachwissen erfordert.

Wenn Sie mit der Planung auf Teamkapazitätsebene statt auf individueller Kapazitätsebene beginnen und Komplexität statt Aufwand und Zeit berücksichtigen, dann denke ich, dass sich Ihre Probleme von selbst lösen werden.

Danke für eine tolle Antwort! Also im Grunde sollten wir uns die Gesamtkapazität für das Team ansehen, dann unseren Geschichten einige zusätzliche Punkte hinzufügen, wenn sie sehr viel komplexer sind als die einfachsten, und dann unsere Sprints auf die Gesamtkapazität aufladen? Dann ziehen wir bei der Ausführung einfach die Gegenstände. Wenn zwei Personen benötigt werden, verwenden wir zwei Personen, wenn mehr oder weniger benötigt werden, verwenden wir, was anwendbar ist? Dann lernen wir später aus der Geschwindigkeit und laden unsere Sprints entsprechend?
@Michael Sie sollten keine "zusätzlichen Punkte hinzufügen", wenn sie komplexer sind. Sie sollten einfach mehr Punkte haben. Punkte sollten ein Maß für die Komplexität sein. Sie sollten auch so viele Leute wie nötig einsetzen, um die Arbeit zu erledigen, und versuchen (so viel wie möglich), Wissen zu teilen. Die Leute sind vielleicht nicht die Experten, aber je mehr sie wissen und können, desto besser für das Team, wenn jemand krank wird, Urlaub nimmt oder das Unternehmen verlässt.
Ah, Entschuldigung, ich meinte den Teil des Hinzufügens nicht in diesem Sinne, ich meinte es eher so, wie Sie es geschrieben haben :) Ich mag den Teil des Wissensaustauschs. In unserem Team hat jede Person ihren eigenen Bereich/ihr eigenes Produkt und wir finden es wirklich schwierig, Dinge zu teilen, da diese einzelne Person die Arbeit schneller erledigt, ohne dass die anderen beiden herumhängen, aber ich denke, das ist keine Entschuldigung in der agilen Welt.

Story Points spiegeln die relative Größe und Komplexität einer Story wider. Das heißt, der Aufwand, der erforderlich ist, um eine Geschichte abzuschließen, ist das einzige Maß, um einer Geschichte Punkte zuzuweisen. Wenn Ihre PBI so komplex ist, dass zwei Personen daran arbeiten müssen, sollten Sie mehr Punkte vergeben als bei einer ähnlich großen PBI, die von nur einer Person abgeschlossen werden kann. Ich denke nicht, dass die Kapazität dafür künstlich gesenkt werden sollte, da dies Ihre Metriken wie die Teamgeschwindigkeit fälschlicherweise beeinflusst.

Entschuldigung für meine Unwissenheit, aber wofür steht PBI?
@michael PBI ist Product Backlog Item