dot.tipp - Die wichtigsten Elemente im Backlog Management als Checkliste

Welche Faktoren machen ein richtig gutes Backlog aus? Wie stelle ich als Product Owner sicher, dass meine Anforderungen in einer guten Qualität zur Verfügung stehen? Antworten zu solchen und weiteren Fragen zum Thema Backlog Management in diesem Blog.

Die Basics als Checkliste?

Nun fragen sich alle Leser, woher bekomme ich die Checkliste? Wie sollte es anders sein, am Ende dieses Blogs natürlich! Aber zuerst müssen wir zusammen die Grundlagen legen.

Positive Faktoren für dein Backlog

Wenn das ganze Team am Schmollen ist, persönliche Angriffe und harsche Kritik an der Tagesordnung sind, dann wird auch das Backlog danach aussehen. Versucht darum, Spass und Freude an der Arbeit als positiven Faktor zu behalten, und strapaziert die dazu verwendete Zeit nicht all zu sehr.

Diskutiert den Prozess zum Befüllen des Backlogs und hinterfragt den Inhalt. Nur so bleiben alle Backlog-Elemente qualitativ gut und alte Dauerbrenner finden den Weg in den Papierkorb - wo sie hingehören. Sind diese positiven Faktoren gegeben, so können wir uns den Grundlagen widmen.

Grundlagen

Wie priorisiert ihr euer Backlog? Wer ist dazu befugt? Wer fühlt sich dazu verantwortlich? Alles Fragen, die schnell eine Antwort finden sollten! Im klassischen Scrum geschieht dies durch den Product Owner, der zusammen mit den Stakeholdern die richtigen Methoden kennt, um schnell und effizient zu priorisieren. Wenn nicht, dann sollte er unbedingt in unserem Kurs für POs vorbeischauen: HIER.

Wie macht man nun aus dem Berg von Anforderungen ein gutes Produkt? Man versucht, es so zu zerlegen, dass am Ende ein MVP daraus entsteht. So wird dem Kunden möglichst schnell ein testbares Produkt geliefert, welches er testen und worüber er Feedback geben kann. Der grösste Fehler wäre es, klassisch zu schneiden und danach versuchen, es zu integrieren. Z.B.:

• Back-End Services
• Logik
• Schnittstelle zu Drittherstellern
• Front-End

Was ist der Unterschied zwischen einem MVP und einem Prototyp?

Ein Prototyp ist eine Methode, um über Funktionen in einem frühen Stadium zu diskutieren. Z.B. in dem man schon auf dem UI herumklicken kann, obwohl das Produkt noch gar nicht lauffähig ist. So kann man mit dem Kunden am Objekt besprechen, wie das Produkt aussehen soll, und muss nicht die Spezifikation Zeile für Zeile reviewen.

Ein Prototyp wird per Definition nach Abschluss der Prototypen-Phase verworfen. Ein Prototyp ist weder ein Produkt-Inkrement noch ein MVP.

Bei einem MVP läuft das Produkt bereits in einer minimalen Form, sodass auch hier der Kunde seine Meinung abgeben kann. Nicht simuliert, nicht auf einem Blatt Papier oder in einer PowerPoint-Präsentation, sondern mit minimalen Daten, minimalen Funktionen und minimalem UI.

Releases?

Jetzt kommt schnell die Frage: "Wo bleibt hier bitte der Überblick?" Aus einem Backlog können Aussenstehende schlecht erkennen, wie alle diese Elemente ein Produkt ergeben sollen. Darum kann man bei grösseren Vorhaben das Produkt in Releases bündeln und diese auf einer Roadmap auslegen. Am besten mit der Hilfe von User Story Mapping, oder einer Customer-Journey.

Backlog Management

Backlog Management wird an vielen Orten erwähnt, jedoch fast nie beschrieben. Was steht hinter diesem Wort? Der Scrum Guide formuliert dies so:

• Die Product-Backlog-Einträge klar zu formulieren.
• Die Einträge im Product Backlog so zu sortieren, dass Ziele und Missionen optimal erreicht
  werden können.
• Den Wert der Arbeit zu optimieren, die das Entwicklungsteam erledigt. Sicherzustellen, dass das Product Backlog sichtbar, transparent und für alle klar ist sowie zeigt, woran das Scrum-Team als nächstes arbeiten wird.
• Sicherzustellen, dass das Entwicklungsteam die Product-Backlog-Einträge im erforderlichen
  Masse versteht.

Inhaltlich hilf dir unsere Checkliste weiter. Was dir die Checkliste aber nicht abnehmen kann, ist der Prozess, der zu den oben genannten Aufgaben führt. Früher Backlog Grooming und heute Backlog Refinement genannt. Regelmässig wird das Backlog ergänzt, priorisiert, mit dem Team hinterfragt, gekürzt oder mit wichtigen Details verfeinert.

Empfehlungen

Wie kannst du dein Backlog in Einklang bringen, damit es nicht ein Ideenhaufen ist, sondern eine Struktur hat, eine gute Priorisierung und dem Kunden mit jedem Sprint mehr Wert liefern kann?

Wie sieht die Struktur in deinem Backlog aus? Gibt es "nur" User Stories? Habt ihr bereits Epics, Features, oder sogar Themen? Was sind gängige Strukturen? Varianten nach Best Practice sind in der unten angefügten Tabelle zu sehen. Hier kommt es auf die Grösse des Backlogs an, je grösser, desto mehr Struktur ist nötig, um einfach den Überblick behalten zu können.

Was ist eine User Story?

Hier entstehen schon die ersten Missverständnisse im Befüllen des Backlogs. Wieso? Weil viele einfach ihre langen Spezifikationen in eine User Story schreiben und das Gefühl haben, dass sie neu agil arbeiten.

Eine User Story ist ein "Kommunikationsversprechen", damit sich der PO und der Entwickler daran erinnern, was sie für die Umsetzung einer Produktfunktion besprochen haben.

Nach dieser Definition kommt niemandem in den Sinn, einen Roman als User Story zu formulieren. Oder? Leider doch. Viele tun sich damit auch schwer, eine Anforderung aus der Benutzer (User) Perspektive zu beschreiben. Aber hierzu mehr in einem anderen Blog zum Thema Effective Delivery.

Mir fehlen noch Infos zu...

• ...wer schreibt die User Stories?
• ...warum braucht es eine Definition of Ready (DoR)
• ...brauchen wir immer noch funktionale und nicht funktionale Anforderungen?
• ...wie funktioniert unser Team?

Diese und weitere Fragen behandeln wir ganzheitlich in unserem dot.benchmark, damit wir gemeinsam das Potenzial deines Teams identifizieren, aktivieren und entfalten können. 

Wie weiter?

Jetzt schnell unten die Checkliste downloaden, bevor ihr irgendetwas anderes macht. Wie weit erfüllt euer Backlog die aufgeführten Ratschläge und Kriterien? Wir sind sehr gespannt auf euer Feedback!