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.
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.
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.
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.:
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.
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.
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 wird an vielen Orten erwähnt, jedoch fast nie beschrieben. Was steht hinter diesem Wort? Der Scrum Guide formuliert dies so:
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.
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.
Normales Backlog | Mittleres Backlog | Grosses Backlog | |
---|---|---|---|
Level-3 | Epics | ||
Level-2 | Epics | Features | |
Level-1 | User Stories | User Stories | User Stories |
Level-0 | Sub-Tasks | Sub-Tasks | Sub-Tasks |
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.
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.
Diese und weitere Fragen behandeln wir ganzheitlich in unserem dot.benchmark, damit wir gemeinsam das Potenzial deines Teams identifizieren, aktivieren und entfalten können.
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!
diese Artikel Scrum
Belchenstrasse 7
CH-4600 Olten
+41 62 962 26 26
Keine Kommentare bis jetzt
Lass uns wissen, was du darüber denkst.