Kontext

Ein Ziel soll durch ein oder mehrere Teams erreicht werden. 

Problem

Welches ist der beste Weg für die Teams, um das Ziel zu erreichen unter der Voraussetzung, dass sie zu jeder Zeit wissen was zu tun ist (Transparenz) ohne Produktivität durch Multitasking zu verlieren.

Einflüsse

zu viel/zu wenig Terminplanung

Lösung

Eine geordnete Liste von Anforderungen, die auch Product Backlog Items genannt werden.

Hinweise

  • Backlogs sind häufig nach Geschäftswert oder Wichtigkeit geordnet, Lieferzeitpunkt können ebenfalls eine Rolle spielen.
  • Ein Product Backlog bezieht sich meist auf ein einzelnes Produkt oder eine Produktlinie.
  • Jedes Team arbeit nur an einem einzigen Product Backlog und startet jeweils mit dem ersten Product Backlog Item.

Resultierender Kontext

Die Teams wissen zu jedem Zeitpunkt, welche Arbeit durchgeführt werden muss.

Quellen

Twittern

9 Comments

  1. Mir fehlt an dieser Stelle die Priorisierung des Backlogs, die überhaupt zu verschiedenen "Lieferzeitpunkten" führt. Priorisierungen können sich auch ändern, d.h. das Team muss regelmäßig mit dem Backlog arbeiten und kann ihn nicht als eine Art fixen Katalog sehen.

    1. Guter Punkt & angepasst.

  2. Die Beschränkung auf einen einzigen Product Backlog pro Team wird schwierig bei Scrum of Scrums. Vielleicht wäre es noch sinnvoll, den Product Backlog View mit reinzunehmen, der soetwas je Sprint für einzelne Teams abbildet.

    1. Bei einem Scrum of Scrums liegt der Schwerpunkt auf der Kommunikation zwischen den Teams. Letztlich treffen sich dort die teamspezifischen Backlogs. Im Moment habe ich eher den Eindruck, dass wir einem Missverständnis zum Opfer fallen. Kann man die ursprüngliche Anmerkung ggf. noch etwas umformulieren bzw. den Problempunkt verdeutlichen?

      1. Meine Formulierung war etwas zu schnell getippt (wink). Mir scheint es problematisch, wenn jedes Team seinen eigenen Product Backlog pflegt, wenn wir mit mehreren Teams unterwegs sind. Stattdessen sollte ein gemeinsamer Product Backlog für alle Teams gepflegt und priorisiert werden und daraus Product Backlog Views abgeleitet werden, die in einem Sprint je Team verwendet werden. Dieses Vorgehen hilft, daß die Teams in die gleiche Richtung schauen.

        1. An der Stelle werde ich in Kürze das Company Backlog vorstellen und damit die Frage nach der Synchronisation und Sichten auf ein Backlog beantworten ,-)

          1. Ok, dann sind wir ja nahe beieinander. Ich verwende die Namenskonvention von Mike Cohn: http://books.google.de/books?id=8IglA6i_JwAC&pg=PT520&dq=mike+cohn+product+backlog+view&hl=de&sa=X&ei=ne9xT4vQK6PY4QTSv6iWDw&ved=0CDwQ6AEwAA#v=onepage&q&f=false 

            Ich fände es gut, wenn wir nicht grundsätzlich Company Product Backlog, sondern vielleicht Project Product Backlog verwenden würden. Company ist bei größeren Kontexten vielleicht etwas zu hoch gegriffen.

  3. Moin (smile)

    Mir fehlt die Logik im Backlog. Denn ich kann erst ein Haus bauen, wenn Fundament und Keller fertig sind. Ebenso kann ich bestimmte Routinen oder Funktionen erst anfassen, wenn ich dafür eine Basis im Kern der Applikation geschaffen habe.

    Diese Abhängigkeiten sind auch im Backlog und seiner Priorisierung zu beachten. Zumeist steuert das Team es aus gesundem Menschenverstand heraus, aber auch der Product Owner sollte dies deutlich auf dem Radar haben.

    Jens

     

    1. Das Scrum Guide und die Pattern geben einen Rahmen vor, der mit gesundem Menschenverstand zu füllen ist. Die Einschätzung, dass der PO die Abhängigkeiten auf dem Radar haben sollte ist genau richtig. Teamübergreifend ermöglicht beispielsweise ein Scrum of Scrums die Synchronisation der Abhängigkeiten.

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen