Wenn agile Teams ihre Product Backlog Items organisieren und beispielsweise den kommenden Sprint planen, stehen sie vor der Aufgabe, die vorhandene Arbeit zu strukturieren. Die Unterscheidung in Vision, Epics, Stories und Tasks ist dabei eine etablierte Hilfe. Durch sie wird verdeutlicht, dass in der kund*innenzentrierten Produktentwicklung auf unterschiedlichen Ebenen gedacht und gesprochen wird.
Vision
Agile Unternehmen nutzen eine Vision, um die Vorstellung eines optimalen Produktes aus Kund*innensicht festzuhalten.
Beispielsweise: „Wir wollen praxisnahe Ausbildungen zum Thema Agilität anbieten.“
Epic
Agile Teams nutzen den Begriff Epic um größere Themenbereiche einer Vision zu beschreiben. Also ein größeres Feature, ein übergeordnetes Ziel oder ein bestimmtes Projekt.
Ein Beispiel wäre: „Wir wollen eine Online-Ausbildung anbieten.“
Story
Aufgrund ihrer Größe ziehen sich Epics meistens über mehr als einen Sprint, weshalb sie in kleinere Stücke zerlegt werden müssen – sogenannte Stories oder User Stories. Diese Stories sind alle durch das Epic miteinander verbunden, können aber auch individuell betrachtet werden. Man könnte sie auch als Unterziele bezeichnen, die schon konkrete Informationen enthalten.
Für das genannte Beispiel bedeutet dies: „Für die Interessent*innen einer Online-Ausbildung möchten wir eine Infoveranstaltung anbieten, die online stattfindet. Dort sollen die Interessent*innen Fragen stellen können und uns so kennenlernen.“
Task
Um diese Story „Infoveranstaltung“ zu realisieren, wird sie in konkrete Aufgaben unterteilt, die es zu erledigen gibt. Es geht also nicht mehr um das, was angeboten werden soll, sondern darum, wie dies umgesetzt werden kann.
Für das Beispiel „Online-Ausbildung“ (Epic), mit der Story „Infoveranstaltung“ wären folgende Tasks möglich:
„Ein Medium finden, auf dem wir die Infoveranstaltung realisieren können.“
„Einen Termin für die Infoveranstaltung festlegen und veröffentlichen.“
„Einen Testlauf für die Infoveranstaltung durchführen.“
Geschichten erzählen und Kund*innen verstehen
Um als Team schon bei der Erstellung der Vision aus Sicht der Kund*innen zu denken und deren Bedürfnisse und Probleme als Grundlage zu sehen, nutzen viele agile Teams die XP-Praktik des Gesichtenerzählens. Es ist also kein Zufall, dass Stories als Ebene genannt wurden.
Geschichten erzählen bedeutet in diesem Kontext Vision, Epics, Stories und Tasks aus der Sicht der Kund*innen zu formulieren. Und da nur die Kund*innen selbst ihre Geschichte kennen, bedeutet dies in erster Linie, viel zu kommunizieren. Die Gesichte muss von den Kund*innen selbst kommen. Um sie zu erfahren, muss mit ihnen gesprochen werden. Die Teammitglieder treffen dann die dazugehörigen technischen Entscheidungen.
Eine gute Geschichte erstellen: Die Cs
Um gute User Stories erstellen zu können, gibt es die Leitplanken der sogenannten Cs. Die Cs Card, Conversation, Confirmation gehen auf Ron Jeffries zurück, der sie 2001 in seinem Blog-Artikel beschrieb.
Card: User Stories sollen die wichtigsten Punkte der Kund*innengeschichte festhalten. Daher müssen sie kurz und prägnant sein. Es bietet sich an, eine User Story auf eine Karteikarte zu schreiben. Der begrenzte Platz zwingt alle Beteiligten, nur die notwendigen Infos herauszuarbeiten und schlussendlich aufzuschreiben. Beim Durchlesen der Karte sollte dann klar sein, was mit der Umsetzung der Story erreicht werden soll.
Um zu überprüfen, ob auf der Karte wirklich alles wichtige steht und die Größe der Story passt, folgender Tipp: Die Entwickler*innen müssen anhand der Informationen auf der Karte in der Lage sein, den Aufwand der Karte einschätzen zu können. Ist dies nicht der Fall, muss die Story in kleinere Teile zerlegt werden oder konkreter formuliert werden.
Conversation: Es reicht nicht aus, die Story „nur“ aufzuschreiben. Wichtiger Teil des Prozesses ist es, dass sich die Kund*innen und das Entwicklungsteam auch über die Story austauschen und konkrete Punkte besprechen. In der Regel geschieht das an unterschiedlichen Stellen im Entwicklungsprozess. Nur so können alle sicherstellen, dass die aufgeschriebenen Sätze aktuell und den Bedürfnissen der Kund*innen entsprechend ist.
Confirmation: Um sicherzustellen, dass die Umsetzung auch den Vorstellungen der Kund*innen entspricht, werden zudem zu jeder Story verbindliche Akzeptanzkriterien vereinbart. So ist dem Entwicklungsteam schon vor Beginn der Umsetzung klar, worauf beim Test geachtet werden wird.
Vision, Epics, Stories und Tasks in der agilen Praxis
Wenn sich ein agiles Team zum Planning oder einem anderen Planungsevent trifft, wird das Team zunächst die Epics besprechen. Der*die Product Owner*in stellt dann seine*ihre Priorisierung vor, aus welcher hervorgeht, welches Epic zuerst bearbeitet werden soll.
Dieses Epic wird dann von allen in Stories aufgeteilt. Diese werden wiederum vom*von der Product Owner*in priorisiert, sodass klar ist, in welcher Reihenfolge die Stories bearbeitet werden sollen. Die wichtigsten Stories werden dann in den Sprint gezogen und von den zuständigen Teammitgliedern in Tasks übersetzt.
Vorteile: Agiles Planen erleichtern
Durch das Herunterbrechen und Benennen der verschiedenen Ebenen einer Idee oder eines Produktes, werden alle Ebenen dem Team nicht nur verständlicher gemacht, das Team kann so auch leichter für jede Aufgabe einschätzen, wie lange die Bearbeitung brauchen wird, welche Fallstricke eventuell zu umgehen sind und was an Zuarbeit benötigt wird. Durch diese Greifbarkeit kann das agile Team einfacher und effizienter arbeiten.
Außerdem kann so effektiver kommuniziert werden. Verschiedene Personen mit verschiedenen Rollen in einem agilen Team haben auch verschiedene Blickwinkel. Wenn die verschiedenen Ebenen benannt werden können, kann auch klarer über die Ebene gesprochen werden, die die betroffene Person interessiert. So haben beispielsweise Stakeholder vermutlich eher ein Interesse, über Epics zu sprechen als über einzelne Tasks.
Tatsächlich die User-Story der Kund*innen zu erzählen, hilft vielen Teams zudem, ein klares Bild davon zu erhalten, was der*die Kund*in für Probleme oder Bedürfnisse hat, um dann eine passende Lösung herauszuarbeiten.
