Letzten Monat erklärte uns Felix, Agile Master der Valiton, die Rollen von Scrum und den Start des GROW Projektes. Damit wir es uns besser vorstellen können, hat Felix diese Bestandteile anhand eines realen Projektes beschrieben: GROW – 360 Grad-Datenbank.
Heute erklärt er uns, wie eine Vision zustande kommt und wie diese Hilft, Product Backlog Items zu definieren.
Los geht´s
Die Erstellung der Vision eines Projektes hilft ungemein, das Ziel des Projektes zu skizzieren und im Weiteren alle weiteren Steps zu priorisieren. Die Vision soll die Zielgruppe, das Bedürfnis, welches mithilfe des Projektes befriedigt wird, und die Rahmenbedingungen des Projektes beschreiben. Die Vision wird vom Product Owner, in Zusammenarbeit mit Kunden oder Stakeholdern, erstellt. Im Falle von GROW – 360 Grad-Datenbank ist die Vision, alle Kunden der Verlage besser zu kennen, um ihnen anhand ihrer Bedürfnisse passgenaue Inhalte zu liefern und ihren Interessen entsprechende Angebote zu unterbreiten.
Auf Basis der Vision erstellt der Product Owner und alle weiteren Stakeholder sogenannte Product Backlog Items, zum Beispiel in Form von User Stories. Diese User Stories formulieren einen fachlichen Wunsch des Anwenders bzw. beschreiben eine Funktionalität aus Sicht eines Akteurs. Hierbei folgt eine User Story dem Muster „Als AKTEUR möchte ich FUNKTIONALITÄT um BEGRÜNDUNG“. Mithilfe von Akzeptanzkriterien (fachliche und technische Abgrenzungen) wird diese fachliche Beschreibung konkretisiert und es werden „Leitplanken“ für die Entwicklung vorgegeben. Ein Beispiel für eine User Story der GROW – 360 Grad-Datenbank ist, das Versenden von individuellen Horoskopen an den Kunden auf Basis seines angegebenen Geburtsdatums:
User Story und Akzeptanzkriterien Horoskop
In Summe, bilden all diese User Stories das Product Backlog. Das Product Backlog wird in JIRA verwaltet und ist für alle Beteiligten zugänglich und transparent.
Der Product Owner priorisiert in Zusammenarbeit mit den Stakeholdern die verschiedenen Items. Die am höchsten priorisierten Items sind Bestandteil des nächsten Sprints und werden im Sprint Planning in das Sprint Backlog überführt und vom Development Team umgesetzt.