Dies ist der Beginn… Nein, nicht einer wunderbaren Freundschaft, sondern einer kleinen Geschichte aus dem Innenleben von SOPHIST. Es geht dabei um „schöne“, „gute“, „weniger schöne oder gute“ User Stories – bekannt aus Scrum.
Eine Erzählung in drei Teilen. Ob das Ganze gut ausgeht, wird an dieser Stelle noch nicht verraten.

Die agile Softwareentwicklung ist in den letzten Jahren stark auf dem Vormarsch. In nahezu jeder Branche wird mittlerweile agil, halbagil, teilagil, etc. entwickelt, wobei Scrum das wohl am weitesten verbreitete „Vorgehen“ ist – jedenfalls nach unserer Erfahrung.

Über viele Aspekte von Scrum gibt es ausreichend Literatur die aufzeigt wie man verschiedene Problemstellungen während einer scrumartigen Entwicklung lösen kann. Der für uns wichtigste und kritischste Aspekt wird jedoch nicht hinreichend untersucht bzw. beschrieben. Es geht hierbei natürlich um das Stichwort der Anforderungen. Über die Analyse der fachlichen Hintergründe schweigt sich der Scrumansatz aus. Es gibt zwar User Stories, die in einem Product-Backlog landen sowie Vorschläge wie diese User Stories zu formulieren sind, für die tägliche Arbeit damit reicht dies jedoch nicht aus, so unsere Wahrnehmung bei den Kunden sowie unser provokativer Ausgangspunkt. Die weitaus interessanteren Folgefragen lauten,  wie diese User Stories – oder allgemeiner gesprochen Backlog-Items – definiert und ggf. zerlegt werden. Welche Kriterien gibt es für einen guten oder weniger guten User Story-Schnitt? Diese Aspekte werden nicht oder nicht ausreichend besprochen, um den Umgang mit User Stories in der Praxis sinnvoll zu gestalten.

Auch deshalb tritt immer wieder die Frage auf, wie User Stories geschnitten werden sollen bzw. gestaltet werden sollen damit sie in den Sprint passen – also die richtige „Größe“ besitzen.

Es gibt Quellen, wie z. B. das vielzitierte „Cheat Sheet“ („Patterns for Splitting User Stories“ von Richard Lawrence, siehe www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/), oder das INVEST-Prinzip von Bill Wake (siehe: xp123.com/articles/invest-in-good-stories-and-smart-tasks/) die mögliche Ansätze zur Definition und zum Zerschneiden von User Stories aufzeigen. Als wir diese Ansätze eingesetzt haben zeigte sich, dass wir damit gute Basiskonzepte vorliegen hatten. Jedoch blieben auch einige Fragen offen, deren Beantwortung wir für die konkrete Arbeit im Projekt als wichtig erachten:

• Unter welchen Rand-/Rahmenbedingungen schneide ich eine User Story nach welchen konkreten Kriterien? Sprich: Wann ist ein bestimmter Schnitt sinnvoll und wann nicht?
• Wie können wir dies so verständlich beschreiben, dass es Projektbeteiligten nachvollziehbar und verständlich vermittelbar ist? Lassen sich also noch konkretere Prinzipien ableiten, als bereits in „Cheat Sheet“ und INVEST-Prinzip beschrieben? Geht das noch praxistauglicher?

Dabei stützten wir uns auf das „Cheat Sheet“. Die Patterns darin gingen uns nicht weit genug – so jedenfalls die Ausgangsthese.  Evtl. könnten wir daraus die von uns gedanklich geforderten Kriterien und Prinzipien ableiten – falls es diese geben sollte.

Dies war der Startpunkt unseres Versuches. Wir versuchten die im “Cheat Sheet“ beschriebenen Patterns unter gegebenen Randbedingungen anzuwenden und das jeweilige Ergebnis zu bewerten. Wie der Versuch ausging, ob wir tatsächlich verwertbare Ergebnisse/Erkenntnisse ermitteln konnten folgt im nächsten Teil der kleinen (User-) Geschichte.

Fortsetzung folgt…