Jedes Softwareunternehmen hat eine IT- oder Digitalstrategie und natürlich arbeiten sie alle agil. Doch was ist dazwischen? Wie aligniert man einen Sprint-Scope (2 Wochen) mit strategischen Zielen über 3-5 Jahre? Das «Epic Planning» bietet gerade für kleinere Unternehmen einen agilen und sehr effizienten Lösungsansatz mit überschaubarem Aufwand.
Die mitunter grösste Herausforderung in der agilen Transformation, insb. kleinerer Unternehmen, liegt im strategischen Alignment. Die iterative Arbeit in Sprints von 2 bis 3 Wochen schafft sehr kurze Feedback-Zyklen und erlaubt schnelle Optimierungen. Viele Teams und Unternehmen verfallen im Zuge der «Agilisierung» ihrer Prozesse in einen gewissen Opportunismus oder gar Planlosigkeit, obwohl die Vision und Strategie wohlbekannt sind. Es gibt keine mittelfristige Planung mehr, welche die taktischen Prioritäten setzt und Leitplanken für die operative Arbeit festlegt: Man macht das, was gerade zu oberst im Backlog ist.
Wir sind viel zu agil!
Aussagen wie diese hört man gerne vom Management oder von ehemaligen Projektleiter:innen, welche sich seit der Transformation neu «Product Owner» nennen. Gerade aus traditionalistischen Gilden wird gerne versucht, einen agilen Prozess zum iterativen Wasserfall umzubiegen. Das Epic schafft Abhilfe und weicht die Fronten auf. Es ist ein Vorhaben das mehrere Stories und optional auch Bugs zu einem grösseren Themenblock zusammenfasst. Klassischerweise wird das Epic im Ticketsystem verfasst und verlinkt. Es hat eine:n Owner, eine User-zentrierte Beschreibung und eine geschätzte Grösse.
T-Shirt Sizes
Bei der Schätzung vom Epics gibt es – wie generell bei Aufwandschätzungen – verschiedene Fraktionen. Ich persönlich favorisiere die «T-Shirt Grössen» Skala. Geschätzt wird dabei die Grösse (und nicht wie bei Storypoints die Komplexität) des Epics auf einer Skala von XXS bis XXL. Es empfiehlt sich, bei der Einführung von XS bis XL zu skalieren. So kann die Skala bei Bedarf erweitert werden. Ist ein Epic kleiner als «XS» sollte überprüft werden, ob dieses überhaupt Epic-Charakter hat oder «nur» eine grosse User-Story ist. Epics die grösser als die Obergrenze der Skala sind, sollten in Teil-Epics aufgesplittet werden.
Weniger ist Mehr
Da das Ticketsystem oft als Hürde gesehen wird und sich Epics in Papierform einfacher auf eine Prioritäts-Skala oder Roadmap legen lassen, arbeiten wir bei uns mit A4 Papierbögen. Dabei wird das Epic nach folgendem Schema aufgezeichnet:
Links oben ist das Kürzel des Owners, links Unten die dazu gehörige Ticket-Nummer und rechts unten die Schätzung des Teams. Die Farbe des Papiers zeigt zudem an, zu welchem Strategischen Ziel (IT-Strategie, oder in unserem Fall OKR) das Epic gehört. Das Zentrale Element ist der Titel, welcher für alle verständlich und gut lesbar sein muss.
Inspect & Adapt
Das Epic-Planning Meeting alle 3 Monate dient der Schärfung, Priorisierung und Planung der Epics. Bei uns bringen die Stakeholder:innen bzw. Epic-Owner ihre Epics mit ins Meeting und «pitchen» diese vor dem Team, den anderen Stakeholder:innen und dem Management. Ist ein Epic unverständlich, unklar, technisch nicht umsetzbar, oder fehlt das strategische Alignment ist hier Schluss. Alle Teilnehmer:innen (inkl. Dev-Team) können Epics begründet ablehnen. Der Epic muss dann vom Owner verbessert und im nächsten Epic Planning wieder vorgestellt werden.
Epics die nicht abgelehnt werden, gelten grundsätzlich als «approved» und dürfen anschliessend nicht mehr verändert werden. Im zweiten Teil des Meetings werden die Epics vom Entwicklungsteam in T-Shirt Sizes geschätzt. Anschliessend werden gemeinsam die Abhängigkeiten und Prioritäten der Epics festgelegt. Ein weiteres mögliches Asset des Epic-Plannings ist eine grobe Roadmap. So weit sind wir in unserer Agilen Transformation aber noch nicht.
