Wie wird geschätzt, wenn alle remote vor ihrem Notebook sitzen?

Über den Sinn und Unsinn des Schätzens im agilen Arbeiten bzw. überhaupt lässt sich vortrefflich streiten. Dies soll aber nicht Teil dieses Blogs sein. Ich setze einmal voraus, dass ihr wisst, worum es beim Schätzen geht und jetzt vielleicht überlegt, wie ihr es remote umsetzen könnt. Auch beim Remote-Schätzen ist die Voraussetzung ein priorisiertes Backlog mit User Stories, die die Definition of Done erfüllen (wenn ihr keine habt, findet ihr hier einen Hinweis zur DoD).Ihr habt zwei Möglichkeiten:

Schätzen mit Timer

  • Wenn ihr über Skype, Teams, Slack oder Ähnliches verfügt, sollte euch der Product Owner die User Stories aus seinem Backlog (MS Planner, JIRA etc.) vorstellen.
  • Ihr könnt gemäß der unreinen Fibonacci-Reihe (1,2,3,5,8,13,20,40,100) eure Schätzung gleichzeitig im Chat abgeben. Stellt hierzu einen Timer auf 10 Sekunden. In dieser Zeit könnt ihr eure Schätzung eintragen.
  • Sobald der Timer abgelaufen ist und das Signal ertönt, drückt ihr gleichzeitig auf Enter. So habt ihr einerseits die Schätzung dokumentiert, seht aber auch schwarz auf weiß, wenn es unterschiedliche Werte gibt.

Magic Estimation Remote

Wenn ihr Magic Estimation einsetzen wollt, ist auch das remote möglich – allerdings ist es etwas aufwendiger.

  • Zunächst bereitet ihr eine PowerPoint vor, in der ihr die Werte der unreinen Fibonacci-Reihe eintragt (1, 2, 3, 5, 8, 13, 20, 40, 100). Diese fungieren später als Trennfolie zwischen den einzelnen User Stories. Entweder habt ihr diese schon als PowerPoint abgespeichert, oder ihr müsst diese aus JIRA (bzw. dem Tool, das ihr benutzt) in eine PowerPoint kopieren. Wichtig: pro User Story eine Folie.
  • Nachdem sich euer Team in diese PowerPoint-Datei eingeloggt hat (Voraussetzung: Ihr könnt parallel darauf zugreifen), verteilt ihr wie beim analogen Magic Estimation die User Stories gleichmäßig an die Teammitglieder.
  • Nun legt ihr eine Referenz-User-Story fest und dann geht es in die erste Runde.
  • Die Teammitglieder verteilen (ohne Kommunikation) ihre User Story zwischen den Trenn-Slides.
  • In der zweiten Runde verschieben die Teammitglieder die User Stories, die sie anders einschätzen und versehen dabei das Slide mit ihrem Kürzel, um diese zu markieren.
  • Im Anschluss wird über alle Slides, also User Stories, die gewandert sind, nochmal diskutiert.
  • Ist auch diese Runde abgeschlossen, habt ihr ein geschätztes Backlog, das vom Product Owner wiederum in die priorisierte Reihenfolge gebracht wird. (Randnotiz: In diesem Zusammenhang bietet es sich an, das Backlog in Powerpoint zu pflegen, um den copy&paste-Aufwand möglichst gering zu halten).

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!

Agile Toolbox
Scrum
Product Owner
Neues Arbeiten
Remote Arbeiten
Schätzen
Scrum Artefacts
Scrum Meetings
Moritz Müller
March 25, 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