Das klassische Vorgehen der Software-Entwicklung funktioniert aufgabengetrieben. Ein Kunde äußert einen Wunsch und erhält dazu ein Angebot. Sind die Rahmenbedingungen abgestimmt, wandert der Wunsch in die Entwicklungsabteilung. Dort werden die Aufgaben stapelweise abgearbeitet. Fehler und länger abgelegte Features haben häufig Vorrang. Je nach Auslastung und Kapazität kann es also einige Monate dauern, bis ein Kundenwunsch angegangen wird – ein Zeitraum, in dem viel passieren kann.
In einem agilen Entwicklungsprozess ist das etwas anders. Hier gibt es ein verantwortliches Teammitglied, das sich kontinuierlich um Kundenwünsche kümmert, analysiert und sie beobachtet. Der Product Owner hält die Hand darauf. Bleibt eine Aufgabe längere Zeit liegen, kann er sie im Entwicklungsteam forcieren oder mit dem Kunden Rücksprache halten: “Ist diese Aufgabe noch wichtig?”
Alle drei bis vier Wochen haben der Product Owner, das Team und der Kunde die Möglichkeit, die Aufgaben für den nächsten Sprint zu vereinbaren. Durch empirisches Vorgehen ist klar, was das Team in einem Sprint schaffen kann und wo einzelne Kunden gerade stehen. Dadurch kann es sein, dass eine eingereichte Aufgabe vor dem Start des nächsten Sprints gar nicht mehr begonnen werden muss. Möglicherweise ist der Kunde derzeit mit frisch gelieferten Features vollends zufrieden, befindet sich in einer Umstellungsphase, oder hat gerade andere wichtigere Projekte. Die damals eingereichte Aufgabe hat also inzwischen einen niedrigeren Wert für ihn. Ein klarer Fall für “story stopping”. Die Aufgabe wird vor dem Starten des nächsten Sprints aus dem Backlog aussortiert. Das ist kein Verlust, sondern ein Gewinn. Das Team erhält die Möglichkeit, sich anderen Features oder höherwertigen Storys zu widmen.
Das ist die Magie der empirischen Produktentwicklung: “The art of maximizing the amount of work not done”. Unnötige Aufgaben, die Teamkapazität kosten und womöglich den Kunden überlasten oder gar verärgern, werden erst gar nicht angegangen.