Wir haben neulich bei unseren HOOD-Kontakten die Umfrage: „Welche Themen fordern Sie in Ihrem im Arbeitsalltag heraus?“ gestartet. Wie Sie sich vorstellen können, kamen viele Antworten zu unterschiedlichsten Themen zusammen. Einige Herausforderungen drehten sich um typische Requirements-Themen wie: Anzahl der Themen im Product-Backlog, die Qualität der Backlog Items, einheitliche Erwartungen an die Definition of Done, oder auch der Weg von der Kundenanforderung in den Sprint.
Daneben gab es auch Herausforderungen, die die Themen Zeit-Management, zu wenige Fach-KollegInnen, zu viele parallele Projekte, Druck, politisches Umfeld und auch Umstrukturierung adressierten. Diese Themen sind meines Erachtens Transformations-Themen. Leider nicht leicht zu lösen, langwierig in der Umsetzung, aber auf jeden Fall sehr lohnend, um zukünftig weiterhin erfolgreich am Markt zu agieren.
Vielleicht war die Langwierigkeit der Grund, weshalb bei unserer weiteren Umfrage zum Webinar unter den Themen „Transformation aus dem Hamsterrad“, „Agilität im Systems Engineering“,  das „Backlogmanagement“ als Top-Thema hervorging.   

Backlogmanagement und Live-Session

Haben Sie in Ihrem Entwicklungs-Team bei diesem Thema auch Herausforderungen? Wo kommen Sie bei Ihrem Product-Backlog an Ihre Grenzen? Wenn Sie Interesse haben, live mit uns zu diskutieren, dann nehmen Sie am kostenlosen und interaktiven HOOD-Webinar für Backlogmanagement am 20. September von 15:00-17:00 Uhr teil. Meine Kollegen Jens, Andreas und Stefan stehen Ihnen mit Ihrem Praxis-Know-how in einem World-Café zur Verfügung.
Lassen Sie uns zur Einstimmung über ein paar Backlog-Begriffe schauen:

Nutzen des Product-Backlogs

Das Product-Backlog ist dafür da, die Produkt-Vision zu erfüllen. Denn mit der Produkt -Vision wird auch der eigentliche Wert des Produktes definiert und darauf kommt es ja an. Mit ihr können wir die Ergebnisse im Wert überprüfbar, validierbar und anpassbar machen. Die Anforderungen sind als Items im Product-Backlog aufgelistet. Ein kurzes Video von der Agile Scrum Group gibt Aufschluss:

Schätzen von Aufwänden

Die Backlog-Liste ist für alle an der Entwicklung beteiligten Personen transparent. So können alle mitdiskutieren und schätzen, mit welchen Prozessen und welchem Aufwand sie zum Produkt-Ziel kommen. Eine Möglichkeit zum Schätzen von Aufwänden ist beispielsweise das Planning Poker.

Priorisieren

Es gibt eine eindeutige Priorisierung der Backlog Items und der damit zusammenhängenden Aufgaben. So kann sich das Team auf die User Stories vorbereiten und die richtige Zeit zur Ausarbeitung und Risikoabwägung veranschlagen. 

Umsetzung

Das Ausprobieren ist wichtig. Nach ein paar Sprints kann das Entwicklerteam schon abschätzen, wie viele User Stories umgesetzt werden können. Das Team sollte bereits User Stories für 1,5 bis 2 Sprints fertigstellen. Denn dann können wir sie in einem Sprint-Planning für das Sprintbacklog anbieten. Da die Anzahl der Items im Backlog begrenzt sein muss, müssen wir das Backlog ständig überarbeiten und anpassen. Anhand des Burndown-Charts können wir den Fortschritt während des Sprints darstellen und weiter Transparenz für alle Beteiligten schaffen.

Formulieren und Schneiden von User Stories

Es macht Sinn, sich für die User Story Formulierungen zu überlegen, mit denen wir möglichst klar den Anforderungskontext des Anwenders transportieren können. User Stories beschreiben, warum etwas getan werden muss. Doch wie formuliere ich diese User Story gut? Wichtig ist dabei, mit den Stakeholdern und insbesondere mit den Nutzern des Produktes, zu sprechen. Welche Probleme sollen gelöst werden? Die Problem-Beschreibung und das Verständnis des Problems helfen dann beim Formulieren.
Auch ob es sich um Begeisterungsfaktoren handelt, können wir in der User Story bzw. auf der Item Card beschreiben. Um sie zu entwickeln, können die Nutzer leider nicht befragt werden. Denn wenn sie sich scheinbare Begeisterungsfaktoren wünschen, dann sind es bereits Leistungsfaktoren. Es gibt allerdings einige Techniken, um Begeisterungsfaktoren zu erarbeiten.
User Stories, Epics und nicht als User Story formulierte Items können alle im Product-Backlog stehen. Bei den User Stories macht es oft einen erheblichen Unterschied, ob wir die INVEST Kriterien beachtet haben. Probieren Sie es gern aus!

Akzeptanzkriterien

User Stories, die nicht ganz klar auf den Anforderungskontext hinweisen, vage, mehrdeutig und zu einer falschen Interpretation führen sind Ideen. Wir können Ideen in gute User Stories umwandeln, indem wir sie priorisierbar machen. Hier helfen die Akzeptanzkriterien. Sie definieren, was noch getan werden muss, damit die User Story vollständig ist. Sie kommen aus dem Testing. Hier fragen wir: Wird das (Teil-)Produkt vom Kunden akzeptiert, oder nicht?

Definition of Done

Im Vergleich dazu, ist die Definition of Done die Beschreibung des End-Zustands des Teil-Produktes, wenn die erforderlichen Qualitätsmaßnahmen erfüllt sind.

Tools

In der konkreten Umsetzung des „wie“ gibt es viele Lösungen und unterschiedliche Tools. Selbst innerhalb des gleichen Tools können wir bspw. analoge Karteikarten und Post-Its, oder digitale Programme verwenden. Die Tools sollten wir danach auswählen, inwieweit sie helfen, die Vision transparent zu machen, den Wert darzustellen, oder auch die Annahmen zu validieren.

6 Tipps zum besseren Product-Backlog von Agile Product Owner

Schauen Sie sich gern noch die Tipps zum Product-Backlog von Agile Product Owner an.

Ich hoffe, der keine Product-Backlog-Exkurs im Vorfeld unseres HOOD-Webinars war hilfreich. Ich freue mich sehr, wenn Sie am 20. September 2022 mit von der Partie sind.