Ansätze um User Stories auf zuteilen/kleiner zu schneiden

Question

Hallo zusammen,
immer wieder erlebe ich es, dass es Teams und POs schwerfällt die Aufgaben so zu verfassen, dass sie klein genug sind um in einem Sprint umgesetzt zu werden.

Mit welchen Ansätzen/Tools kann ich das schneiden von großen User Stories in kleinere User Stories angehen?

Answer 1

Ja, das erlebe ich auch regelmäßig als Schwierigkeit und ein wirkliches Patentrezept habe ich da auch nicht.

Ich versuche immer als erstes eine möglichst kleine Story zu erstellen, die wirklich nur die minimal notwendige Funktionalität/Detailtiefe beschreibt. Dabei hilft es bei allem was beschrieben und diskutiert wird, die Frage zu stellen, ob es das wirklich für den Start braucht. Alles was erst einmal nicht gebraucht wird, packe ich in eine "Folgestory", die dann weiter beschrieben bzw. detailliert wird, wenn die erste Story durch ist.

Dabei habe ich gute Erfahrungen damit gemacht, einzelne Funktionalitäten abzuschneiden (Bsp. Löschen und Verändern eines Objektes nicht gleich beim Anlegen mit zu implementieren) bzw. notwendige Informationen zu einem Objekt oder Prozess im ersten Schritt auf ein Minimum zu reduzieren und erst in weiteren Stories zu implementieren. Damit breche ich zwar ein wenig mit dem "I" des INVEST Prinzips, da die jeweils späteren Stories natürlich nicht vor den ersten implementiert werden. Das nehme ich aber in diesem Fall in Kauf, weil ich es wichtiger finde, Fortschritte zu erzielen.

Answer 2

Hierzu habe ich leider keine magische Lösung. Ich weiß nur eins: Gemeinsam ist diese Übung einfacher (und besser als alleine). Wenn PO's die Stories alleine schneiden, dann kommen oft Stories raus die zwar für Kunden einen Nutzen bieten, aber nur sehr umständlich (wenn überhaupt) umsetzbar sind. Wenn die Teams (Devs) die Stories schneiden, dann kommen sehr praktikable, strukturierte und machbare Schnitte raus, die aber oft dem Kunden keinen Nutzen bieten (und auch nicht zur frühen Validierung von Annahmen dienen können).

Deswegen ist mein Trick kleine Gruppen zu bilden (Devs + PO), denn man muss ja nicht alles in der Großen Runde machen, um sich solche komplexen Stories anzuschauen. Da kommen erfahrungsgemäß auch ohne viel Technik und Moderation gute Ergebnisse raus.

Comments

Wichtig bei der gemeinsamen Besprechung (=Refinement) ist aus meiner Sicht, DASS eben gemeinsam das Problem verstanden wird. Ich verweise hier gerne auf Jeff Patton, der nicht müde wird zu betonen, dass es darum geht 'Gemeinsames Verständnis' des Kundenproblems zu erreichen. Wenn POs alleine Stories schreiben (und noch schlimmer gleich Lösungsideen mit einbringen) tritt das Verständnis für das eigentliche Kundenproblem in den Hintergrund. Als Folge davon, stehen bereits viele Details in den User Story Beschreibungen. Der Kontext, wie der PO aber dahin gekommen ist, ist leider verloren. Wenn sich das Team dann weitere Gedanken über die Lösung macht, ist man sehr oft schon nicht mehr 'on the same page'.
Ansonsten kann ich Giancarlo absolut zustimmen: In der Gruppe finden sich leichter Ansätze, wie man große Stories zerschneiden kann als alleine. Durch die gegenseitige Inspiration entstehen aus der Gruppe Ideen, die alleine nicht möglich wären. Das macht dann ein Team zu mehr als der Summe ihrer Mitglieder.

Answer 3

Ich erlebe es auch oft, dass man sich schwer tut, inkrementell iterative User Stories herauszuschneiden. Es ist zugegebenermaßen eben auch nicht leicht.

Was aus meiner Sicht auf jeden Fall hilft, ist
a, Visualisierung (am Besten mit Stickynotes an der Wand oder mindestens auf einem digitalen Whiteboard). Menschen können sich später viel besser an das Bild und damit verbundene Assoziationen erinnern als wie das in einem geschriebenen Dokument möglich wäre. Außerdem kann auf eben die aufwändige Dokumentation der Gedankengänge oft verzichtet werden. Das schafft Effizienz.
b, Gemeinsam mit den wichtigsten Teamvertretern (bei kleinen Teams alle), um die Intelligenz des Teams nutzbar zu machen und allen die Gedankengänge zugänglich zu machen, die dazu beigetragen haben, die passenden User Stories zu finden.
c, Immer ausgehend vom eigentlichen Problem, das es zu lösen gilt. Oft ist das nicht konkret genug bekannt bzw. nicht genügend vom Endkunden her betrachtet. Wenn ich die Frage stelle, welches Problem tatsächlich gelöst werden soll, ist oft Schweigen die Reaktion. Dann frage ich z.B. anders: Was passiert, wenn wir nichts tun? Welche Auswirkung hat das? Wer wird dann enttäuscht sein, wenn wir ablehnen? Das führt dann schon eher zum Verständnis des eigentlichen Problems.