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
- Scrum Guide auf scrum.org
Comments:
|
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. 
Posted by bbucksch at 27. Mär 2012 11:15
|
|
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.
Posted by rainwebs at 27. Mär 2012 11:53
|
|
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?
Posted by aheilwagen at 27. Mär 2012 12:06
|
|
Guter Punkt & angepasst.
Posted by aheilwagen at 27. Mär 2012 12:25
|
|
Moin 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
Posted by jgersdorff at 27. Mär 2012 12:41
|
|
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.
Posted by aheilwagen at 27. Mär 2012 13:04
|
|
Meine Formulierung war etwas zu schnell getippt
Posted by rainwebs at 27. Mär 2012 18:07
|
|
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 ,-)
Posted by aheilwagen at 27. Mär 2012 18:18
|
|
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.
Posted by rainwebs at 27. Mär 2012 18:57
|
. 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.