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

Das Product Backlog Board

Diese Woche habe ich mit meinem Team einmal über das Product Backlog Board nach Empfehlung von Roman Pichler gesprochen. Das Product Backlog Board ist eine Visualisierung des Product Backlogs und der wichtigsten Constraints (= Nebenbedingungen/Auflagen) im Teamraum, so dass sich jederzeit jedes Teammitglied und auch die Stakeholder darüber informieren können.
Wir haben seit einiger Zeit eine Grundversion eines Backlog Boards im Büro gehabt, nach einer Schulung von Roman in München wurden mir jedoch noch einige Punkte deutlich, die ich mit dem Team abgestimmt habe.

Der Aufbau eines Backlog Boards

Den grundlegenden Aufbau eines Backlog Boards erklärt Roman in seinem Artikel „The Product Backlog Board„. Die folgende Darstellung zeigt ein reduziertes Product Backlog Board, an dem wir uns bei unserem Board orientiert haben:

product-backlog-board

Das Product Backlog Board

Die zentralen Bereiche des Product Backlog Boards sind die Story Area und die Constraint Area.

Die Story Area

In der Story Area wird der Product Backlog der aktuell in Arbeit befindlichen Version vorgehalten. Es handelt sich dabei nicht zwangsläufig um sauber ausformulierte Userstories, auch Fehlermeldungen können dort vorgehalten werden.
Von den Stories sind dort drei verschiedene Granularitäten vorzufinden: Stories, Epics und Themes.

Fein zerteilte Stories, die fertig für eine Umsetzung sind, befinden sich oben im „ready items“-Bereich. Die feine Zergliederung und Fertigstellung von Stories werden dabei auf diejenigen fokussiert, die im nächsten Sprint für eine Umsetzung vorgesehen werden.

Im unteren Teil der Story Area befinden sich Themes und Epics. Die Themes dienen der ganz groben Unterteilung des Backlogs nach Themenbereichen. Die Epics stellen eine grobe Formulierung von Features dar, die erst dann feiner formuliert und ausgearbeitet werden, wenn die Umsetzung nahe rückt.
Im Bereich der „ready items“ ist eine Priorisierung durch den Product Owner Pflicht, während im Bereich der Themes & Epics nach Roman eine Priorisierung nicht unbedingt erforderlich ist.

Die Constraint Area

In der Constraint Area werden die grundlegenden Anforderungen an das User Interface sowie operative Eigenschaften der Software festgehalten.
Das Produkt- und User Interface-Design kann in Form von Screens/Wireframes/Skribbles mit Anmerkungen zu den wichtigsten Vorgaben Vereinbarungen dargestellt werden.
Die operativen Eigenschaften können durch „Constraint Cards“ abgebildet werden, wobei pro Karte eine bestimmte operative Eigenschaft festgehalten wird. Das kann u.a. die Browser, für die optimiert werden soll, die Performance oder die Skalierbarkeit eines Softwareprodukts betreffen.
Die Constraints sollten mit der Definition of Done verknüpft werden, damit deren Einhaltung zum Bestandteil der Abnahme von jeder einzelnen Userstory wird. Das lässt sich gut am Beispiel der Browseroptimierung verdeutlichen. Wird diese in die Definition of Done aufgenommen, ist bei der Abnahme einer Story auch eine entsprechende Prüfung in den verschiedenen Browsern vorzunehmen. Ist die Erfüllung dieses Constraints nicht gegeben, gilt die Story somit nicht als „Done“.

[Anmerkung: Roman weist in seinem Beitrag über das Product Backlog Board noch eine „Model Area“ aus. Diese wurde im Rahmen der Schulung nicht behandelt und eignet sich auch für eine spätere Ergänzung.]

Regelmäßige Backlog-Pflege

Die regelmäßige Pflege des Product Backlogs und des Boards erfolgt in Form von Backlog Grooming Workshops oder Sessions. Das Team (inkl. Product Owner) nimmt dabei gemeinsam eine Aktualisierung des Backlogs vor, bespricht Stories, zerteilt sie, fügt neue hinzu und beschätzt sie. Für Teams mit 2-wöchigen Sprints schlägt Roman vor, wöchentlich 2 Stunden mit Backlog Grooming Workshops zu verbringen.
Wir hatten bisher weniger Zeit mit dem Grooming verbracht und haben die Workshops auch nicht zu einem festen Termin durchgeführt. Dies werden wir in Zukunft tun. Der Beitrag des Teams zur Erstellung und Pflege des Backlogs wird damit deutlich höher, wodurch auch sichergestellt wird, dass alle relevanten Aspekte einer Story besprochen werden.
In dem Workshop kann das Backlog Board auch direkt aktualisiert werden.

Mit diesem Setting werden wir in den nächsten Wochen erst einmal Erfahrungen sammeln. „Inspect and Adapt“. Die Reise mit Scrum bleibt spannend.

Weitere Artikel zur Product Backlog-Pflege:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

25 Blogs zu Scrum und agiler Softwareentwicklung

Welche Blogs zu Scrum und agile Softwareentwicklung solltet ihr nicht verpassen? Vor einiger Zeit habe ich meine persönlichen Top 5 Scrum-Blogs vorgestellt. Agile Office fragte in einem Kommentar, welche weiteren Blogs ich zu dem Thema lese.
Nachfolgend daher eine umfangreichere Liste von 25 Blogs zu Scrum und agiler Softwareentwicklung:

  1. „Scrum Log“ von Jeff Sutherland: Der „Vater von Scrum“ schreibt seit 2002 über alles rund um Scrum, von „Dealing with Bugs in a Sprint“ bis zu „Hackathons – How it’s done at Facebook“
  2. „Telling It Like It Is“ von Ken Schwaber: Der Mitbegründer von Scrum und Gründer von Scrum.org schreibt regelmäßig über seine Sicht auf die Entwicklungen in der Scrum Community.
  3. ScrumAlliance Articles: Hier gibt es Artikel von vielen erfahrenen Scrum Trainern und Professionals.
  4. „bor!sgloger — leading Scrum with passion“ von Boris Gloger: Einer der bekanntesten Scrum-Trainer aus Deutschland versorgt uns regelmäßig mit aktuellen Tipps und Tricks rund um agile Softwareentwicklung.
  5. „All Things Product Owner“ von Roman Pichler: Der Scrumtrainer und mehrfache Buchautor schreibt regelmäßig und überzeugt durch tolle Anregungen, wie die zu einem Product Backlog Board.
  6. „Lean und Kanban“ von Arne Roock: Der Prokurist bei it-agile und Träger eines schwarzen Gürtels in Karate schreibt einen der wenigen deutschen Blogs über Kanban in der Softwareentwicklung.
  7. „Dayley Agile“ von Alan Dayley: Ein Softwareentwickler, der seit vielen Jahren auf agile Softwareentwicklung schwört und seine Erfahrungen mit uns teilt.
  8. Implementing Scrum von Michael Vizdos: Der Scrum-Trainer berichtet von seinen Erlebnissen, Tony Clark liefert ihm herausragende Illustrationen dazu. Sehr sehenswert.
  9. „inside-scrum“ von Jean-Pierre: Ein Anwenderbericht vom Start und der Durchführung eines Scrum-Projekts.
  10. Agile Product Design: Agile Softwareentwicklung betrachtet aus dem Blickwinkel des Product Designs, eine längere Zeit schon still, aber mit sehr interessanten Artikeln.
  11. Peter Beck: Scrum-Trainer von DasScrumTeam. Zuletzt leider etwas ruhig geworden.
  12. „scrum breakfast“: Die Selbstbeschreibung drückt es am besten aus: „Blog about Scrum: getting started, crisis project management and transforming into a lean organization.“
  13. ScrumEdge: Ein weiteres Scrum-Blog, das durch eine hohe Frequenz von guten Artikeln überzeugt.
  14. „Agile Product Owner“ von Jennifer: Die Eigenbeschreibung „Sharing the Art of Agile Product Ownership“ trifft es auf den Punkt. Zuletzt ist es in dem Blog leider eher ruhig geworden.
  15. ScrumCenter: Der Corporate Blog eines agilen Beratungsunternehmens. Viele Inhalte von Präsentationen werden behandelt, aber auch auf interessante Artikel verwiesen.
  16. Scrumology von David Bland: Entgegen dem Namen geht es nicht nur um Scrum, sondern auch um Kanban und „schlanke“ Softwareentwicklung. David teilt seine Erfahrungen aus der Praxis.
  17. Stefan Roock: Der Trainer für agile Softwareentwicklung berichtet über seine Erlebnisse und Erfahrungen aus seiner Beratungstätigkeit.
  18. The Agile Executive von Israel Gat: Dieser Blog beschäftigt sich mit dem Rollout von „Agile“ auf Unternehmensebene, also über einzelne Teams hinweg.
  19. The Agilista PM von Donna Reed: Mit Fachartikeln, Webinaren und Webcasts werden hier Aspekte des agilen Projektmanagements behandelt.
  20. Scaling software agility: Wie lässt sich agile Softwareentwicklung in großen Projekten einsetzen? Hier gibt es Antworten.
  21. PM-Blog von Stefan Hagen: Obwohl sein Blog nicht ausdrücklich auf agile und schlanke Vorgehensweisen fokussiert, ist ihm dieses Faible von Stefan anzumerken.
  22. „ScrumTools – agiles Projektmanagement“: Neben einer Liste von Scrum-Tools gibt es von Zeit zu Zeit Artikel im zugehörigen Blog.
  23. agileoffice: Agile, Lean und Scrum sind die Themen, mit denen sich dieses Blog beschäftigt.
  24. „Systems Thinking, Lean and Kanban“ von David Joyce: David teilt seine langjährigen Erfahrungen als Coach und Teammember und verweist regelmäßig auf spannende Artikel.
  25. „Lean Software Engineering“ von Corey Ladas und Bernie Thompson: Die beiden teilen ihre Erfahrungen aus Teams von u.a. Microsoft und IBM. Ihre Artikel bekommen hohe Aufmerksamkeit und sorgen regelmäßig für umfangreiche Diskussionen.
Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.
Foto: Von Rafa[EU]

Produktmanagement Lesetipps: Scrum ist sexy, Product Backlog Board, Fibonacci-Folge, 10 Regeln des Unternehmertums, Fehler von MySpace, Kanban, Arbeit der VCs

Diesmal mit Erfahrungen bei ImmobilienScout nach der Einführung von Scrum, Roman Pichlers Vorschlag eines Product Backlog Boards, einem Aufruf zur Verwendung der richtigen Fibonacci-Folge, 10 Regeln des Unternehmertums vom LinkedIn-Gründer, die Fehler von MySpace, einer Einführung in Kanban und einem Einblick in die Arbeit eines Venture Capitalist.

  • Scrum ist sexy und macht erfolgreich. So sieht es Oliver Zeiler, CTO bei ImmobilienScout. Für das Magazin CIO berichtet er berichtet er von den Anfängen mit Scrum, den bereits erzielten Produktivitätssteigerungen und dem Ziel „Continuous Live Deployment“: Die Scrum-Erfahrungen bei Immobilien Scout. Ebenfalls sehenswert ist diese Präsentation zu Scrum bei ImmobilienScout: Scrum & Project Management.
  • Scrum-Trainer Roman Pichler macht einen Vorschlag, wie das Product Backlog und Bedingungen („Constraints“) besser visualisiert werden können: The Product Backlog Board
  • Scrum-Mitbegründer Ken Schwaber ruft dazu auf, dass wir bei Anwendung von Planning Poker, einer Methode zum Generieren von Aufwandsschätzungen, nur mit Pokerkarten mit der richtigen Fibonacci-Folge arbeiten. Der theoretische Physiker Stephen Hawking hatte sich an ihn gewendet, da er und sein Team immer wieder mit einer falschen Folge konfrontiert wurden, die als Fibonacci-Folge missinterpretiert wurde. Der Aufruf von Ken Schwaber
  • LinkedIn-Gründer Reid Hoffman präsentiert für VentureBeat seine 10 Regeln des Unternehmertums.
  • Robert Scoble analysiert in einem Blogpost, welche Fehlentscheidungen dafür gesorgt haben, dass MySpace der Todesspirale nicht entkommen konnte, sondern noch tiefer hineingeraten ist: MySpace’s death spiral.
  • Im Blog von //SEIBERT/MEDIA gibt es einen Artikel zu Kanban, der insbesondere für Einsteiger zu empfehlen ist: Kanban: Funktionsweise, Elemente, Anwendung.
  • Der Venture Capitalist Olaf Jacobi, Partner bei Target Partners, stand selbst schon auf der Seite der Startup-Gründer. Nun erinnert er sich zurück, dass er damals selbst immer wissen wollte, wie ein VC arbeitet. Er bietet uns nun einen spannenden Einblick: Wie arbeitet eigentlich ein VC?

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

%d Bloggern gefällt das: