Merge pull request #65 from DARCBLUEAG/master

Manual Product Backlog

_data/navigation.yml

@@ -34,8 +34,7 @@ manual:
       - title: "Story Map"
         url: /story-map/
       - title: "Product Backlog"
-        url: /coming-soon/
-#        url: /product-backlog/
+        url: /product-backlog/
       - title: "Delivery Kanban"
         url: /coming-soon/
 #        url: /delivery-kanban/

_manual/13-product-backlog.md

@@ -3,33 +3,88 @@ title: Product Backlog
 permalink: /product-backlog/
 excerpt: “Lorem ipsum”
 toc: true
-published: false
 ---
 
-Das Product Backlog ist laut Scrum Guide „eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt.“ Das Product Backlog ist demnach keine Ideenliste. Es enthält Maßnahmen für das Produkt, die bereits bewertet wurden. Es ist nie vollständig und wird kontinuierlich mit dem Produkt weiterentwickelt. 
+## Einführung
+Die Idee des Product Backlogs ist sehr einfach: es ist eine geordnete Liste von all dem, das ein Projekt oder Produkt beinhalten soll. 
+Das Product Backlog nimmt somit eine zentrale Rolle in der Produktarbeit mit deinem Team ein. 
+Das Management des Backlogs ist eine der schwierigsten Aufgaben im agilen Arbeiten. 
 
-Das Product Backlog umfasst Einträge, sogenannte Backlog Items. Diese Einträge müssen nicht alle in der gleichen Form vorliegen: Häufig sind in Softwareprojekten Items in der Form von User Stories verfasst, aber auch Tasks oder andere Formate sind möglich.
+## Ziel
+Das Product Backlog bietet allen an der Produktentwicklung Beteiligten Transparenz darüber, welche Erweiterungen und Änderungen demnächst am Produkt vorgenommen werden sollen. 
+Es ist demnach keine Ideenliste. 
+Es enthält Maßnahmen für das Produkt, die bereits bewertet wurden. 
+Es ist nie vollständig und wird kontinuierlich mit dem Produkt weiterentwickelt. 
 
-{% include figure image_path="/assets/images/Backlogs.png" alt="Backlogs" caption="Backlog Items, die demnächst bearbeitet werden sollen, sind genauer beschrieben." %}
+## Funktionsweise
+Das Product Backlog umfasst Einträge, sogenannte Backlog Items. 
+Diese Items können User Stories, technische Aufgaben, Risiken oder Fehler sein. 
+Sie bestehen aus einer inhaltlichen Beschreibung, einer Angabe zu ihrem Wert und einer Schätzung des mit ihnen verbundenen Umsetzungsaufwands. 
+Außerdem haben alle Backlog Items eine Position relativ zu den anderen Backlog Items, durch die die Ordnung des Backlogs deutlich wird. 
+
+Im Backlog fährt man immer auf Sicht. 
+Die Items, die demnächst bearbeitet werden sollen, sind genauer beschrieben als Items, die erst später umgesetzt werden. 
+Es ist daher möglich, dass einige Backlog Items noch nicht über Angaben zu Wert, Aufwand oder näherem Inhalt versehen sind.
 
-Im Backlog fährt man immer auf Sicht. Die Items, die demnächst bearbeitet werden sollen, sind genauer beschrieben als Items, die erst später bearbeitet werden. Der kontinuierliche Vorgang, in dem das Team Backlog Items detailliertere Informationen hinzufügt, heißt im Scrum Guide Refinement (geläufig sind auch die Namen Grooming oder Pre-Planning). Ein fixes Regelmeeting wie bei den Scrum Events ist hierfür nicht vorgeschrieben. Das Team verständigt sich auf ein gemeinsames Vorgehen für die Arbeit mit dem Product Backlog. 
-
-Verantwortlich für den Inhalt des Product Backlogs, also die Auswahl der Einträge und ihre Reihenfolge, ist der Product Owner. Der Product Owner stellt auch sicher, dass das Backlog für alle relevanten Personen(-gruppen) zugänglich ist. 
+{% include figure image_path="/assets/images/13-backlogs-gerrit-beine.png" alt="Backlogs" caption="Backlog Items, die oben im Backlog stehen und somit demnächst bearbeitet werden sollen, sind genauer beschrieben." %}
 
-Pro Produkt gibt es immer nur ein Backlog. Das heißt, dass auch in skalierten Entwicklungsprojekten mit mehreren Teams diese ihre Anforderungen aus einem Backlog ziehen.
+Durch Feedback zu deinem Produkt wird sich dein Product Backlog ebenfalls weiterentwickeln. 
+Auch Markttrends und neue Technologien können dazu führen, dass du Änderungen am Backlog vornimmst.
 
-Das Product Backlog ist zwar die einzige Anforderungsquelle für das Projekt, aber kein gutes Mittel, Projekte strategisch zu planen. Hierfür sind andere Mittel, wie Roadmaps oder auch Story Maps besser geeignet
+## Einsatz
+
+###Verantwortlichkeit
+Verantwortlich für den Inhalt des Product Backlogs, also die Backlog Items und ihre Reihenfolge, bist du als Product Owner. 
+Der Product Owner stellt auch sicher, dass das Backlog für alle relevanten Personen(-gruppen) zugänglich ist. 
+Einige Aufgaben, wie Backlog Refinement (siehe unten), kannst du an andere Teammitglieder delegieren. 
+Auch in diesem Fall bleibst du als Product Owner aber verantwortlich.
+
+###Refinement
+Der kontinuierliche Vorgang, in dem das Team Backlog Items detailliertere Informationen hinzufügt, heißt in Scrum „Refinement“. 
+Das Refinement umfasst folgende Aufgaben:
+
+* Hinzufügen von Details
+* Items in eine angemessene Größe bringen, zum Beispiel so, dass das Bearbeiten und Fertigstellen innerhalb eines Sprints erfolgen kann (Tipps zum Schneiden von User Stories findest du zum Beispiel bei Mike Cohn) 
+* Vornehmen von Aufwandsschätzungen für die Items (häufig genutzt werden zum Beispiel Story Points)
+* Backlog Items in eine Reihenfolge bringen
+
+Es gibt keine festgelegte Zeit, in der ein Item das Refinement durchlaufen muss. 
+Diese Zeit hängt vom Typ, Kontext, Wichtigkeit und anderen Eigenschaften des Items ab. 
+
+Refinement ist ein kontinuierlicher Prozess, an dem der Product Owner und das Entwicklungsteam beteiligt sind. 
+Die Beteiligten verständigen sich auf ein gemeinsames Vorgehen, zum Beispiel auf ein regelmäßiges Meeting mit einer Time Box.
+
+Weitere Infos zum Thema Refinement gibt es beispielsweise von [Stephanie Ockermann](https://www.scrum.org/resources/blog/art-product-backlog-refinement).
+
+###Backlog ordnen
+Um die Items in deinem Backlog zu ordnen, musst du mehrere Faktoren berücksichtigen. 
+Du musst in der Lage sein, den Wert der Items relativ zueinander abzuschätzen. 
+Die dem Backlog vorgelagerten Tools in der Product Owner Value Chain helfen dir dabei. 
+Außerdem spielt der relative Aufwand des Items eine Rolle für die Position im Backlog. 
+Schließlich solltest du auch beachten, ob das Item dir dabei hilft, ein Risiko zu minimieren und ob es Abhängigkeiten zu anderen Items hat.
+
+###Product Backlog für mehrere Teams
+Pro Produkt gibt es immer nur ein Backlog. 
+Das heißt, dass auch in skalierten Entwicklungsprojekten mit mehreren Teams diese ihre Anforderungen aus einem Backlog ziehen.
+
+##Tools
+Für die Darstellung deines Backlogs kannst du verschiedene Tools nutzen. Du kannst es zum Beispiel mit Post-its an einer Wand transparent für alle im Team machen.
+
+Weiter verbreitet ist allerdings die Nutzung von [Jira](https://www.atlassian.com/de/software/jira).
 
 ## Fragen
 
-* …
+* Welche Informationen sind in einem Backlog Item nach dem Refinement üblicherweise enthalten?
+* Warum ist ein Product Backlog für strategische Planung eher ungeeignet?
+
 
 ## Diskussionen
 
-[Hier geht es zur den Diskussionen][1] über das *Product Backlog* auf dem oncampus.
+[Hier geht es zu den Diskussionen](https://www.oncampus.de/blocks/oc_mooc_nav/forum_view.php?showall=false&id=47546) zu *Handbuchkapiteln* auf dem oncampus.
 
 ## Links, Literatur & Quellen
 
-* …
-
-[1]:	https://www.oncampus.de/course/weiterbildung/moocs/apomooc/section-2/47433-handbuch-product-backlog "oncampus Forum zum Product Backlog"
+* [What is a Product Backlog? (scrum.org)](https://www.scrum.org/resources/what-is-a-product-backlog)
+* [Stephanie Ockermann (2018): The Art of Product Backlog Refinement](https://www.scrum.org/resources/blog/art-product-backlog-refinement)
+* [Mike Cohn (2017): Five simple but powerful ways to split User Stories (scrum.org)](https://www.mountaingoatsoftware.com/blog/five-simple-but-powerful-ways-to-split-user-stories) 
+* [Mike Cohn (2010): Story Points estimate effort not just complexity](https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity)