Alle Wege führen nach Rom, aber mit Scrum geht es schneller.

Wer sich für den Umstieg entschieden hat und die ersten Schritte geht, hat es am Anfang nicht leicht. Wir teilen gerne unsere Erfahrungen, damit Scrum auch bei Ihnen leichter und reibungsloser läuft. Mit diesen zwei Tipps gelingt Ihre Retrospektive und 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, umso wichtiger ist dieses Thema. Danach wird von der höchsten zur niedrigsten Priorität systematisch jedes Thema diskutiert. 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?

Wenn man die Retrospektive noch leichter beziehungsweise spielerischer gestalten will, gibt es unzählige Möglichkeiten dazu. Zum Beispiel ein Seestern wird vom Scrum Master auf Whiteboard gezeichnet. Die Fragen kommen auf die Seesternarme drauf und anschließend werden die Post-its zu den Fragen einsortiert.

• 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, könnte es Sinn machen, in diesem noch keine Schätzung abzugeben. Dafür könnten dann aber im 2. Sprint einer Story aus dem 1. Sprint Story Points 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. Sollten sie sich dennoch einmischen, kann es dazu führen, dass Vorgänge in einem Sprint nicht abgeschlossen werden können also unterschätzt werden.
Erfahrungsgemäß ist es immer besser, eine konservative und weniger eine positive Schätzung abzugeben. Auch wenn Vorgänge genau erörtert scheinen, ergeben sich doch oft unvorhergesehene Ereignisse und Schwierigkeiten, die die Entwicklung verzögert. Kommen viele unterschätze Vorgänge in einem Sprint zusammen, artet der Sprint für die Entwickler in Stress aus, was zu Fehlern und unsauberem Arbeiten führt, oder schlichtweg darin, dass die Stories nicht abgeschlossen werden können.