Haben Sie schon mal ein Kleidungsstück maßschneidern lassen? Dann erinnern Sie sich sicherlich noch an das aufwendige Maßnehmen, bei dem die unterschiedlichsten Maße, Längen und Umfänge sehr genau nachgemessen und fein säuberlich notiert wurden. Schließlich soll das Kleidungsstück hinterher wie angegossen sitzen. Sonst hätte man es ja auch von der Stange kaufen können.

Maßnehmen für perfekt sitzende Software

Mit Software ist das ganz ähnlich. Wenn Sie eine maßgeschneiderte Software in Auftrag geben, möchten Sie, dass sie hinterher wie angegossen sitzt. Aber wem? Häufig weniger Ihnen als Auftraggeber, sondern vor allem den verschiedenen Anwendern, die im Zweifel sehr unterschiedliche Anforderungen und Bedürfnisse haben. Egal, ob diese Anwender Ihre Mitarbeiter sind, die die Software in ihrer täglichen Arbeit einsetzen, oder Ihre Kunden, die die Anwendung vielleicht sogar nur einmal im Jahr brauchen. Entscheidend ist, dass alles passt, und zwar in genau in dem Moment, in dem es gebraucht wird.

Maßgeschneiderte Software soll hinterher wie angegossen sitzen. Aber wem? #softwareentwicklung #userstories #individualsoftware

Deshalb basiert das Schnittmuster für eine individuelle Softwarelösung nicht auf Maßen, Längen und Umfängen, sondern vor allem auf Anwendungsszenarien. Wer benutzt die fertige Software? Mit welchem Ziel? Mit welchen Erwartungen? Wann? Wie oft? An welchem Gerät? Welches Problem soll die Software lösen? Und was ist dabei besonders wichtig?

Erzählen Sie uns eine Geschichte - oder gleich mehrere

Damit die Anwender sich mit der Software rundherum wohl fühlen, ist es wichtig, dass wir vorher ausgiebig darüber reden. Und zwar mit jemandem, der sich mit dem praktischen Einsatz der zu entwickelnden Anwendung richtig gut auskennt und jede Menge Geschichten aus der Anwendungspraxis erzählen kann. In der Regel ist das der Product Owner oder die Produktmanagerin.

Im klassischen Scrum setzt sich der Product Owner direkt mit den Entwicklern zusammen. Das Problem: Die beiden kommen häufig aus völlig unterschiedlichen Welten und sprechen nicht dieselbe Sprache. Mit dem Ergebnis, dass am Ende Informationen fehlen, weil die eine Seite sie als zu selbstverständlich und deshalb nicht erwähnenswert wahrgenommen hat. Oder dass aufgrund sehr unterschiedlicher Sichtweisen Missverständnisse entstehen. Deshalb hat es sich für uns bewährt, in diesen Prozess eine Art Übersetzer einzubauen, der beide Seiten versteht. Unsere Anforderungsmanager*innen haben ein tiefgreifendes technisches Verständnis, fühlen sich aber in der Welt der Geschäftsprozesse und Business-Anforderungen genauso zu Hause. Deshalb sind sie diejenigen, die sich von den Produktverantwortlichen auf Kundenseite die geplante Anwendung, die Unternehmensziele und das technische Umfeld erklären lassen. Und die auf dieser Basis praxisorientierte Anwendungsszenarien bzw. User Stories erstellen, die als Ausgangsbasis für die konkrete Anforderungsanalyse dienen.

Was macht eine richtig gute User Story aus?

Das Schreiben von User Stories ist einer der wichtigsten Schritte bei der Planung, Konzeption und Entwicklung von Software. Die Software-Entwickler können die größten Technik-Cracks sein - ohne ein an den tatsächlichen Anwendungsszenarien ausgerichtetes Konzept ist jede Software in der Praxis zum Scheitern verurteilt. Gute User Stories sind also Gold wert. Aber was macht eine richtig gute User Story eigentlich aus?

Ohne Nutzerorientierung ist auch perfekt programmierte Software zum Scheitern verurteilt. #softwareentwicklung #userstories #individualsoftware

1. Die perfekte User Story schaut durch die Augen der (richtigen) Nutzer.

Eine User Story sollte aus Sicht der User geschrieben sein. So weit, so selbstverständlich (sollte man meinen). Die entscheidende Frage ist aber: Aus der Sicht welcher User? Zu den größten Herausforderungen bei der Erarbeitung von User Stories zählt das Identifizieren der richtigen Nutzer. Wer GENAU nutzt eigentlich das Produkt bzw. eine bestimmte Funktion? Und was ist sein größtes Problem? Häufig gibt es verschiedene Arten von Nutzern - vom Verkäufer über die Managerin oder den Werbetreibenden bis hin zum Kunden. In solchen Fällen lohnt es, verschiedene Perspektiven zu testen und die zu wählen, die für die Gestaltung einer bestimmten Funktion am entscheidendsten ist und sich am “natürlichsten” anfühlt. Sich schließlich in diese Nutzer hineinzuversetzen und ihre Motivation und Anforderungen zu verstehen, ist die wichtigste Voraussetzung für gelungene User Stories.

2. Die perfekte User Story hat genau den richtigen Umfang.

Was gehört eigentlich in diese Story rein? Und welcher Aspekt braucht seine eigene User Story? Wenn eine Story zu viele unterschiedliche Aspekte enthält, wird sie sehr komplex und ihre Umsetzung dauert lange. Damit steigt auch die Gefahr für Fehlentwicklungen und Zeitverzug. Sind verschiedene miteinander verknüpfte Stories dagegen zu kleinteilig aufgeteilt, kann man wiederum leicht die übergeordnete Zielrichtung aus dem Blick verlieren und der Projektmanagementaufwand steigt. Von Kreuzverweisen und sich gegenseitig bedingenden Zusammenhängen ganz zu schweigen. Ein entscheidender Schritt ist also direkt zu Beginn die Definition, Abgrenzung und Aufteilung verschiedener Anwendungsszenarien in die richtige Anzahl User Stories. Bei einem sehr überschaubaren Feature kann eine einzelne User Story schon ausreichen. Für umfangreichere Projekte müssen es manchmal aber auch mehrere Dutzend sein. Grundsätzlich sollte eine User Story immer für sich alleine stehen können und sich unabhängig umsetzen und an die Anwender ausliefern lassen.

3. Die perfekte User Story erzählt die relevantesten Geschichten.

Wie häufig kommt die in der Story erzählte Situation eigentlich vor? Die relevantesten Anwendungsszenarien zu finden und sie gemeinsam mit dem Kunden zu priorisieren, gehört ebenfalls zu den entscheidenden Aufgaben im Anforderungsmanagement. Wir erzählen nur User Stories mit einer starken Motivation, und angefangen wird mit den wichtigsten Szenarien. Was nur alle Jubeljahre mal gebraucht wird, lässt sich auch noch zu einem späteren Zeitpunkt ergänzen.

4. Die perfekte User Story ist so präzise wie möglich und so umfangreich wie nötig.

Am Ende des Tages sollte eine User Story alle Informationen enthalten, die für die technische Umsetzung gebraucht werden. Sie sollte aber auch nicht mit irrelevanten Informationen überfrachtet sein. Was das für die Länge konkret bedeutet, ist von Story zu Story sehr unterschiedlich. Manche lassen sich in wenigen Absätzen relativ knapp erklären, manche brauchen mehrere Seiten mit vielen Details. Eine gute Methode kann es auch sein, am Anfang der Entstehung erstmal mit groben Ideen zu starten, die in Mindmaps strukturiert und dann im Laufe des Projekts gemeinsam verfeinert werden. Zu Beginn der technischen Umsetzung muss jede User Story so detailliert sein, dass die Softwareentwickler daraus konkrete Tasks ableiten können.

5. Die perfekte User Story trennt Funktion und Technik.

Stellen Sie sich vor, Sie haben einen Handwerker im Haus und bitten ihn, einen Nagel in die Wand zu schlagen, damit Sie ein Bild aufhängen können. Nagel rein, Bild dran - fertig. Alles gut. Soweit.

Nun stellen Sie sich vor, Sie formulieren Ihre Bitte anders: “Als Kunstliebhaber möchte ich, dass mein Bild so an der Wand angebracht wird, dass ich es betrachten kann.” Wird dabei dasselbe Ergebnis herauskommen? Vielleicht. Vielleicht weiß der Handwerker aber auch noch einige andere Möglichkeiten, wie man ein Bild an die Wand bringen kann:

  • Möglicherweise gibt es an der entsprechenden Stelle bereits ein Sims, auf das man das Bild nur draufstellen muss. Ohne jeden Aufwand.

  • Vielleicht stellen Sie im gemeinsamen Gespräch fest, dass Sie Bilder gerne regelmäßig austauschen? Dann bietet sich vermutlich das Anbringen einer Bilderleiste an, weil es Ihnen langfristig mehr Flexibilität bietet, auch wenn es im ersten Schritt deutlich aufwendiger ist.

  • Eventuell leben Sie auf einem Schiff und es gibt oft Seegang. Dann schraubt der Handwerker das Bild besser fest an die Wand.

  • Oder es gibt kein Sims, keinen Seegang und es wird auch nicht oft umdekoriert. Dann nehmen wir doch den Nagel. Einfach, schnell und kostengünstig

Nur indem die Anforderung ohne technologische Vorgaben formuliert wird, wird es möglich, die für dieses spezielle Anwendungsszenario beste und passendste Lösung zu finden. Und wenn Sie dann auch noch nicht einfach einen Handwerker, sondern einen erfahrenen Galeristen befragen, können Sie sicher sein, dass die gewählte Methode nicht nur die beste für Ihre spezielle Situation ist, sondern auch in der Praxis langfristig funktioniert - und sich bei Bedarf entsprechend anpassen lässt.

Sind Hammer und Nagel die einzige Möglichkeit, ein Bild aufzuhängen? Warum User Stories ohne Technikvorgaben so wertvoll sind. #softwareentwicklung #userstories #individualsoftware

Und wenn die Stories fertig sind?

Weil bei ihnen das fachliche und das technische Verständnis zusammenlaufen und wir unsere Kunden so weit wie möglich entlasten, ist das Schreiben der User Stories eine Aufgabe für unsere Anwendungsmanager*innen. Bevor das Entwicklerteam an die Arbeit geht, werden alle User Stories aber natürlich vom Produktmanager oder von der Produktmanagerin des Kunden abgenommen.

Die User Stories sind also ein zentrales Dokument für alle Projektbeteiligten. Und sie bleiben auch dann noch wichtig, wenn das Entwicklerteam daraus die technische Planung mit konkreten Tasks abgeleitet hat.

Die Stories sind nämlich die perfekte Grundlage, um im Testing festzustellen, ob die Umsetzung auch das darin beschriebene gewünschte Resultat erzielt. Und auch um zu verstehen, warum bereits umgesetzte Features in genau dieser Form und nicht anders umgesetzt wurden, lohnt sich ein Blick in die User Stories, die so zum Teil der Projekt- oder Produktdokumentation werden.

Keine Software ohne Geschichten

Zur Softwareentwicklung gehören User Stories unverzichtbar mit dazu. Nur wer weiß, was die Nutzerinnen und Nutzer einer Software in der Praxis brauchen, vor welchen Herausforderungen sie stehen, welche Probleme sie lösen müssen und welche Anforderungen sie dabei im Detail an das verwendete Werkzeug haben, kann eine Software bauen, die das Leben ihrer Nutzer*innen leichter macht. Und nur solche Software lohnt es sich letzten Endes zu bauen. Finden wir.

Software zu bauen, lohnt sich nur dann, wenn sie das Leben ihrer Nutzer*innen leichter macht. #softwareentwicklung #userstories