Alle Wege führen nach Rom, aber mit Scrum geht es schneller.
Wer sich für den Umstieg zu Scrum entschieden hat und die ersten Schritte geht, hat es am Anfang nicht leicht. Wir geben hier ein wenig Starthilfe, damit Scrum auch bei Ihnen leichter und reibungsloser läuft.
Mit diesen zwei Tipps gelingt Ihre Retrospektive und Ihr Sprint Plannig besser.
1. Retrospektive
Für die Durchführung der Retrospektive hat sich bei uns folgendes Vorgehen bewährt: zu Beginn des Events erhält jedes Mitglied des Scrum Teams Post-its und einen Stift. Darauf werden alle positiv und negativ wahrgenommenen Dinge während des letzten Sprints notiert. Jedes Mitglied stellt anschließend die Punkte kurz vor und klebt die Post-its auf ein Whiteboard. Wenn alle Mitglieder ihre Punkte aufgeführt haben, werden die Post-its thematisch sortiert, meist lässt sich alleine schon an der Anzahl der Posts sehen, welches Thema die größte Priorität haben sollte. Es gilt also: Umso mehr Post-its zu einem Thema, desto wichtiger ist dieses Thema. Danach wird jedes Thema systematisch diskutiert - von der höchsten zur niedrigsten Priorität. Verbesserungsvorschläge werden schriftlich festgehalten und mindestens einer der Verbesserungsvorschläge fließt direkt in den nächsten Sprint ein und wird im Sprint Backlog festgehalten.
Folgende Fragen sind Scrum-Standard:
- Was haben wir so gut gemacht, dass wir darüber reden müssen, um es nicht zu vergessen?
- Was haben wir gelernt?
- Was müssen wir künftig anders machen?
- Was haben wir noch nicht verstanden?
Es gibt unzählige Möglichkeiten die Retrospektive noch leichter zu gestalten. Beispielsweise können folgende Fragen auf einem Whiteboard angebracht werden. Diese können von allen Teammitgliedern beantwortet werden.
- Was lief gut, was müssen wir fortsetzen?
- Welche Tätigkeit müssen wir intensivieren?
- Welche Tätigkeit müssen wir drosseln?
- Welche neue Idee müssen wir sofort aufgreifen?
- Was lief weniger gut, was müssen wir sein lassen?
2. Sprint Planning
Um Stories, Tasks und Bugs aus dem Product Backlog während des Sprint Plannings zu schätzen, empfehlen wir folgendes für den Planning Poker. Nutzen Sie bereits vorhandene geschätzte Vorgänge als Referenz für Ihre Schätzung der Story Points. Sollte es sich um den 1. Sprint handeln, kann es sinnvoll sein, in diesem noch keine Schätzung abzugeben. Dafür können im 2. Sprint einer Story, Story Points aus dem 1. Sprint zugeordnet werden. Dann lässt sich diese als Referenz für die Schätzung der Stories aus dem 2. Sprint heranziehen.
Achten Sie darauf, dass die Schätzung der Vorgänge alleine in der Verantwortung des Entwicklerteams liegt. Weder der Product Owner noch der Scrum Master dürfen sich in diese Schätzung einmischen. Das könnte dazu führen, dass Vorgänge in einem Sprint nicht abgeschlossen werden können, da sie unterschätzt werden.
Erfahrungsgemäß ist es immer besser, eine konservative und nicht all zu positive Schätzung abzugeben. Auch wenn Vorgänge genau erörtert scheinen, ergeben sich doch oft unvorhergesehene Ereignisse und Schwierigkeiten, die die Entwicklung verzögern. Kommen viele unterschätze Vorgänge in einem Sprint zusammen, artet der Sprint für die Entwickler in Stress aus, was zu Fehlern und zu unsauberem Arbeiten führt, oder schlichtweg darin, dass die Stories nicht abgeschlossen werden können.
Sie stehen noch ganz am Anfang und verstehen nur Bahnhof?
Wir bieten Scrum Schulungen an, um Ihnen den Einstieg in das Thema zu erleichtern.
kununu