Die Ausgangslage sowie Hinführung wurde in Teil I der Geschichte behandelt. Leser denen Teil I unbekannt ist mögen ihn hier nachlesen: www.sophist.de/sophist-blog/blog/eine-kleine-user-geschichte-teil-i. Hier nun die Fortsetzung der Erzählung.

Die Ausgangsfrage sei hier noch einmal wiedergegeben: Wie schneidet bzw. gestaltet man User Stories unter gegebenen Randbedingungen damit sie optimal in einen Sprint passen bzw. die richtige „Größe“ besitzen?

Eine Runde von SOPHISTen schloss sich mit dieser Fragestellung in einen Raum ein und diskutierte angeregt über mögliche Antworten auf diese Frage. Die Gedankenspiele wurden dabei gleich praktisch ausprobiert. Ich möchte anhand eines kleinen Beispiels aufzeigen, welche Gedanken wir uns über die Schneidung der User Stories gemacht haben und welche möglichen Lösungsansätze wir auf der Grundlage des „Cheat Sheets“ erarbeitet haben.

Als Grundlage für unsere Überlegungen diente uns eine erfundene User Story für eine Online Partnerbörse:
„Als Benutzer will ich anhand einer Suchfunktion zu mir passende Personen finden, so dass ich mit diesen in Kontakt treten kann.“

Neben dem Suchalgorithmus, der passende Partner anhand des eigenen Profils und der Profile der anderen Benutzer findet (und der für sich schon eine Mammutaufgabe darstellt), gehören zu dieser Story auch die Eingabe- und Ausgabemaske, eine weitere Funktion zum direkten Kontaktaufnehmen mit den gefundenen Personen und natürlich eine breite Palette an qualitativen Einschränkungen bzw. Forderungen wie beispielsweise Performance und Usability.

Wir gehen nun davon aus, dass nicht alle Aspekte dieser Story innerhalb eines Sprints umgesetzt werden können. Es folgt somit die Notwendigkeit bei dieser Story die Schere ansetzen um sie in kleinere Teile zu zerlegen. Der erste Gedanke den wir uns dazu machten war, was eigentlich die Grundlage zur Schneidung von User Stories ist, bzw. welche Prämisse liegt der Schneidung von User Stories zugrunde?

Einer der Grundpfeiler von Scrum ist, dass jeder Sprint ein „shippable product“ erzeugen muss. Eine der Möglichkeiten dies zu erreichen ist, nur Inkremente zu implementieren die für sich selbst bereits einen Kundennutzen erzeugen. Daraus kann folgende Prämisse für die Schneidung von User Stories abgeleitet werden. Auch nach der Schneidung von User Stories muss ein Kundennutzen erhalten bleiben. Auf diese Art wird gesichert, dass die Kundenakzeptanz einen möglichst hohen Grad erreicht und schnellstmöglich ein „Return of Investment“ erreicht wird. Gleichzeitig wird die Testbarkeit der Inkremente gewahrt, da sie direkt in das bestehende/ zu entwickelnde System integriert werden können.

Das Umsetzen der Eingabemaske in allen Facetten wäre demnach nicht zielführend, denn welchen Nutzen hätte ein User wenn er zwar Suchkriterien wählen kann, aber am Ende kein Ergebnis bekommt, weil es keinen Algorithmus gibt der tatsächlich auf die Suche nach Partnern geht? Umgekehrt gilt dies natürlich genauso. Der tollste Suchalgorithmus bieten keinen Kundennutzen, wenn er nicht gestartet werden kann oder wenn es keine Möglichkeit gibt sich die Ergebnisse anzeigen zu lassen.

Nachdem also eine klare Prämisse aufgestellt ist stellten wir uns folgende Frage: Anhand welcher Aspekte lassen sich User Stories schneiden?

Als Grundlage für unsere Überlegungen diente uns  – wie in Teil I dargestellt – das „Cheat Sheet“. Jeder SOPHIST nahm eines der „Cheat Sheet“-Patterns und versuchte unsere Beispielstory anhand der Patterns und unter Berücksichtigung unserer Prämisse in sinnvolle Einheiten zu zerschneiden. Die Ergebnisse verglichen wir und extrahierten daraus die vier folgenden Schneidungsaspekte:

• User Stories lassen sich anhand der verwendeten Daten schneiden. In unserem Beispiel wären dies u.a. mögliche Eingabeparameter oder die im Algorithmus verwendeten Daten (Alter, Geschlecht, Wohnort etc.).
• Ein weiterer Schneidungsaspekt ist der zugrundeliegende Prozess. Der sich in einzelne Prozessschritte, mögliche Alternativpfade und Ausnahmeverhalten teilen lässt.
• Die dritte Variante zielt auf die nicht-funktionalen Aspekte der User Story ab, was sich in unserem Beispiel in der Performance oder der Stabilität des Algorithmus oder dem Design der Nutzeroberfläche äußert.
• Die vierte und letzte Variante ist die Schneidung anhand der technischen Aspekte der Lösung. Mögliche Vertreter dieses Schneidungsaspektes wären die verwendete Programmiersprache oder das verwendete Datenmodell. Eine Schneidung anhand dieses Aspektes halten wir allerdings nur in Ausnahmesituationen für sinnvoll, da sie nicht den direkten Kundennutzen im Fokus hat.

Nun war uns (einigermaßen) klar – gut, wir hatten eine erste Idee – aufgrund welcher Schneidungsaspekte wir den Schnitt ansetzen könnten – also WIE wir schneiden. Wir verfolgten diesen Weg also weiter. Jetzt galt es noch das WANN und WARUM zu klären. Aufgrund welcher Randbedingungen oder Einflussfaktoren kann man entscheiden welche Aspekte einer Story weggeschnitten werden können und welche nicht, um sie auf ein in einem Sprint umsetzbares Maß zu kürzen und die Prämisse einzuhalten? Oder: Welchen Schneidungsaspekt verwende ich in welcher Situation?

Mit dieser Fragestellung entlasse ich Sie in Ihre Gedankenwelt. Vielleicht haben Sie Lust mögliche Antworten selbst zu finden. Wenn nicht, lesen Sie unsere Folgegedanken und Ergebnisse im nächsten Teil der kleinen (User-) Geschichte.

Fortsetzung folgt…