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

Agile Toolbox
Scrum
Scrum Meetings
Neues Arbeiten
Remote Arbeiten
Matthias Rodewald
March 24, 2020

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen