Größe von Sprint Backlog Items

Der Aufwand (Estimated Effort) zur Umsetzung von Sprint Backlog Items wird häufig in Stunden definiert. Hier empfiehlt Roman Pichler den Aufwand von maximal einem Nettoarbeitstag, damit Fortschritt gut fühlbar wird. Ich habe aus anderer Quelle von maximal 16h und minimal einem halben Tag gelesen, um Micromanagement zu verhindern.

Ich orientiere mich in der Regel zwischen 0-16 Stunden. Jedoch finden 16 Stunden Tasks nur dann Verwendung, wenn die Aktivität sehr schlecht gesplittet werden kann oder die Splittingdiskussion von den Teammitgliedern im Planungsmeeting nicht getragen wird. Eine Aufteilung während des Sprints ist dann immer noch möglich.

Aufwandsschätzung mit PlanningPoker und TFS

Zur Aufwandsschätzung eignet sich für verteilte aber auch lokale Teams mit jeweils eigenem Notebook gut der kostenlose Dienst von www.planningpoker.com.

Um mit diesen System eine gute Aufwandsschätzung in Zusammenspiel mit dem Microsoft Team Foundation Server und einem Scrum Template durchführen zu können empfehle ich das folgende Vorgehen:

• Export aller nach ID absteigend sortierter Product Backlog Items vom TFS zu Excel (mit dem Add-In)
• Ersetzen aller Zeilenumbrüche in den User Stories, da PlanningPoker damit nicht umgehen kann (In Excel kann man "Suchen und Ersetzen" verwenden, indem man nach Strg+J sucht (Achtung: man sieht kein Zeichen im Suchfeld, dies ist aber der Shortcut für einen Zeilenumbruch in der Suche) und ersetzt durch gar nichts.
• Dann über die Zwischenablage inkl. Header in Planningpoker.com importieren.
• Nach der Schätzung die Daten als CSV herunterladen und nur die Aufwandsschätzung importieren (da die Werte nach der ID sortiert sind, sollte man nur die Aufwandsspalte kopieren müssen in die Excelliste)
• Zurück einspielen der Exceldaten in den TFS

Übrigens sollte man für eine Aufwandsschätzung genügend Zeit einplanen. Abhängig davon, wie vertraut das Team mit dem System ist, wie komplex und wie groß die User Stories sind und wie viele Teammitglieder schätzen, kann so eine Schätzung schon einige Stunden für ein initiales Product Backlog dauern. 15 User Stories pro Stunde sind da bisher meine Erfahrungswerte bei großen User Stories.

Was sind Story Points?

Story Points sind eine Schätzgröße für User Stories. Sie werden verwandt, um dem Product Owner und auch dem Team ein Gefühl für die Größe / Komplexität einer Anforderung zu vermitteln. Für ihn ist es dann leichter, eine Priorisierung vorzunehmen. Man verwendet hier häufig eine Fibonacci Zahlenreihe, damit keine Diskussionen entstehen, ob ein Backlog Item 3 oder 4 Story Points groß ist.

Die Story Points aller abgeschlossenen User Stories in einem Sprint werden am Sprintende summiert, was die Teamgeschwindigkeit ergibt. Im nächsten Sprint können dann wieder so viele Stories eingeplant werden, wie die Teamgeschwindigkeit zulässt.

Was genau Story Points definieren, kann das Team selbst festlegen. Es ist eine abstrakte Größe ohne Bezug zu Zeit oder Kosten. Eher etwas wie Größe oder Komplexität. Hat "Story A" zwei Story Points ist sie halb so groß wie "Story B" mit vier Story Points. Auf jeden Fall sind Story Points immer relativ zu anderen Story Points zu sehen.

Wenn man ein Product Backlog vollständig mit Story Points geschätzt hat, hat jedes Product Backlog Item (PBI) einen Wert, welche die relative Größe zu anderen PBIs angibt.