Agiles Vorgehen zu Hause anwenden

Taskboard at homeWer die Vorzüge eines agilen Vorgehens im Berufsleben kennen und schätzen gelernt hat, möchte mitunter auch zu Hause nicht darauf verzichten. Viele Aufgaben und zu wenig Zeit, um alle abzuarbeiten, ist für viele Agilisten nicht nur im beruflichen, sondern auch im privaten Umfeld eine Herausforderung. Also heißt es, bewusst zu entscheiden, was „ausgeliefert“ wird und was vorerst nicht umgesetzt wird.

Besonders häufig findet ein einfaches Kanban-Board Anwendung, das dabei hilft, den vollen Überblick über die anliegenden Aufgaben und den Stand der Bearbeitung zu behalten. Es wird dann von „Personal Kanban“ gesprochen. In einem priorisierten Backlog wird festgehalten, welche Arbeiten in welcher Reihenfolge anfallen. In regelmäßigen Standups wird gemeinsam besprochen, was als nächstes angegangen wird. Etwa nach dem gemeinsamen Abendessen. Ein WiP-Limit begrenzt die Anzahl der parallel bearbeiteten Items. Teilweise wird das WiP-Limit am Wochentag ausgerichtet, da z.B. am Wochenende mehr Zeit für die Erledigung privater Aufgaben zur Verfügung steht als unter der Woche.
Damit eine Aufgabe tatsächlich als abgeschlossen gilt, sollte sie entsprechend einer formulierten Definition of Done abgeschlossen sein.
Abweichend von einer solchen Einteilung des Boards in „Backlog“, „Doing“ und „Done“ wird teils auch mit einem Board, das nach den Wochentagen eingeteilt ist, gearbeitet.

Ausgangspunkt für viele Personal Kanban-Anwender ist eine Situation, in der sie durch besonders viele Aufgaben überwältigt werden. Dies kann z.B. durch eine anstehende Hochzeit, einen Hausbau, Umzug oder ähnliches bedingt sein. Genau unter solchen Umständen ist es besonders wertvoll, sich die Zeit zu nehmen, um einen vollständigen Überblick der noch ausstehenden Arbeiten zu erhalten. Ein persönliches Kanban-Board aufzusetzen und initial zu befüllen ist mit weniger als einer Stunde Zeiteinsatz locker machbar. Ausprobieren lohnt. Durch regelmäßiges Reflektieren über den Prozess können nach und nach Optimierungen vorgenommen und so ein passendes persönliches Set gefunden werden.

Vereinzelt wird auch vom Einsatz von Scrum in der Familie gelesen, hier ist allerdings bereits die Rolleneinteilung in ScrumMaster und Product Owner unter Umständen eine kleine Herausforderung. Aber warum nicht mal selbst probieren?

Erfahrungsberichte zur Agile-Anwendung im privaten Umfeld:

Foto: orcmid

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Werbeanzeigen

Was kennzeichnet ein gutes Product Backlog?

Deep WatersDas Product Backlog enthält alle Arbeiten, die für die Erstellung eines erfolgreichen Produkts erforderlich sind. Es hat einen erheblichen Einfluss auf die Team-Produktivität, ob mit einem guten oder einem schlechten Product Backlog gearbeitet wird. Daher sollte sich gerade der Product Owner auch Gedanken über die Qualität des Backlogs machen. An welchen Kriterien können sich Product Owner und Team orientieren, um die Güte ihres Backlogs einschätzen zu können?

Eine Orientierung bieten die DEEP-Eigenschaften, die ein gutes Product Backlog aufweisen sollte. DEEP ist dabei ein Kürzel für:

  • Detailed appropriately
  • Emergent
  • Estimated
  • Prioritised

Betrachten wir uns diese Eigenschaften eines guten Product Backlogs einmal genauer.

Detailed appropriately

Die Grundregel hierbei heißt: Je näher ein Backlog Item an die Umsetzung heranrückt, desto granularer sollte es sein.
Dadurch gibt es im Product Backlog verschiedene Größen von User Stories:

  • Items, die im nächsten Sprint umgesetzt werden sollen, werden in detaillierter Form vorgehalten, etwa als kleine Stories.
  • Für die darauf folgenden Sprints angedachte Idems können mittelmäßig detailliert in Form von großen User Stories vorgehalten werden.
  • Noch weiter von einer Umsetzung entfernte Odems können in Form von groben Epics festgehalten werden.
  • Es wird auch deutlich, dass ein optimaler Product Backlog keinesfalls so ausschaut, dass alle Anforderungen bis ins kleinste Detail ausformuliert sind.

Emergent

Ein Product Backlog ist nie in Stein gemeißelt. Es ist lebendig und wird ständig gemeinsam von Product Owner und Team und Unterstützung der Stakeholder weiterentwickelt. Dies erfolgt z.B. im Rahmen von Backlog Grooming-Workshops, aber z.B. auch im Rahmen des Review-Meetings wird über das Backlog und mögliche Anpassungsbedarfe gesprochen.

Estimated

Das Product Backlog sollte beschätzt sein. Für die Beschätzung gibt es zahlreiche erprobte Verfahren, wie etwa das Planning Poker oder das Estimation Game. Im Rahmen von Schätzmeetings oder Backlog Grooming-Sessions kann sichergestellt werden, dass eine Beschätzung für alle Backlog-Einträge vorliegt. Für Backlog-Einträge, die noch weiter von einer Umsetzung entfernt sind, wird eine ganz grobe Schätzung vorgenommen.

Prioritised

Die geplanten Aufgaben sollten stets priorisiert sein. Die Priorisierung des Product Backlogs wird vom Product Owner vorgenommen und sichergestellt. Dabei steht er in enger Abstimmung mit den Stakeholdern und verschafft sich einen tiefen Einblick in die Marktentwicklung.

Diese grundlegenden Eigenschaften eines guten Product Backlogs geben Orientierung, worauf Product Owner und Team achten sollten. Das Product Backlog sollte außerdem gut sichtbar und einfach zugänglich sein. Ein Product Backlog Board kann hierbei eine gute Hilfe sein.

Foto: von tassoman

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Englische Version des Artikels

%d Bloggern gefällt das: