Wie groß sollte jede Geschichte für eine Person im 3-wöchigen Sprint sein?

TL; DR

Grundsätzlich sind Ihre gesamten Planungsannahmen nicht agil. Sie müssen erneut prüfen, wie Sie Ihre Iterationen planen und wie Ihr Team plant, die Arbeit zu schätzen, die seiner Meinung nach für die aktuelle Iteration abgeschlossen werden kann. Eine detailliertere Analyse folgt.

Detaillierte Analyse

Wir wissen, dass die langfristige Planung (Release-Planung) in Story-Punkten erfolgen sollte. [sic]

Nein. Die agile Release-Planung erfolgt in Iterationen . Daher schätzt ein Scrum-Projektplan einen ungefähren Bereich von Iterationen, die erforderlich sind, um das minimal lebensfähige Produkt zu erreichen oder das anfängliche Product Backlog zu vervollständigen. Dies ist nur möglich eine Schätzung, da sich der Backlog-Inhalt im Laufe der Zeit ändert und sich Länge und Genauigkeit der Schätzungen zusammen mit dem Unsicherheitskegel ändern.

Für die Sprint-Planung sollte sie jedoch auf Commitment basieren.

Auch hier ist die Sprint-Planung nein kapazitätsbasiert . Der einzige Verfolgungspunkt (oder Erstellen einer ersten Schätzung der Durchschnittsgeschwindigkeit des Teams besteht darin, die nachhaltige Arbeitsfähigkeit des Teams im Laufe der Zeit zu ermitteln. Während das Team sicher sein muss, sich niemals zu sehr für die Arbeit in einem Sprint zu engagieren, nur weil der Geschwindigkeitsbereich oder der Durchschnitt angibt, dass Kapazität verfügbar sein sollte, liegt es in der Verantwortung des Teams, die aktuelle Iteration unter Berücksichtigung der Teamzusammensetzung und Verfügbarkeit zu planen und andere Faktoren , die sich auf den aktuellen Sprint auswirken.

Die Aussage, dass Sprints „auf Engagement basieren“, wird wahrscheinlich als emotionaler Knüppel verwendet, um Teams dazu zu bringen, sich zu engagieren mehr arbeiten als sie sollten, da die Teammitglieder natürlich „engagiert“ sein sollten. Dies ist jedoch ein Missbrauch. In der realen Welt sollte die Teamkapazität im Allgemeinen reduziert, aber während der Planung selten aufgeblasen werden. Wenn sich das Team zu wenig engagiert hat, kann bei Bedarf zusätzliche Arbeit aus dem Product Backlog entfernt werden. Die Einschränkung des Umfangs ist jedoch fast immer politisch belastet und gefährdet häufig das Sprint-Ziel. Tun Sie das also nicht.

Kapazität kann eine relativ objektive Metrik sein. Andererseits kann Engagement (ähnlich wie Patriotismus) „nur gemessen werden, wenn Sie“ Bitten Sie die Menschen, „das ultimative Opfer zu bringen“, was der gesamten Prämisse agiler Nachhaltigkeit widerspricht. Verpflichten Sie sich niemals zu einem Todesmarsch .

Wie groß sollte für einen dreiwöchigen Sprint jede Geschichte für eine Person sein?

Dies verdient ein ganzes Buch, das mit „Nein“ gefüllt ist. Geschichten werden niemals für eine Person bewertet oder von einer Person akzeptiert. Alle Geschichten werden auf der Grundlage der vollständigen, koordinierten Ressourcen eines funktionsübergreifenden Teams geschätzt, das zusammenarbeitet , um jede Geschichte zu vervollständigen. Die Geschichten werden akzeptiert oder abgelehnt, je nachdem, ob:

1. Sie für das aktuelle Sprint-Ziel wesentlich sind.
2. Sie passen in die geschätzte Kapazität verfügbar für den aktuellen Sprint.

Ein einzelnes Product Backlog-Element kann beliebig sein Von 0 Story-Punkten bis zum Maximum, das für den gesamten Sprint verfügbar ist. Eine gute Story, die die INVEST-Kriterien erfüllt, besteht im Allgemeinen aus Sprint Backlog-Aufgaben mit einer Länge von etwa 0,5 bis 2,0 Tagen. Denken Sie daran, dass die Schätzung normalerweise umso genauer ist, je kleiner die Aufgabe oder die Story ist. Daher sind ein Dutzend 5-Punkte-Storys (wenn sie genau geschätzt werden) im Allgemeinen zuverlässiger als eine einzelne 60-Punkte-Story. Die Reife Ihres Teams und die Genauigkeit der Schätzung können jedoch durchaus variieren.