Schätzungen im Sprint-Planning

Lohnt es sich, im Sprint-Planning Stunden für Tasks zu schätzen?
Die Frage diskutiere ich immer wieder mit Teams, denn in der Regel ist es eines der ersten Dinge, die ich Teams abgewöhne. Der Verzicht auf die Schätzung von Stunden für einzelne Tasks im Planning führt eigentlich immer zu einem besseren weil fokussiertem Planning.

Warum man die Stundenschätzung nicht unbedingt benötigt und warum das Planning dadurch häufig besser wird, will ich im Folgenden erklären.
Schätzungen im Sprint-Planning weiterlesen

Burndown Charts im Sprint?

Diese Woche habe ich mich mit einem Kunden über den Nutzen von Burndown Charts zum Messen des Fortschritts eines Sprints unterhalten. Die Diskussion war sehr interessant, daher möchte ich die Essenz daraus in diesem Artikel teilen.

Ausgangspunkt war dass in einem Scrum-Projekt gemessen werden sollte, ob das Sprint-Ziel in Gefahr ist. Die altbekannte These „Was ich nicht messen kann, kann ich auch nicht managen“ war dabei die Leitidee. Diese Leitidee teile ich im Prinzip. Einen Burndown Chart während eines Sprints halte ich aber nicht für hilfreich, insbesondere nicht, um eine Gefährdung des Sprint-Zieles abzulesen.

Warum nicht?

Messen kann man in Scrum, ob eine Story fertig ist. Fertig ist sie, wenn sie der Definition of Done genügt und der Product Owner sie sich in einem Review angeschaut und akzeptiert hat. Der Review durch den Product Owner erfolgt üblicherweise im Sprint Review am Ende eines Sprints. Natürlich könnte man das auch während des Sprints machen, aber im Sprint soll das Team möglichst ungestört arbeiten.
Das Sprint-Ziel ist erreicht, wenn alle Stories, auf die sich das Team committed hat, am Ende des Sprints der Definition of Done genügen und vom Product Owner akzeptiert sind.
Burndown Charts im Sprint? weiterlesen

Fragen über Fragen: Test-Werkzeuge in agilen Projekten

Warum testet man Software?
Man will Sicherheit gewinnen, dass die Funktionalitäten, die man realisieren möchte, korrekt umgesetzt sind.

Warum fühlt sich Test Driven Development so gut an?
Es erlaubt, in extrem kurzen Zeitabständen Feedback über die geleistete Arbeit zu erhalten.

Das können, so glaube ich, alle unterschreiben, die in agilen Projekten unterwegs sind.
Fragen über Fragen: Test-Werkzeuge in agilen Projekten weiterlesen

Was zwischen Planning I und Planning II passiert

Die meisten Teams, denen ich bisher begegnet bin, teilen das Sprint Planning in einen ersten und einen zweiten Teil. Im ersten Teil stellt der Product Owner die Items aus dem Backlog vor, die im den nächsten Sprint entwickelt werden sollen. Das Team hat die Möglichkeit fachliche Fragen zu stellen und der Product Owner antwortet. Im Planning II zerlegt das Team die Stories in Tasks. So weit, so gut.

Die fachlichen Fragen des Teams hat der Product Owner im Planning I beantwortet. Aber was ist mit den technischen Fragen? Über diese stolpern die meisten Teams während des Planning II. Oft passiert es dann, dass sich einzelne Teammitglieder vor ihren Computer setzen und in den Tiefen des Quellcodes abtauchen – nur, um dann für den gesamten Rest des Plannings nicht mehr aufzutauchen. Das ist ärgerlich für den Rest des Teams.

Manche Teams lösen das über ein Pre-Planning der Stories im Sprint davor. Allerdings das Pre-Planning zu verschwendeter Zeit führen, nämlich dann, wenn Stories doch nicht in den nächsten Sprint kommen.

Um diese Situationen zu vermeiden, habe ich mit meinen Teams eine Phase zwischen Planning I und Planning II eingeführt.
Was zwischen Planning I und Planning II passiert weiterlesen