Was tun mit Langläufern oder zurückgestellten Aufgaben bei Scrum?

Stories oder Aufgaben, die bekanntermaßen nicht im aktuellen Sprint abgeschlossen werden können, sollten nicht ins Sprint Backlog aufgenommen werden. Das ist oft z.B. bei teamexternen Abhängigkeiten der Fall.

Aber wohin gehören sie denn dann?

Entweder teilt man so ein Issue in kleinere Teile auf, die innerhalb eines Sprint umgesetzt werden können, oder markiert es im Backlog als WARTEND.

Für den zweiten Fall kann man im Backlog eine Trennlinie eingetragen. Z.B. „— WAITING ON SOMETHING above this line —„.

Niedrig priorisierte Bugs oder Aufgaben, die prinzipiell startklar sind, und nur noch auf Zeit bzw. Priorisierung warten, gehören ans untere Ende des Backlogabschnittes, welcher fertig für den Sprint ist. D.h. direkt über eine Trennlinie „— READY FOR SPRINT above this line —„.

Was tun, damit solche Einträge nicht in Vergessenheit geraten?

  • Issues die an bestimmte Termine gebunden sind, sollte man in einen elektronischen Kalender eintragen. Dann bekommt man eine aktive Erinnerung.
  • Alternativ bzw. zusätzlich kann man ein Board errichten, auf dem solche Langläufer auf Wiedervorlage gelegt werden können. Das Board hat einen Bereich für jeden künftigen Sprint, auf dem diese Aufgaben geheftet werden. Zu Beginn des Sprints wird geprüft, ob die Aufgabe ins Sprintbacklog übertragen werden kann.
  • Am Besten gegen das Vergessen ist jedoch eine erste Teilaufgabe zu definieren, die innerhalb eines Sprints abgeschlossen werden kann. Das ist dann die Erinnerung an die Folgeaufgabe.

Verwandte Artikel:

WM 2014 Spielaufstellung für Estimation Workshops

Manchmal scheinen selbst Entwickler zu viel zu reden. Grade in frühzeitigen Estimation- (bzw. Grooming- oder Product Backlog Refinement) Workshops verliert man leicht den Fokus und diskutiert zu früh über fachliche und technische Feinheiten.

Mit dieser Spielaufstellung hat das Team eine spielerische Hilfe sich auf die wichtigsten Dinge zu konzentrieren.

Jeder Spieler auf dem Feld steht für einen wichtigen Aspekt bei einer User Story.

  • Titel ist eindeutig.
  • Wer, was, warum sind beschrieben.
  • Story wurde vorab von einem Entwickler gereviewed.
  • Fachlichkeit ist nachvollziehbar.
  • Akzeptanzkriterien sind eindeutig.
  • Abschätzbar.
  • Fachliche Voraussetzungen sind aufgelistet.
  • Technische Voraussetzungen sind aufgelistet.
  • Umsetzung ist in einem Sprint möglich.

Darüber hinaus kann man sich noch weitere Spielregeln ausdenken. Ersatzspieler, z.B. für die typischen INVEST Kriterien oder zu speziellen Team Herausforderungen. Oder Punktregelungen.

Diese Präsentation mit der Spielaufstellung kann gerne weiterverwendet werden. Enjoy!

Titel ist eindeutig.
Wer, was, warum sind beschrieben.
Story wurde vorab von einem Entwickler gereviewed.
Fachlichkeit ist nachvollziehbar.
Akzeptanzkriterien sind eindeutig.
Abschätzbar.
Fachliche Voraussetzungen sind aufgelistet.
Technische Voraussetzungen sind aufgelistet.
Umsetzung ist in einem Sprint möglich.

Verwandte Artikel:

Wie schätzt man nichtfunktionale Stories in Storypoints / Funktionspunkten ab?

Teams, die User Stories üblicherweise in Storypoints abschätzen die auf Funktionalität statt auf Aufwand beruhen, kommen bei der Abschätzung von Stories ins Strudeln, die keinen funktionalen Charakter haben.

Das könnten z.B. längere Analysestories sein, oder das Austauschen eines Quellsystems gegen ein anderes.

Zu überlegen ist dabei, ob diese Stories denn überhaupt Punkte bekommen sollten. Oder ob Analysetätigkeiten einfach die Velocity senken. Wenn über die Velocity der fachliche Fortschritt gemessen werden soll, erscheint das passender. Wenn es Gründe für eine Abschätzung gibt, kann man die Frage stellen: Um welchen Wert würde die Velocity im Sprint absinken?

Bei technisch motivierten Stories, wie z.B. der Austausch eines Quellsystems gegen ein anderes, kann man die Funktionsänderung an der Schnittstelle abschätzen. In dem Fall ist es nicht die Funktion, die der User sieht, sondern der Entwickler bzw. das eigene System. Vielleicht lässt sich auch feststellen, welche Funktionen für den User gleich bleiben müssen und das sind dann die abzuschätzenden Funktionen. Das mag auf den ersten Blick zu viel erscheinen, andererseits müssen diese Funktionen getestet werden und je nach Änderung des Quellsystems müssen auch einige Businessobjekte oder gar Abläufe geändert werden. Das Risiko des Unbekannten ist mit einer höheren Abschätzung besser abgedeckt, als mit einer geringen.

Verwandte Artikel:

Zwei User Story Beispiele

Ein einfaches Beispiel

Überschrift: Anwendung starten

Story: Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um Zeit zu sparen.

(Quelle: Wikipedia)

Ein ausführlicheres Beispiel

Überschrift: Datenschutzerklärung System Sales Assistant

Story: Jeder Anwender der Anwendung muss vor der Verwendung personenbezogener Daten bestätigen, dass er die Datenschutzerklärung beachtet, um den rechtlichen Anforderungen des Datenschutzgesetz §4711 zu genügen.

Akzeptanzkriterien:

  • Bei jeder Anmeldung am System wird eine Textinformation angezeigt, die bestätig werden muss. Maximal jedoch einmal je Benutzer und Quartal.
  • Wenn der Anwender die Information nicht bestätigt, beendet sich die Anwendung.
  • Die Textinformation muss durch eine Person in der Rolle „Betrieblicher Datenschutzbeauftragter“ ohne neue Distribution der Anwendung redaktionell gepflegt werden können.

Folgendes ist nicht angefordert:

  • Die Textinformation muss nicht archiviert werden.
  • Die Bestätigungen müssen nicht gespeichert oder weitergemeldet werden.

Bemerkungen zu den Beispielen

  • Die Überschrift erleichtert das optische Auffinden in einem Stapel von User Stories. Unabhängig davon, ob sie an der Wand hängen, oder in einem elektronischen System wie z.B. Jira.
  • Das einfache Beispiel funktioniert gut für Teams, die schon lange zusammen an den Produkt arbeiten und großes Domainenwissen haben. Ein neu gegründetes Team benötigt i.d.R. mehr Spezifikationen.
  • Der Detailgrad einer User Story wächst mit der Zeit. Zur Releaseplanung und Priorisierung gibt es nur einfache Stories Sätze / Epics / Features, aber dafür decken diese möglichst vollständig den Release Umfang ab.
  • Nach erster Priorisierung werden die Stories für die kommenden 2-3 Sprints in Product Backlog Refinement Workshops detailliert, so dass zum Sprint Planning I schon einige der Punkte vorhanden sind:
  • Überschrift
  • User Story
  • Akzeptanzkriterien
  • Abschätzung in Story Points
  • Ermittlung und Klärung technischer sowie organisatorischer Abhängigkeiten

Bei Bedarf noch

  • Nicht-Anforderungen
  • Funtionale Ablaufdiagramme
  • UX-Design / Kreativ Konzept / Wire Frames
  • Vermaßtes UI-Design
  • Testfälle

Das hilft dem Team dabei, die Story auch wirklich in einem Sprint umsetzen zu können.

Verwandte Artikel:

Coaching durch Inception

Wer kennt es nicht – Kollegen, Chef’s oder Kunden die einfach nicht den Ratschlägen folgen wollen? Alle Lösungsvorschläge finden scheinbar kein Gehör. Mit dem Inception Konzept wird es zum leichten Spiel.

Wer den Film Inception gesehen hat, bekommt eine Ahnung wie es funktioniert. Anders als im Film können wir uns jedoch nicht in den Traum unserer Zielperson einhacken. Wir können sie jedoch träumen lassen.

Statt sich auf die Probleme zu konzentrieren geht es darum ein Bild zu erzeugen, wie schön alles sein könnte: Die richtigen Menschen sprechen miteinander … über die richtigen Sachen … zum richtigen Zeitpunkt … Wäre es nicht prima, wenn es zum Releasetag keine Bugs mehr gäbe … Versuchen wir unseren Gegenüber dazu zu ermuntern, zu träumen.

Nun muss dieses Gefühl nur noch sacken. Nach einiger Zeit hat das Unterbewusstsein die damals vorgeschlagenen Lösungen mit der wunderbaren Vision verknüpft oder gar bessere gefunden. An dieser Stelle holen wir unseren Liebling wieder ab und helfen ihm bei der Umsetzung seiner Ideen.

Verwandte Artikel: