Horizontaler und Vertikaler Schnitt von Stories

Jede agile Methode teilt ihre funktionalen Anforderungen: Extreme Programming hat seine Stories, Feature Driven Development - es steht schon im Namen - seine Features und Scrum hat, je nach Quelle, seine ProductBacklog Items aka Features aka Stories. Ich beobachte oft, wieviel vom guten Schnitt der Stories abhängt. Ein Aspekt des guten Schnitts ist das vertikale Schneiden, im Gegensatz zum ungünstigen horizontalen Schnitt.

"Stories schneiden" meint den Vorgang, aus einer Anforderung gut verdaubare Häppchen zu erstellen, die schätzbar und priorisierbar sind und dem ProductOwner einen echten Mehrwert liefern.

Man stelle sich ein Backend-System vor, dass Termine, Kontakte und Aufgaben von einer Quelle abgreift, etwas damit macht und in ein Ziel schreibt. Es gibt dieses Backend-System noch nicht, der ProductOwner will es erst haben, das Team hat es noch nicht gebaut. Der ProductOwner schreibt dafür eine Story: "Lese Termine, Kontakte und Aufgaben aus der Quelle ein und schreibe sie ins Ziel."

Der ProductOwner stellt die Story dem Team vor. Das Team sagt: "Uffz!" und gibt damit zum Ausdruck, dass es da einen ziemlichen Brocken vorgesetzt bekam. Das Team weiß nicht so recht, was mit den Daten geschehen soll zwischen Quelle und Ziel, und es verzettelt sich einige Male in Nebensächlichkeiten bei der Diskussion. Der ProductOwner bittet das Team, den Aufwand zu schätzen. Das Team schätzt die Story auf 23 StoryPoints (SP), wobei einige eher 10 SP schätzen würden, andere eher 50. Dem ScrumMaster fällt auf, dass das Team im ganzen letzten Sprint 23 SP geschafft hat. Die Story ist zu groß für den Sprint. Stories sollten nie größer sein, als dass man sie nicht während eines Sprints erledigen kann. Auch traut der ScrumMaster der Schätzung nicht, da die Spanne von 10 bis 50 SP darauf hindeutet, dass das Team keine einheitliche Vorstellung von der Story hat.

Alle Anforderungen in einer einzigen Story. Die Story ist 23 SP groß, wobei die Schätzungen der Teammitglieder zwischen 10 und 50 SP auseinandergegangen sind.

Der ScrumMaster rät dem ProductOwner, die Story zu teilen. Die einzelnen Teile wären überschaubarer, einfacher zu durchleuchten vom Team und auch einfacher zu schätzen. Der ProductOwner schreibt zwei Stories: "Lese Termine, Kontakte und Aufgaben aus Quelle" und "Schreibe Termine, Kontakte und Aufgaben ins Ziel". Das Team schätzt das Einlesen mit 12 SP und das Schreiben mit 14 SP, und die Schätzungen sind einheitlicher als bei der vorherigen großen Story.

Zwei Stories, horizontal geschnitten (12 SP + 14 SP = 26 SP)

Der ProductOwner bemerkt, dass das ja nun auch nicht besser sei, als bei der großen Story: Zusammen wär's nun noch teurer geworden (12 + 14 = 26). In einen Sprint passen die beiden Stories nun auch nicht, da 26 SP für beide Stories zusammen größer ist als das, was das Team im letzten Sprint geschafft hat und laut Wetter von Gestern im nächsten Sprint schaffen wird. Außerdem fängt das Team an, die Schnittstelle zwischen den Schichten des Systems (Lesen und Schreiben) abzusprechen, wobei die enormen Abhängigkeiten der beiden Stories zueinander deutlich werden: Das Team wird sich voraussichtlich in Diskussionen um Schnittstellen-Verträge verheddern. Der ScrumMaster erkennt, dass das System horizontal nach den Schichten (Frontend, Backend) geschnitten wurde, was die Probleme beim ProductOwner und beim Team verursacht.

Der ScrumMaster bittet den ProductOwner, das System vertikal in Stories zu schneiden. Der ProductOwner versucht es: "Lese Termine aus Quelle und schreibe sie ins Ziel." - "Lese Kontakte und schreibe sie ins Ziel." - "Lese Aufgaben und schreibe sie ins Ziel." Das Team stellt fest, dass die Aufgaben weitestgehend unabhängig voneinander sind, und freut sich, keine Schnittstellen-Verträge festklopfen zu müssen.

Drei Stories, vertikal geschnitten und (noch) nicht schätzbar, da nicht klar ist, in welcher Story welche storyübergreifende Anforderung "versteckt" ist

Das Team versucht zu schätzen - und scheitert. Es weiß jetzt nicht, wo es die zusätzlichen Aufgaben unterbringen soll, die in jeder Story enthalten sein werden: Beim Einlesen sollen die Daten auch validiert und beim Schreiben nach Angaben vom Ziel umgewandelt werden. Beim Lesen soll ein Puffer zum Einsatz kommen, beim Schreiben eine Warteschlange. Das Team sagt, das hätten sie implizit mitgeschätzt bei der ganz großen Story oder den beiden mittelgroßen, horizontal geschnittenen Stories.

Der ProductOwner wandelt die impliziten Anforderungen in explizite Stories um: "Validiere Termine beim Lesen." - "Validiere Kontakte beim Lesen." - "Validiere Aufgaben beim Lesen." - "Wandle Termine um vorm Schreiben gemäß Ziel." - "Wandle Kontakte um vorm Schreiben gemäß Ziel." - "Wandle Aufgaben um vorm Schreiben gemäß Ziel." - "Baue Puffer beim Lesen ein." - "Baue Warteschlange beim Schreiben ein." Das Team schätzt erneut: Termine und Kontakte zu lesen und zu schreiben kosten je 3 SP, Aufgaben zu lesen und zu schreiben kosten 4. Das Validieren schlägt mit je 2 SP zu Buche, das Umwandeln 1 bzw. 2 bzw. 3 SP. Der Puffer kostet 2 SP, die Warteschlange 4.

Elf Stories, vertikal geschnitten und geschätzt (3 SP + 3 SP + 4 SP + 2 SP + 2 SP + 2 SP + 1 SP + 2 SP + 3 SP + 2 SP + 4 SP = 28 SP)

Der ProductOwner wird ungehalten, denn er rechnet nach, dass ihn alles zusammen 28 SP teuer zu stehen kommen werden. Er wäre lieber bei der einen großen Story geblieben, denn die hätte ihn 7 SP weniger gekostet. Der ScrumMaster erklärt, dass die Schätzung nun wesentlich genauer sei und das Team vor allem jetzt das explizit schätzen konnte, was vorher nur implizit in die Schätzung eingegangen war. Von daher sei jetzt nur transparent gemacht worden, was schon die ganze Zeit dagewesen wäre, vorher allerdings verdeckt.

Der ProductOwner wirft ein, dass trotz aller Teilung die Summe nicht in den nächsten Sprint passe. Der ScrumMaster sieht das auch so, und teilt dem ProductOwner mit, dass sie jetzt einen kritischen Pfad hätten (nicht zu verwechseln mit der Methode des kritischen Pfades). Der ScrumMaster zeigt dem ProductOwner den kritischen Pfad:

Elf Stories, drei davon auf dem kritischen Pfad (kritischer Pfad = 3 SP + 3 SP + 4 SP = 10 SP)

Der ProductOwner versteht noch nicht ganz: Was bringt ihm der kritische Pfad? Der ScrumMaster erläutert, dass alles auf dem kritischen Pfad Liegende ausschlaggebend für das erreichen des SprintGoals ist. Das, was der ProductOwner haben wolle, sei das Lesen von Daten aus einer Quelle und das Schreiben der Daten in ein Ziel. Die entsprechenden Stories kosten den ProductOwner nur 10 SP, und sind mit ziemlicher Sicherheit am Ende des Sprints umgesetzt. Der ProductOwner könnte dann sein Kerngeschäft (Lesen und Schreiben von Daten) vorführen, testen, damit experimentieren, sogar damit in einer Beta-Phase online gehen.

Der ScrumMaster führt weiter aus, dass diese Stories für den vertikalen Schnitt durch das System - er nennt es auch "den Durchstich" - erst einen vollständigen Integrationstest durch alle kritischen Bereiche des Systems ermöglichen, ja sogar eine ideale Grundlage für Akzeptanztests bilden. Hierfür müssen alle wichtigen Bereiche des Systems kollaborativ miteinander arbeiten. Jedes Sandkorn im Getriebe würde sofort bemerkt werden. Sobald ein Durchstich durch das System erst einmal erreicht ist, dienen die Akzeptanztests als Regressionstests und halten das System dauerhaft am Leben.

Was mit den anderen Stories denn noch sei, die nicht auf dem kritischen Pfad liegen, möchte der ProductOwner wissen. Die seien, so der ScrumMaster, seitlich an den kritischen Pfad anzudocken. Der Durchstich würde quasi verbreitert. Bei der Umsetzung der nicht auf dem kritischen Pfad liegenden Stories könne der Durchstich als Unterstützung angesehen werden: Die Validierung erweitert das Lesen um einen Aspekt, wodurch das Lesen als solches aber nicht beeinträchtigt wird. Die vorhandene Infrastruktur, geschaffen per Durchstich, kann ausgebaut werden. Und falls es Komplikationen während des Sprints gibt, werden allenfalls die Stories im Sprint nicht erledigt, die nicht auf dem kritischen Pfad liegen.

Der ProductOwner fügt den Stories auf dem kritischen Pfad die aus seiner Sicht höchstpriorisiertesten Stories hinzu, so dass der Sprint "voll" wird. Er wählt das Validieren mit je 2 SP, den Puffer und die Warteschlange für 2 bzw. 4 SP, und das Umwandeln der Termine für 1 StoryPoint. Zusammen mit den 10 SP für die Stories des kritischen Pfades kommt er so auf 23 SP, was dem entspricht, was das Team im letzten Sprint geschafft hat.

Elf Stories, neun davon im jetzigen Sprint eingeplant (23 SP), zwei davon nicht im jetzigen Sprint eingeplant (5 SP)

Alles wird gut, meint der ScrumMaster.

Update: Dank an Jens Coldewey fürs Korrigieren einer Addition.