Dieser Beitrag soll kein weiterer Artikel darüber sein, was Scrum Planning ist. Wir gehen davon aus, dass dieses Konzept bereits bekannt ist. Falls doch nicht, könnten wir als Einleitung Folgendes zusammenfassen.
Es handelt sich um ein Verfahren mit einem Zeitrahmen (Time Box), bei dem unter allen Teammitgliedern (auch dem Scrum Master), basierend auf einem definierten Ziel, entschieden wird, WAS durchgeführt und WIE es durchgeführt wird.
In diesem Artikel werden wir uns auf das „WIE“ konzentrieren. In dem vorgegebenen Zeitrahmen sollte das Entwickler-Team die Entscheidung treffen, ob ein Hauptthema in kleine Aufgaben aufgeteilt werden soll. Das bedeutet, die Arbeit soll so organisiert werden, dass eine Erreichung der Ziele am Ende des Sprints sichergestellt ist.
Unser Team arbeitet nach den Prinzipien der eXtreme-Programmierung, wie CI/CD, TDD, Pair Programming, Automation und Devops (als Einstellung).
Unter Berücksichtigung dieser Prinzipien haben wir einige Regeln definiert, die uns bei der Durchführung der Arbeitsteilung helfen. Diese Regeln sind:
- Wir definieren einzelne Aufgaben auf der Grundlage der Definition Of Done (DoD). Hierzu spezifizieren wir das DoD auf der Ebene der Themen in technische Aufgaben und nicht-technische Aufgaben. Diese Vorgehensweise hilft uns zu erkennen, wann eine Aufgabe wirklich als Done gekennzeichnet werden kann.
- Wir machen Pausen, wenn sich jemand ausruhen muss. Dies ist wichtig, denn obwohl der Scrum-Guide Pausen als Time-Box-Event definiert (maximal eine Stunde für Sprints mit der Dauer von einem Monat), ziehen wir es vor, nicht den Druck einer Time Box zu haben. Unsere Planung (einschließlich der Auftragsvergabe) wird also so lange dauern, wie es sein muss. Um die Qualität nicht zu mindern, ist es notwendig Pausen zwischen den einzelnen Aufgaben zu machen.
- Wir definieren die Aufgaben auch auf der Grundlage des folgenden Zeitrahmens: an einem Arbeitstag muss das Pensum erledigt, also in Done, sein. Dies mag etwas aggressiv erscheinen, aber wir tun dies aus mehreren Gründen:
- Es hilft uns, Abweichungen zu erkennen
- Wenn eine Aufgabe mehr als einen Tag dauert, um ins Done überzugehen, wenden wir Pair Programming an (falls wir es nicht schon nutzen) oder unterteilen sie in eine andere Aufgabe.
- Wir vermeiden Engpässe: kurze Aufgaben implizieren kurze Überprüfungen. Wenn sie mit Pair Programming und TDD durchgeführt werden, ist es außerdem nicht notwendig, eine Pull-Anfrage (pull request) zu stellen (trunk based development).
- Wir verlieren den Fokus nicht aus den Augen, entweder indem wir einen Edge Case detailliert darlegen, welchen wir bei der Umsetzung testen müssen, oder indem wir den Fokus auf einen Refaktor legen, der die technische Verschuldung bereinigt.
- Es entstehen weniger Blocks und Konflikte wenn mehrere Entwickler auf demselben Branch arbeiten. Die Änderungen kommen dadurch schnell auf dem Master Branch an und werden schnell in live/staging deployed.
- Bei der Definition von Aufgaben stützen wir uns auch auf den Quellcode, mit dieser Praxis sammeln wir Erfahrungen, wie wir an die Lösung herangehen können.
- Wenn es sich um ein Thema handelt, bei dem keine Vorerfahrung vorhanden ist, beziehen wir erfahrene Dritte in die Planung mit ein, um dem Team zu helfen und es zu beraten.
- Die sehr komplizierten Aufgaben werden als „Pairing mandatory“ gekennzeichnet.
Wir haben natürlich keine Kristallkugel, um zu sehen, ob die definierten Aufgaben ausreichen oder eventuell zu viele sein werden. Besonders in den ersten Wochen, wenn ein Scrum-Team mit der Arbeit beginnt, kann dies passieren. Wir lernen jedoch aus jedem Sprint, und die hier genannten Regeln helfen uns, immer mehr erfolgreiche Sprints zu erzielen.
