In einem früheren Blogbeitrag habe ich die Definition von READY vorgestellt und ich wollte einen weiteren "Kontext"-Blogbeitrag schreiben, bevor ich mit diesem anfange: über den Unterschied zwischen fließendem Arbeiten ("Kanban") und Iteration. Ich hatte jedoch viel mehr zu diesem Thema zu sagen, als ich erwartet hatte, und so wurde die Sache immer umfangreicher... Ich werde meine Gedanken zusammentragen und diesen Beitrag später veröffentlichen. Für den Zweck dieses Blogbeitrags haben Sie also einfach nur Geduld mit mir: Ich finde, dass die Arbeit eines Product Owners am besten in einem fließenden Stil erledigt werden kann. Und da mein lieber Ex-Kollege Lars Vonk mir gesagt hat, dass er auf diesen Beitrag gewartet hat, erkläre ich Ihnen hier einfach das Wie. Lars, bitteschön... :-) Update: Der dritte Teil der Serie ist ebenfalls fertig. Siehe hier. Nicht alle Backlog-Artikel sind gleich. Ein Backlog-Item beginnt als grobe Skizze - in der Regel nur die Als... Ich will... So That... - und muss so weit ausgearbeitet werden, dass das Team es in einem Sprint aufgreifen kann. Genauso wie ein Team einen grundlegenden Arbeitsablauf hat, um Dinge zu erledigen, gilt dies auch für die Rolle des Product Owner. Scrum bietet keine spezielle Unterstützung für einen Product Owner: Das Product Backlog "entsteht" einfach so. In diesem Beitrag werde ich versuchen, diese Lücke in Bezug auf den Prozess, den ein Product Owner befolgen kann, zu schließen. Ich werde eine Partitionierung des Backlogs erklären, die auf einen Ablauf abgebildet wird, die Art dieser Partitionen und wie Sie sie durchlaufen, um genügend Material für das Team bereitzustellen, damit es im nächsten Sprint weiterarbeiten kann.
Fluss zu BEREIT
Der allgemeine Arbeitsfluss in einem Scrum-Team besteht darin, dass der Product Owner neue Dinge aufnimmt, sie BEREITSTELLT und das Team sie aufnimmt, um sie zu FERTIG zu machen. Beachten Sie, dass ich hier ausdrücklich das Wort "Rolle" verwende: Die Teammitglieder haben die Aufgabe, den Product Owner dabei zu unterstützen, Backlog-Elemente auf BEREIT zu bringen.
Aufteilung des Rückstandes
Ein Rückstand kann grob in vier Bereiche unterteilt werden, basierend auf dem Gesamtfluss:
- Artikel, die sich derzeit im Sprint befinden,
- Artikel, die bereit sind,
- Artikel, die Sie für die Bereitschaft vorbereiten, und
- der Rest: neue Sachen.
Natürlich ist dies eine idealisierte Sicht der Dinge. In der Praxis sind die Grenzen etwas unscharf, da die Zuordnung der Prioritäten zu den Workflow-Schritten nicht immer so sauber ist, wie Sie es gerne hätten. Neue Artikel können eine sehr hohe Priorität haben, so dass sie zwischen den READY-Artikeln liegen. Andererseits könnte diese Art der Betrachtung des Backlogs dazu dienen, die Priorisierung durchzusetzen: Etwas, das BEREIT ist, könnte per Definition höher priorisiert werden als etwas, das es nicht ist.
Von der Partitionierung zum Fluss
Wenn wir diese Schritte nebeneinander stellen, ergibt sich folgendes Bild:
Die Tatsache, dass ich eine Farbe für "Neu" und "Bereit" und eine andere für "In Vorbereitung" und "Im Sprint" verwendet habe, ist kein Zufall: "Neu" und "Fertig" sind priorisierte Puffer, "In Vorbereitung" und "Im Sprint" sind laufende Arbeiten. Lassen Sie uns den Ablauf Schritt für Schritt durchgehen.
Vorrangiger Puffer: Neu
Backlog-Einträge im Status Neu sind diejenigen, an denen Sie noch nicht gearbeitet haben, zumindest nicht in dem Maße, dass Sie sie auf BEREIT bringen. Dennoch habe ich in der Praxis festgestellt, dass es ratsam ist, bei diesen Punkten eine minimale Triage vorzunehmen: Wenn Sie jede verrückte Idee dort ablegen, werden Sie schnell von einer Lawine von Punkten überschwemmt. Stakeholder neigen dazu zu sagen: "Ich habe tausend Ideen!", aber viele davon sind genau das: Ideen. Nur ein kleiner Teil davon ist tatsächlich realistisch oder sinnvoll umsetzbar. Diese anfängliche Triage sollte einfach gehalten werden, aber sie erfordert ein gewisses Maß an Disziplin, wenn die Interessengruppen ihre Anforderungen einbringen. Seien Sie nicht zu besorgt, wenn sich die Beteiligten beschweren, denn im Allgemeinen wissen die Beteiligten zu schätzen, wenn sie wissen, was sie tun müssen, um ihre Anforderungen einzureichen :-). Um als Neu in das Backlog aufgenommen zu werden, sollte ein Stakeholder folgende Angaben machen:
- eine Geschichte, die sich ausschließlich auf die Geschäftserfahrungen bezieht, die beschreibt, was sie erleben und was sie brauchen , ohne darauf einzugehen, wie das Produkt dies unterstützen würde
- Strophe der Benutzergeschichte (Als... Ich will... So dass...)
- eine (grobe) Bewertung des Nutzens
- eine ungefähre Angabe zur Größe (d.h. zu den Kosten): klein, mittel, groß. (Beachten Sie, dass dies am besten von einem Teammitglied oder dem Product Owner nach einem Gespräch mit dem Stakeholder geschätzt wird: Sie kennen das Produkt besser)
Die geschäftliche Dringlichkeit gibt Ihnen eine grobe Priorisierung, anhand derer Sie entscheiden können, welche Artikel Sie zuerst einholen sollten.
Unfertige Arbeit: Vorbereiten von
Dieser Schritt ist für den Product Owner der wichtigste: Hier wird die Kernarbeit des Product Owner erledigt. Der Product Owner ist der einzige Ansprechpartner für alle Interessengruppen, und das ist natürlich beabsichtigt. Es muss eine zentrale Anlaufstelle für alle Anforderungen und die Festlegung von Prioritäten geben, sonst fällt alles auf das Team zurück und die Rolle des Product Owner ist so gut wie nutzlos. Ein unglücklicher Nebeneffekt für unseren armen Product Owner ist, dass er ständig mit Anforderungen und Druck von allen Beteiligten bombardiert wird. Das Ergebnis ist, dass ein Product Owner überfordert ist, wenn er versucht, mit all dem fertig zu werden. Ich habe die Erfahrung gemacht, dass hier der Flow/Kanban-Stil seine Stärken ausspielt: Die explizite Begrenzung der laufenden Arbeit ist eines der besten Werkzeuge, um etwas Vernunft in das Leben des Product Owners zu bringen. Der Product Owner zieht Elemente je nach Kapazität in den Vorbereitungsschritt. Genauso wie ein Team Arbeit nach Kapazität einzieht und sie nicht ändert, bis der Sprint vorbei ist, sollte ein Product Owner eine bestimmte Anzahl von Objekten einziehen (ich habe oft zwei pro Person in der Product Owner-Rolle gesehen, weiß aber nicht, ob das allgemein üblich ist), an ihnen arbeiten, bis sie fertig sind, und nur dann neue Objekte einziehen, wenn im Vorbereitungsschritt ein "freier Platz" frei wird. Der Product Owner muss nicht alle Informationen zur Verfügung stellen (und kann dies in den meisten Fällen auch nicht), aber er ist dafür verantwortlich, dass jemand dies tut, damit der Backlog-Eintrag fertiggestellt werden kann. Das bedeutet, dass der Product Owner mit den Stakeholdern spricht, um sie um weitere Informationen zu bitten, mit dem Team, um eine Schätzung der Implementierungskomplexität abzugeben, und mit allen anderen, die für Klarheit und Informationen sorgen müssen. Das ist eine ganze Menge Arbeit, und in größeren Organisationen ist es nicht ungewöhnlich, dass mehrere Personen (oft Analphabeten) diese Rolle übernehmen. Durch den expliziten Schritt im Flow ist es nun möglich, die Leistung des Product Owners zu messen. Das Äquivalent zur Geschwindigkeit im Flow-Stil ist die Zykluszeit: die durchschnittliche Zeit, die benötigt wird, um ein Backlog-Element von Neu auf Fertig zu bringen. Ein festgefahrenes Backlog-Element ist leichter zu erkennen, da es länger als üblich in der Vorbereitungsphase verbleibt. Es hilft auch bei der Planung der Kapazitäten der Product Owner. Wenn Sie die Zykluszeit mit der Anzahl der Backlog-Elemente vergleichen, die das Team pro Sprint benötigt, können Sie feststellen, ob der Product Owner schnell genug ist, um Schritt zu halten. Die Geschwindigkeit eines Product Owner wird nicht an den Story Points eines Backlog-Elements gemessen, sondern an der Anzahl der Backlog-Elemente, denn der Arbeitsaufwand für jedes Element ist in etwa derselbe: Jedes Element muss unabhängig von seiner Größe beantwortet werden. Große Backlog-Einträge bedeuten zwar mehr Arbeit, aber in den meisten Fällen müssen sie in Größen aufgeteilt werden, die für das Team handhabbar sind. Das bedeutet, dass für (ursprünglich) große Aufgaben mehr Backlog-Einträge zur Verfügung stehen, so dass große Aufgaben auf diese Weise berücksichtigt werden. Wenn ein Backlog-Eintrag bereit ist, kann er in den Bereitschaftspuffer verschoben werden.
Prioritärer Puffer: Der Bereitschaftspuffer
Ich habe es als sehr nützlich empfunden, die Liste der Ready Items als einen Puffer zu betrachten. Die Produktivität des Product Owners muss so sein, dass dieser Puffer voll genug ist, wenn der nächste Sprint beginnt. Die Verfolgung der Größe des Puffers (in Story Points, da jetzt die Kapazität des Teams relevant ist) ist eine sehr gute Möglichkeit, um zu sehen, ob der Product Owner in Schwierigkeiten gerät. Sie könnten ein Burn-Down-Diagramm, ein Burn-Up-Diagramm oder einfach
Unfertige Arbeit: Im Sprint
Dieser Schritt ist natürlich relativ einfach zu beschreiben, denn hier kommt der übliche Scrum-Kram ins Spiel :-). Als Product Owner verfolgen Sie, welche Elemente sich im Sprint befinden, aber Ihre Arbeit ist noch nicht ganz getan. In Anlehnung an ein Zitat über Design: "Ein gutes Design hängt nicht von einer einzigen großen Entscheidung ab, sondern von Hunderten von kleinen", braucht ein Team Sie, um es mit Entscheidungen zu beglücken. Während eines Sprints wird ein Team Alternativen für Details der Implementierung vorschlagen. Oft wirken sich diese Alternativen auf das Endergebnis aus: Sie haben vielleicht eine einfache Option, die aber nicht genau dem entspricht, was verlangt wurde, oder ein Team stellt fest, dass ein Teil der Implementierung schwieriger zu bewerkstelligen ist als erwartet. In diesem Fall müssen Sie in der Nähe sein, um dem Team weiterzuhelfen.
Zusammenfassung
Das Backlog kann in vier Teile unterteilt werden, die Sie mit einem Fluss verbinden können. Da dieser Blogbeitrag schon lang genug ist, werde ich einen weiteren schreiben, wie Sie diesen Prozess mit einer Kanban-Tafel und elektronischen Tools unterstützen. Update: Ich habe den dritten Beitrag der Serie geschrieben: Sie finden ihn hier
Verfasst von
Serge Beaumont
Unsere Ideen
Weitere Blogs
Contact