Ein Reporting ist eine Berichterstattung mit zielgruppengerechter Darstellung von Informationen.
Ein optimales Reporting …
… sollte
- einfach zu handhaben sein,
- in hohem Maße verständlich sein,
- ohne Zusatzaufwand jederzeit vorhanden und einsehbar sein,
- wenn möglich, Echtzeitinformationen liefern und
- genau die Informationen liefern, die für die jeweilige Zielgruppe von Interesse ist!
Vorstellung eines implementierten Reportings
| Anwendung: | eShop |
| Teams: | 8 Scrum Teams |
| Methoden: | Scrum und SAFe |
| Ticketingsystem: | Atlassian Jira + Structure |
| Anzahl Strukturebenen: | 3 - Requirements AND Epics AND (Stories, Tasks, Bugs) |
Exkurs zum Thema Anforderungen
Es gibt kleine, mittelgroße, große und wirklich große Anforderungen.
Für eine kleine Anforderung, deren Umsetzung gerade mal ein paar Tage dauert, reicht es in der Regel aus, diese in Form einer Story oder einer Task zu formulieren. Eine kleine Anforderung mit aller Gewalt einem Epic – einer übergeordneten Klammer – unterzuordnen, ist nicht wirklich sinnvoll.
Die einzelnen Aufgaben einer mittelgroßen Anforderung, die vielleicht von mehreren Entwicklern umgesetzt werden müssen und die für die Umsetzung innerhalb eines Sprints zu umfangreich sind, können über ein Epic als “zusammengehörend” gebündelt werden. Das Epic bildet also die Klammer für logisch zusammengehörende Aufgaben.
Epic als Milestones
Große und wirklich große Anforderungen haben oftmals einen Umfang, der es erforderlich macht, diese schrittweise über mehrere Milestones (= Zwischenziele) umzusetzen. Diese einzelnen Milestones würden dann in Form von Epics benannt werden.
Wichtig ist, dass diese Epics nicht nur eine Aufteilung der Arbeiten in Teil 1, Teil 2, Teil 3, usw. darstellen, sondern wenn möglich, für sich abgeschlossene Milestones darstellen, die wenn irgend möglich schon für sich alleine einen sogenannten added Value darstellen.
Anforderungsdokumentation und Ticketing
(Jira-) Tickets dienen ausschließlich der Aufgabenverwaltung und keinesfalls der Dokumentation von Anforderungen.
Beispiel / Handlungsempfehlung für den PO:
Der Product Owner trifft den Vertriebsleiter für einen Stakeholder-Smalltalk auf einen Kaffee. Dabei erzählt ihm der Vertriebsleiter von einer interessanten Funktionalität, die ein Kunde gerne umgesetzt hätte. Es gestaltet sich dazu ein angeregtes Gespräch.
Gleich nach dem Smalltalk erstellt der Product Owner ein JIRA-Ticket vom Typ Requirement und eine Confluence-Seite und verlinkt diese gegenseitig. Die Überschrift der Confluence-Seite und die Summary des Jira-Tickets spiegeln in prägnanter und verständlicher Form die Anforderung wider.
Ist das “was wird benötigt” halbwegs klar, holt sich der Product Owner noch weitere sogenannte Subject Matter Experts ins Boot, um das “wie könnte es umgesetzt werden” zu erörtern. Er oder sie teilt das Confluence-Dokument nun mit noch weiteren Experten. Wer auch immer sinnvoll dazu beitragen kann, das Wie zu beschreiben, wird aufgefordert mitzumachen. Developer, UX’er, etc.
Schön langsam kristallisiert sich heraus, dass die Anforderung, in Bezug auf den zu erwartenden Implementierungsaufwand, ein wahres Monster ist. Der Product Owner, in Zusammenarbeit mit den anderen Experten, definiert Milestones (= Zwischenziele), um möglichst rasch schon erste Ergebnisse liefern zu können. Diese Milestones werden in Form von Epics abgelegt, die allesamt mit dem Requirement-Ticket verlinkt sind. Das Requirement stellt dabei das “Parent” dar.
Sobald ein Epic/Milestone hinreichend gut spezifiziert ist und der Product Owner selbiges demnächst umgesetzt sehen möchte, können die Developer mit dem Breakdown des Epics/Milestones in Stories und/oder Tasks beginnen. Aus der Summe der geschätzten Aufwände der Stories und Tasks eines Epics ergibt sich, ob der Milestone in einem Release/PI umgesetzt werden kann oder ob es sinnvoll wäre, diesen Milestone – dieses Epic – noch einmal aufzuteilen.
Sowohl die Epics als auch die Stories und Tasks haben ihren Inhalt in Confluence dokumentiert; nicht im Ticket selbst. Im Ticket, ganz gleich ob es sich um das Epic oder die Story handelt, ist lediglich der Verweis auf die in Confluence dokumentierte Anforderung hinterlegt sowie ein „in scope“ und „out of scope“, damit auch das Richtige umgesetzt wird. Warum auch in jedem einzelnen Story/Task noch einmal die Anforderung niederschreiben, die doch schon in Bild und Text und zusammengehörend in Confluence abgelegt ist?
Das Reporting
Das Management interessiert sich in der Regel weniger für die einzelnen Stories und Tasks, dafür aber umso mehr für die Milestones und die Requirements selbst. Aus diesem Grunde sollten die Summaries dieser beiden Hierarchieebenen klar und verständlich formuliert sein.
Wenn wir der Annahme sind, dass Milestones/Epics in der Regel innerhalb eines Quartals/PIs umgesetzt werden sollen, dann ist das die Ebene, auf der die Musik spielt. Als Manager würde mich das Kleinteilige der Story- und Task-Ebene nicht interessieren. Sofern eine große Anforderung – abgelegt in Jira als Requirement – unter Umständen auch einen langen Lebenszyklus hat, ist auch die (Anforderung) unter Umständen nicht wirklich geeignet für ein Reporting. Sofern eine große Anforderung über mehrere oder gar viele Milestones verfügt, verweilt die Anforderung gegebenenfalls über einen längeren Zeitraum im Status „In Development“.
Beispiel:
Ein Requirement könnte beispielsweise „Reduzierung Materialverbrauch“ oder „Reduzierung Energieverbrauch“ lauten und beides könnte über verschiedene Maßnahmen erreicht werden, die wiederum als (hoffentlich verständlich formulierte) Milestones erreicht werden. Jeder Milestone (= Epic) sollte innerhalb eines Quartals/Releases/PIs umgesetzt werden können und die umzusetzenden Aufgaben sind dann jeweils dem jeweiligen Epic untergeordnet.
Oder: Optimierung des User Interface Fahrzeug-Cockpit. Auch das könnte ein übergeordnetes Ziel sein, das oberhalb der Epic-Ebene in Form eines Requirement-Tickets abgelegt wird und dem dann verschiedene Epics (= Milestones) untergeordnet sind.
Wichtig ist, dass sowohl die übergeordneten Requirements als auch die Epics (= Milestone) für die berechtigten Adressaten des jeweiligen Reportings verständlich formuliert sind. So manches Mal haben wir bei Kunden schon Summaries vorgefunden, bei denen dann selbst der Product Owner zwei Wochen später nicht mehr wusste, was damit gemeint war.
Wichtig ist, dass sowohl die übergeordneten Requirements als auch die Epics (= Milestone) für die berechtigten Adressaten des jeweiligen Reportings verständlich formuliert sind. So manches Mal haben wir bei Kunden schon Summaries vorgefunden, bei denen dann selbst der Product Owner zwei Wochen später nicht mehr wusste, was damit gemeint war.
JIRA Automation
Implementierte Logiken:
- Wird einem Epic eine Story oder eine Task untergeordnet und das betreffende Epic wäre noch in Spalte „To Do“, würde es automatisch in die Spalte „In Refinement“ geschoben werden.
- Sobald die erste Story oder Task des Epics sich in einem aktiven Sprint befindet, wird das Epic in die Spalte „In Development“ geschoben.
- Sobald alle untergeordneten Issues den Status DONE haben, wird das Epic in die Spalte DONE geschoben.
Analog dazu werden die übergeordneten Tickets, die Requirements, behandelt.
- Sobald eines der untergeordneten Epics die Spalte „To Do“ verlässt, wird das Requirement in eine Spalte „In Bearbeitung“ geschoben.
- Etc.
Durch die Nutzung der JIRA Automation ist es einfach, das Reporting up2date zu halten. Wann auch immer ein Manager – z. B. der Product Manager – sich das Epic Board betrachtet und hier vielleicht zuerst einmal auf die Prio-1-Epics fokussiert, wird er/sie den Status Quo der wichtigsten Milestones ersehen. Sofern die Karten auf dem Epic-Board gut konfiguriert sind, können die Epics auch den übergeordneten Zielen, bzw. den Anforderungen (= Requirements) zugeordnet werden.
Conclusio
Durch Struktur und verständlich formulierten Summaries – zumindest auf Epic- und der/den darüber liegenden Ebenen – lässt sich ein einfach zu verstehendes und einfach zu handhabendes (nahezu) Echtzeit Reporting aufbauen, über das dann jederzeit des Status Quo der Projektabwicklung abgerufen werden kann; und das ohne regelmäßig wiederkehrenden Aufwand für die Berichterstellung.
Sie brauchen Unterstützung bei der Implementierung eines solchen Reportings?
