Wenn ein Team anfängt nach Scrum zu arbeiten braucht es erstmal ein Product Backlog. Wie soll er gefüllt werden? Mit Aufgaben oder Anforderungen? Was ist denn eigentlich der Unterschied zwischen beiden?
2 Antworten
Den Unterschied zwischen Aufgaben und Anforderungen verstehe ich so, dass Aufgaben Aktivitäten sind, die erledigt werden müssen, um das Produkt zu entwickeln, während Anforderungen, das sind, was ein Anwender mit dem Produkt erreichen möchte.
Ich würde mit Anforderungen im Backlog beginnen, die idealerweise aus Sicht der Benutzer eines Produktes beschrieben sind. User Stories eignen sich hervorragend dies zu erreichen, da man sich dabei Gedanken machen muss, wer denn eigentlich die Benutzer oder Anwender des eigenen Produktes sind und dann beschreibt, welche Ziele diese mit dem Produkt erfüllen wollen. Man kann diese Ziele auch als Nutzen des Produktes sehen.
Aus der Bewertung der Wichtigkeit dieser Einzelnutzen ergibt sich auch gleich eine Reihenfolge des Backlogs, was bei der Abarbeitung hilft.
Weder, noch. Ein Backlog ist eine Sammlung aller notwendigen Dinge, die nötig sind, damit ein Produkt hergestellt werden kann. Wichtiger als die Form (Aufgaben, Anforderungen oder User Stories) ist die Anwendung agiler Prinzipien. Dazu fallen mir ein:
- Keine Einträge schreiben, damit sie später an ein Entwicklungsteam ÜBERGEBEN werden. Sondern kurze Einträge, die als Platzhalter für eine spätere Diskussion mit dem Entwicklungsteam dienen. Das spart Zeit bei der Erstellung der Einträge und minimiert teure bereits getätigte Aufwände, falls Einträge gestrichen werden und erhöht gleichzeitig die Chance, dass unter dem Eintrag ein gemeinsames Verständnis hergestellt werden kann. Die Dokumentation dieses gemeinsamen Verständnis kann gerne als Anhang an den Eintrag im Backlog angehängt werden. Dieses Vorgehen ist unter dem Kürzel CCC (Card-Conversation-Confirmation) bekannt geworden. Als erster wird also der Platzhalter definiert, dann erfolgt eine gemeinsame Konversation, um anschließend eine Bestätigung der gemeinsam erarbeiten Lösung zu dokumentieren.
- Die Einträge sollten immer möglichst aus der Sicht des Endanwenders geschrieben sein. Dies ermöglicht dem Entwicklungsteam ein Gespür für die tatsächlich beim Endanwender zu lösenden Probleme zu entwickeln. Außerdem verhindert es unnötige Zwischenschritte, die gemäß dem 'Stille Post'-Spiel (das wir alle aus der Kindheit kennen) oft zu Informationsverlust und damit Verfälschung des eigentlich zu lösenden Problems führen. Nicht selten mit dem Ergebnis, dass etwas Falsches entwickelt wird, das dann in der Endabnahme beim User wegen 'Themaverfehlung' abgelehnt wird.
- Einträge oben im Backlog (also hohe Prio) sind klein. Idealerweise umsetzbar innerhalb weniger Tage. Im Backlogrefinement wird GEMEINSAM überlegt, wie Einträge, die noch zu groß sind, aufgesplittet werden können in Kleinere. Der Zeitpunkt, wann dies getan wird ist flexibel, wird aber balanciert von der Leistungsfähigkeit des Entwicklungsteams (z.B. gemessen als Velocity in Story Points). Ziel ist es, weder in eine leere Backlog-Pipeline zu laufen, noch zu viele Einträge auf Halde zu produzieren. Anders ausgedrückt: Just in Time.
Wie man Vorbeantworter schon richtig bemerkt hat, eignen sich für diese Art der Einträge die sogenannten 'User Stories' sehr gut. User Stories werden in einem standardisierten Format erfasst: Als 'Anwender' möchte ich 'Funktion', damit folgendes 'Problem' gelöst wird.
In der anschließenden gemeinsamen Diskussion werden dann Zielbilder der Lösung erarbeitet, die als Akzeptanzkriterien festgehalten werden. Diese wiederum z.B. in einer standardisierten Form: GEGEBEN Vorbedingung, WENN Aktion, DANN Resultat. Im Englischen auch Given-When-That bekannt. Akzeptanzkriterien in dieser Form haben den großen Vorteil, dass sie gut über geeignete Testautomatisierungssysteme automatisch abgebildet und getestet werden können.
Aufgaben, wie z.B. Dokumentation oder Deploy-Aktivitäten haben idealerweise im Backlog nichts zu suchen, sondern sind im Sinne eines FERTIGEN Produktinkrementes Teil der Lösung eines Backlog-Eintrags. In der Praxis kommt es jedoch oft vor, dass gegeben durch äußere Rahmenbedingungen, z.B. Deployments nicht immer sofort nach Entwicklung und Test erfolgen können. In diesen Ausnahmefällen ist ein pragmatischer Ansatz, z.B. einen Backlog-Eintrag für ein Release-Deployment als extra Backlog-Eintrag vorzusehen. Dieser kann auch gleich als eine Art Wasserstandslinie dienen. Alle Backlog-Einträge, die höher priorisiert sind als der Release-Deployment-Eintrag sind nach aktuellem Kenntnisstand eingeplant für das Release, alle danach nicht. So hat man auch gleich eine Art von Release-Notes erhalten, nämlich alle Einträge, die zw. dem aktuellen und letztem Release-Deployment umgesetzt wurden. JIRA kann so etwas z.B. out of the box.
- Keine Einträge schreiben, damit sie später an ein Entwicklungsteam ÜBERGEBEN werden. Sondern kurze Einträge, die als Platzhalter für eine spätere Diskussion mit dem Entwicklungsteam dienen. Das spart Zeit bei der Erstellung der Einträge und minimiert teure bereits getätigte Aufwände, falls Einträge gestrichen werden und erhöht gleichzeitig die Chance, dass unter dem Eintrag ein gemeinsames Verständnis hergestellt werden kann. Die Dokumentation dieses gemeinsamen Verständnis kann gerne als Anhang an den Eintrag im Backlog angehängt werden. Dieses Vorgehen ist unter dem Kürzel CCC (Card-Conversation-Confirmation) bekannt geworden. Als erster wird also der Platzhalter definiert, dann erfolgt eine gemeinsame Konversation, um anschließend eine Bestätigung der gemeinsam erarbeiten Lösung zu dokumentieren.
- Die Einträge sollten immer möglichst aus der Sicht des Endanwenders geschrieben sein. Dies ermöglicht dem Entwicklungsteam ein Gespür für die tatsächlich beim Endanwender zu lösenden Probleme zu entwickeln. Außerdem verhindert es unnötige Zwischenschritte, die gemäß dem 'Stille Post'-Spiel (das wir alle aus der Kindheit kennen) oft zu Informationsverlust und damit Verfälschung des eigentlich zu lösenden Problems führen. Nicht selten mit dem Ergebnis, dass etwas Falsches entwickelt wird, das dann in der Endabnahme beim User wegen 'Themaverfehlung' abgelehnt wird.
- Einträge oben im Backlog (also hohe Prio) sind klein. Idealerweise umsetzbar innerhalb weniger Tage. Im Backlogrefinement wird GEMEINSAM überlegt, wie Einträge, die noch zu groß sind, aufgesplittet werden können in Kleinere. Der Zeitpunkt, wann dies getan wird ist flexibel, wird aber balanciert von der Leistungsfähigkeit des Entwicklungsteams (z.B. gemessen als Velocity in Story Points). Ziel ist es, weder in eine leere Backlog-Pipeline zu laufen, noch zu viele Einträge auf Halde zu produzieren. Anders ausgedrückt: Just in Time.
Wie man Vorbeantworter schon richtig bemerkt hat, eignen sich für diese Art der Einträge die sogenannten 'User Stories' sehr gut. User Stories werden in einem standardisierten Format erfasst: Als 'Anwender' möchte ich 'Funktion', damit folgendes 'Problem' gelöst wird.
In der anschließenden gemeinsamen Diskussion werden dann Zielbilder der Lösung erarbeitet, die als Akzeptanzkriterien festgehalten werden. Diese wiederum z.B. in einer standardisierten Form: GEGEBEN Vorbedingung, WENN Aktion, DANN Resultat. Im Englischen auch Given-When-That bekannt. Akzeptanzkriterien in dieser Form haben den großen Vorteil, dass sie gut über geeignete Testautomatisierungssysteme automatisch abgebildet und getestet werden können.
Aufgaben, wie z.B. Dokumentation oder Deploy-Aktivitäten haben idealerweise im Backlog nichts zu suchen, sondern sind im Sinne eines FERTIGEN Produktinkrementes Teil der Lösung eines Backlog-Eintrags. In der Praxis kommt es jedoch oft vor, dass gegeben durch äußere Rahmenbedingungen, z.B. Deployments nicht immer sofort nach Entwicklung und Test erfolgen können. In diesen Ausnahmefällen ist ein pragmatischer Ansatz, z.B. einen Backlog-Eintrag für ein Release-Deployment als extra Backlog-Eintrag vorzusehen. Dieser kann auch gleich als eine Art Wasserstandslinie dienen. Alle Backlog-Einträge, die höher priorisiert sind als der Release-Deployment-Eintrag sind nach aktuellem Kenntnisstand eingeplant für das Release, alle danach nicht. So hat man auch gleich eine Art von Release-Notes erhalten, nämlich alle Einträge, die zw. dem aktuellen und letztem Release-Deployment umgesetzt wurden. JIRA kann so etwas z.B. out of the box.