Sprint Planning? – so ein Nonsens

Ein Sprint Planning, das den PI Plan (maßgeblich) verändert, ist ein No-Go!

SAFe, ein Framework für Projekte an denen mehrere Teams an einer sogenannten Solution arbeiten, sieht am Anfang eines jeden Program Increments (PI) ein PI Planning vor. Ein großes Event, bei dem alle Teams samt RTEs, Product Manager, Architects und auch alle Stakeholder und der eine oder andere Manager zusammenkommen, um das nächste Program Increment zu planen. Wenn nicht gerade eine Pandemie ihr Unwesen treibt, ist das PI ein Big Room Planning, das von so manch Abstimmungsrunde in kleinerem Rahmen flankiert wird. Zumeist dauert es zwei ganze Tage.

Folgt man der vorgegebenen Agenda, dann findet am Ende des ersten Tages – nachdem die Teams schon viel Energie in die Erstellung des Plans der Sprints des anstehenden PIs investiert haben – ein Management Review statt. In diesem Meeting versucht das Management Probleme aus dem Weg zu räumen, die von den Teams im Rahmen des Plannings identifiziert wurden. Gegebenenfalls wird der Scope ein wenig geändert und / oder es werden Beschlüsse bezüglich erforderlicher Ressourcen gefällt. Mitunter werden Kraft der Entscheidungsbefugnis der anwesenden Manager:innen hinderliche Dependencies aufgelöst.

Grundvoraussetzungen für ein (PI) Planning

Ein Planning ist ein Matching zwischen Angebot und Nachfrage. Der Bedarf, spezifiziert über die User Stories, muss mit den vorhandenen Kapazitäten abgeglichen werden. Um ein (PI) Planning sinnvoll durchführen zu können, bedarf es

• der Kenntnis der (zumindest ungefähr) verfügbaren Kapazitäten und
• der Kenntnis darüber, wie viel Aufwand (ungefähr) in der Umsetzung der einzelnen User Stories steckt.

Um den Aufwand schätzen zu können, der in etwa in der Umsetzung einer Anforderung steckt, bedarf es oftmals – je nach Größe der Anforderung – eines sogenannten Task Breakdown. Wenn die Umsetzungsschritte grob bekannt sind, kann man über den Daumen hinweg eine Aufwandsschätzung durchführen.

Die Aufwandsschätzungen für alle Anforderungen (User Stories, Tasks, etc.), die im Rahmen eines PIs umgesetzt werden sollen, sollten im Rahmen der Refinements durchgeführt werden. Siehe dazu auch Continuous Exploration.

Story Points??? – oftmals ein Schmarrn

Aus welcher Notwendigkeit heraus, so fragt sich der Autor dieses Blogs, ist die Erfindung einer kryptischen Fremdwährung zur Schätzung des Aufwands von Anforderungen entstanden?

Ein Plan ist ein Plan ist ein Plan.

Soll heißen, dass die Unwägbarkeiten des Lebens immer wieder gegen diesen Plan schießen. Da wird der eine oder andere Entwickler krank, weil draußen oftmals ein Sauwetter herrscht. Die eine oder andere Aufwandsschätzung ist daneben gegangen. Man hat sich grob verschätzt. Und dann gibt es da noch Menschen, die unvermittelt nicht nur das Projekt sondern gleich das Unternehmen verlassen. All diese Unwägbarkeiten müssen agile gehandhabt werden. Es muss darauf reagiert werden, weil sie den Plan in Gefahr bringen.

Eine gängige Methode auf solche “Hickups” zu reagieren könnte sein, die eine oder andere User Story von einem Team in ein anderes Team zu verschieben. Beim “anderen” Team eine weniger wichtige Anforderung herausnehmen und die wirklich wichtige User Story des “Hickup-Teams” dort umsetzen lassen. Klar, das funktioniert oftmals nur unter “Bauchschmerzen”, weil nicht jedes Team in jedem Themenbereich die gleiche Expertise hat. Oftmals ist es dann sinnvoll die ursprüngliche Schätzung noch einmal um einen dicken Puffer zu vergrößern; aus 3 PDs mach 5 PDs.

Wie aber soll das erfolgen, wenn man so gar keine Ahnung darüber hat, was denn die 12 Story Points, die das eine Team geschätzt hat, tatsächlich bedeuten?

Fakt ist, dass Story Points zumeist eine teamspezifische Wertigkeit haben. Der Wert des Story Points des einen Teams entspricht selten der Wertigkeit des Story Points eines anderen Teams.

12 Story Points des einen Teams mögen 5 Story Points eines zweiten Teams und 18 Story Points eines dritten Teams gleichzusetzen sein. Wie soll hier das Product Management, in Zusammenarbeit mit den Product Ownern der einzelnen Teams, ein Shifting von Anforderungen vornehmen können?

Zeit ist eine gute Metrik

Ab dem Moment, ab dem wir in den Kindergarten müssen (weil Mama und / oder Papa zur Arbeit müssen), hat uns die Zeit am Wickel.

Die Uhr können wir zu diesem Zeitpunkt wahrscheinlich noch nicht lesen, doch stinkt es uns gewaltig, dass wir nun nicht mehr ausschlafen können. Früh am Morgen werden wir aus dem Schlaf gerissen. Haben wir den Kindergarten (halbwegs) überstanden, geht es fast übergangslos zur Schule. Über viele, viele, viele Jahre begleitet uns ein Stundenplan. Eine Schulstunde dauert 45 Minuten. Ist der Schultag kurz, endet die Quälerei um 12:00 Uhr oder 13:00 Uhr; ist er lang, erst am (späten) Nachmittag.

Gegen 18:00 Uhr treffen wir uns mit Freunden. Das haben wir so verabredet.

Lange Rede kurzer Sinn: Von Kindesbeinen an leben wir mit der Zeit. Wir lernen die Uhr zu lesen, erfahren wie langsam oder schnell die Zeit oftmals verrinnen kann. Jeder bekommt mit der Zeit ein Gefühl dafür, respektive weiß irgendwann wie lange ½ Tag, ein ganzer Tag, 4 Tage oder zwei Wochen dauern.

Klar, wir können uns immer noch verschätzen, aber der eine Entwickler zum anderen Entwickler sagt …

Conclusio

Das Scrum Sprint Planning macht nicht mehr wirklich Sinn, wenn ein Scrum Team als Teil eines Agile Release Trains an einer Solution arbeitet. Die Freiheit als Schätzmetrik Zeit, Story Points, T-Shirt-Größen oder gar Hunderassen wählen zu können, hat dort seine Grenzen, wo ein Miteinander aller Teams – zum Wohle einer zu entwickelnden Solution ein großes, funktionsfähiges, Ganzes ergeben muss.

Nachdem SAFe auch eine sogenannte Cadence – siehe SAFe Prinzip #7 – als sinnvoll und notwendig erachtet, sollten einzelne Scrum Teams eines Agile Release Trains auch nicht selbst über die Sprint-Länge entscheiden dürfen.