Wohl schon jeder Product Owner, Business Analyst oder Requirements Engineer ist über die Fragen gestolpert «Weshalb muss ich überhaupt Backlog-Items schneiden?» respektive «Wie schneide oder zerkleinere ich die Backlog-Items sinnvoll?». Es ist ein immer wiederkehrendes, viel diskutiertes Thema und doch ist es eine wichtige Fertigkeit eines Product Engineers. Selbst wenn diese Tätigkeit keine Raketenwissenschaft ist, ist diese nicht zu unterschätzen.
Dieser Blog summiert die häufigsten Herausforderungen und erläutert Dir den Mehrwert des Schneidens von Backlog-Items. Nebst dem ich Dir einfache und hilfreiche Anwendungstipps für den Praxistransfer zur verfügung stelle. Mit diesen wenigen Tipps und den richtigen Gedanken im Hinterkopf wird es Dir gelingen gute Ergebnisse zu erzielen.
Backlog-Items – egal ob Epic, Feature und Story – zu schneiden klingt im ersten Moment einfach, hat aber durchaus seine Tücken. Nicht selten kommt es vor, dass bei einem Vorhaben schlechte Erfahrungen mit dem Schneiden von Backlog-Items gemacht werden. Als Folge davon wird das nächste mal häufig darauf verzichtet. Doch zu grosse Backlog-Items in die Entwicklung zu geben bringt teils folgenschwere Nachteile oder Probleme mit sich. Typische Symptome von zu grossen oder schlecht geschnittenen Backlog-Items sind:
- Lange Wartezeit auf eine erste Version des nutzbaren Produkts oder Produktinkremente
- Die Entwicklung einzelner Backlog-Items dauert ewig oder sehr lange
- Erhöhtes Risiko einzelner Backlog-Items
- Umsetzung von Backlog Items, die selbst keinen Nutzer-Mehrwert liefern
- Einzelne Backlog-Items können nur in Kombination mit anderen BL-Items umgesetzt werden (Abhängigkeiten)
- Der Grössen- / Aufwandsunterschied der Items im Backlog ist beachtlich
- Das Deployment einzelner Backlog-Items ist schwierig oder nicht möglich
- Es ist schwierig, für einzelne Backlog-Items Akzeptanzkriterien und Abnahmetests zu definieren
In der Praxis wird in vielen Fällen die Ursache falsch gedeutet oder diese erst gar nicht untersucht. Das ein besseres Schneiden der Backlog-Items vielen Problemen entgegenwirkt, wird daher nur selten erkannt. Dabei ist es nicht notwendig, eine Wissenschaft daraus zu machen. Man muss sich lediglich ein paar Prinzipien bewusst sein und beim nächsten Mal die richtigen Fragen stellen.
Was ist der Hauptnutzen von kleingeschnittenen Backlog-Items? Und rechtfertigt dies den dazu notwendigen Aufwand?
Diese zentrale Frage kann mit unzähligen Argumenten beantwortet werden. Die eigentliche Essenz liegt jedoch in den Prinzipien und Paradigmen der agilen Produktentwicklung - kurze Feedbackzyklen und iterative Entwicklung des Produktes. Gestützt darauf kann die Antwort auf zwei zentrale Argumente reduziert werden. Eine kontinuierliche Lösungserarbeitung in kleinen Schritten...
- Senkt die Tragweite von Annahmen und Ungewissheit. Durch eine schnellere Umsetzung kann früher Feedback eingeholt werden, was wiederum die Risiken minimiert.
- Verringert die Time-to-Market. Früher mit einem Produkt am Markt zu sein wird immer entscheidender und beeinflusst Investitionsentscheide massgebend.
Ist man von der Notwendigkeit und dem Mehrwert des Schneidens von Backlog-Items überzeugt, stellt sich unweigerlich die Frage, nach welcher Methodik oder Vorgehen man Items schneiden soll. Es gibt verschiedene Prinzipien und Techniken, welche hier Anhaltspunkte liefern. Die gängigsten Theorien proklamieren ein Schneiden nach den folgenden acht Regeln oder Techniken:
Diese theoretischen Methoden helfen, eine gewisse Standardisierung in einem Team zu etablieren, brauchen aber Übung und Erfahrung. Darüber hinaus gibt es nicht die einzig richtige Technik. Je nach Kontext und Rahmenbedingung eines Vorhabens sind unterschiedliche Techniken anwendbar oder nicht. Häufig ist deshalb eine Mischung der Techniken unausweichlich und zielführend. Weitere hilfreiche und ergänzende Werkzeuge sind etwa Story-Maps, Customer Journey oder Service-Blueprints.
Zuerst in die Qualität INVESTieren, dann ins Schneiden
Es ist intuitiv und verlockend, ein Thema zuerst in kleine Stücke aufzuteilen (oder eben zu schneiden) und danach die Items mit Details und Spezifikationen anzureichern (verfeinern). Man kann dadurch zwar die ersten (kleineren) Backlog-Items schneller «fertig» definieren, aber es wird ungleich schwieriger, den Überblick über das Gesamtbild und die geschnittenen Items zu behalten. Dieses Vorgehen ist deshalb eine trügerische Vereinfachung und verschiebt allfällige Inkonsistenzen oder Widersprüche nur nach hinten. Korrekterweise sollte ein Thema zuerst in seiner Gänze erfasst werden und gewissen Ansprüchen genügen, bevor es für die Umsetzung selektiert und geschnitten wird. Eine hilfreiche und bewährte Hilfestellung hierfür ist das Akronym INVEST.
Die Aspekte des INVEST Akronyms stellen quasi Qualitätskriterien für Backlog-Items dar. Werden diese berücksichtigt und grösstmöglich erfüllt, kann dadurch eine gute Voraussetzung geschaffen werden, um Backlog-Items zu schneiden. Das zugrundeliegende Ziel dabei ist stets, die Lösungserarbeitung in möglichst kleinen und kontinuierlichen Schritten zu ermöglichen.
Für den Einstieg ins Schneiden von Backlog-Items gibt es ein paar hilfreiche Tipps und Tricks in der Form von einfachen Fragen, die du im Hinterkopf behalten solltest:
- Ist das Backlog-Item bereits ausreichend definiert und erfüllt es die INVEST Regel?
Ein Backlog-Item sollte zuerst ausreichend definiert werden, bevor es geschnitten wird - und nicht umgekehrt. - Muss das Backlog-Item überhaupt geschnitten werden?
Hilfreiche Faustregel: Ein Item sollte nicht umfangreicher als 1/6 bis 1/10 der Sprintkapazitäten (Scrum) / Durchsatzmenge (Kanban) sein! - Kann der Anwendungsfall / Inhalt / Umfang des Items vereinfacht werden?
Versuche das Prinzip Minimal-Viable-Feature anzuwenden. Alles was nicht wirklich zwingend notwendig ist entfernen . - Kann zu Beginn eines neuen Features auf Variation verzichtet werden?
Häufig ist es am wirtschaftlichsten und risikoärmsten, den vollständigen Mehrwert eines Features in Schritten nacheinander zu realisieren - Welcher Anwendungsfall liefert den grössten Mehrwert oder ist am Erkenntnisreichsten?
Es ist meist am sinnvollsten, bei der Umsetzung mit dem grössten Mehrwert oder dem grösste Lernpotenzial zu beginnen
Egal für welches Prinzip oder Methodik du dich beim Schneiden von Epics, Features oder Stories entscheidest, sei mutig und lernfreudig! Merke dir lieber ein paar wenige Fragen als Hilfestellung anstatt die Theorien das Schneiden von Items zu vernachlässigen.
Wenn du Fragen zu diesem Thema hast, gerne mehr darüber erfahren willst oder du Hilfestellung bei konkreten Projekten benötigst, zögere nicht und setz dich mit uns in Verbindung. Wir haben ein breites Angebot an Weiterbildungen in unser Academy und helfen dir gerne bei konkreten Vorhaben mit unseren Product Engineering Services.