Remote Sprint Planning: Ein digitales Backlog ohne JIRA bauen

Eine der scheinbar großen Paradoxien in der agilen Welt ist, dass wir Agilisten total auf Post-its und Flipcharts stehen, während wir uns als Speerspitze der Digitalisierung sehen. Mit Post-its und einfachen Visualisierungen waren wir ja auch immer schneller und konnten rasch und interaktiv handeln. Das hat sich im März 2020 drastisch geändert.Das Sprint Planning ist remote genauso einfach durchzuführen wie in einem Raum. Die Grundzüge sind die gleichen. Der Product Owner bringt ein priorisiertes Backlog mit, die Rahmenbedingungen werden transparent gemacht, ein Item nach dem anderen wird besprochen:

• Kommt der Nutzen für den User gut rüber?
• Ist die Beschreibung klar?
• Welche Testcases bauen wir?
• Passen die Akzeptanzkriterien, so wie sie formuliert sind, für das Team?

Der ScrumMaster fragt nach jedem Item (User Story), ob das Team dieses eine noch liefern kann. Sobald Uneinigkeit über den Scope im Team besteht, werden der Product Owner und die Stakeholder gebeten, den – in diesem Fall – virtuellen Raum zu verlassen, das Development Team bespricht sich und am Ende steht die alles entscheidende Frage: Wollen wir den Scope, so wie er ist, schaffen? Dieses Resultat wird anschließend dem Product Owner und der Organisation mitgeteilt.Was nun,

• wenn das Team bisher mit einem haptischen Board gearbeitet hat,
• JIRA als Industriestandard nicht zur Verfügung steht
• oder die Lizenzen erschöpft sind und die Organisation/der Konzern in der digitalen Steinzeit verhaftet ist und zum Beispiel noch immer Office 2013 nutzt?

Ein PowerPoint-Backlog anlegen

Das einfachste Backlog ist in diesem Fall eine PowerPoint-Präsentation, die auf dem Sharepoint liegt.

• Jede Folie ist eine User Story und kann exakt so aufgebaut sein, wie ein Post-it an einer Wand.
• Durch das Einfügen von Abschnitten findet eine Trennung zwischen Sprint-Scope und Backlog statt und die Reihenfolge der Folien spiegelt die Priorisierung wider.
• Um die Übersichtlichkeit zu bewahren, sollte das Backlog nicht größer als die dreifache Velocity in Items sein. Das bedeutet in klaren Worten: Erledigt das Team durchschnittlich acht Items, dann sind 24 Items für das Backlog ausreichend. Alles darüber hinaus kann in einer Liste in der letzten Folie dokumentiert werden. Das entspricht auch dem Eisbergmodell, wonach nur die Items für die circa nächsten drei Sprints ausformuliert werden, um keinen administrativen „Waste“ zu erzeugen.Ein besonderes Augenmerk liegt auf der Definition of Ready (DoR), damit nur Items ins Sprint Planning und in den Sprint gelangen, die eine gewisse Qualität aufweisen: old in, gold out! Die DoR ist im normalen Arbeiten wichtig, in der Remote Collaboration ist sie essentiell.

Tipp: In Kürze werden wir das Training „Remote Collaboration for Agile Teams“ anbieten, um den Change zur langfristigen Remote-Arbeit so einfach wie möglich zu gestalten. Wenn du informiert werden möchtest, sobald wir mit den Vorbereitungen dafür fertig sind, trage dich gleich jetzt in die Liste ein!Foto: Pixabay License, picjumbo_com