Jedes Projekt wird begonnen, um ein oder mehrere Ziele zu erreichen. Diese Ziele sind anfangs meist noch unscharf und es ist nicht klar, ob sie alle umsetzbar sind, ob es überhaupt sinnvoll ist, sie alle umzusetzen und ob einzelne Ziele an aktuelle Gegebenheiten angepasst werden sollten. Je weiter die Projektplanung und -umsetzung voranschreitet, desto klarer werden diese Details. Das passiert bei komplexeren Projekten eigentlich immer. In konventionell geplanten und durchgeführten Projekten ist dann meist eine Krise oder ein großer Knall und eine Rückkehr zum “Reißbrett” nötig, um dieser notwendigen Änderungen Rechnung zu tragen.

Agile Projekte erklären diese Krise von vornherein zur Norm. Neue Erkenntnisse sollen eine Stärke sein, keine Störung. Von niemandem soll verlangt werden, alle Details von Anfang an festlegen zu können. Das verlangt nach einer anderen Herangehensweise, die wir als agiles Projektmanagement oder agile Produktentwicklung bezeichnen – im Gegensatz zu konventionellen, starren Vorgehensweisen.

Pflichtenheft?

Innerhalb eines agilen Projekts können wir daher auch nicht viel anfangen mit einem dicken Pflichtenheft welches versucht, von vornherein jedes Detail unseres Projekts zu klären. Und mal ehrlich: nach der 20. Änderung liest niemand mehr ein Pflichtenheft. Zumindest nicht ohne Augenrollen.

Was tun?

Wir müssen – und können – uns also den Projektzielen anders nähern. Die genaue Vorgehensweise ist Subjekt zahlreicher Diskussionen und philosophischer Betrachtungen.  Sie hängt außerdem von einer Reihe von Faktoren ab, vor allem von den zu erreichenden Zielen und den Prozessen im Unternehmen. Und gerade diese Prozesse sind nötig, Ziele und den Weg dorthin hervorzubringen. Ein Unternehmen kann daher nur effizient agil arbeiten, wenn es die agile Vorgehensweise wirklich annimmt und in seine Prozesse integriert.

Ein Lastenheft enthält traditionell die Ziele, also WAS wir erreichen wollen. Ein Pflichtenheft ist eine Beschreibung des Weges, also WIE wir zu den Zielen kommen wollen. Diese strikte Trennung wird im agilen Projekt teilweise aufgehoben. Die Requirements werden in kleinen Happen verfasst, die unterschiedlich bezeichnet werden. Ich nennen sie hier einfach “User Stories” und dieser Name deutet schon auf den Inhalt hin: eine möglichst genaue Beschreibung des WAS. Dazu können wir, wenn nötig, auch beschreiben, WIE wir zum jeweiligen Ziel kommen wollen oder es den Experten überlassen.

So könnten wir dem Koch zum Beispiel beschreiben, dass wir eine Kürbissuppe essen wollen und es ihm selbst überlassen, wie er sie zubereitet. Schließlich ist er ein guter Koch! Oder aber wir stellen sicher, dass die Kürbisstücke vorher angebraten werden, indem wir das so definieren. Es muss aber klar sein, dass wir das Potenzial des Kochs mehr und mehr beschränken, wenn wir ihm immer detaillierter vorschreiben, wie er kochen soll. Schmeckt die Suppe am Ende nicht, ist fraglich, wer das zu verantworten hat, weil ja zu viele Köche Brei und Suppe verderben.

Aufbau einer User Story

Eine User Story besteht aus drei Teilen:

  1. Der Betreff beschreibt kurz und prägnant den Inhalt der Story. Es ist wichtig, dass man beim Lesen des Betreffs sofort versteht, worum es geht. Das wird später das Wiedererkennen und Sortieren der Stories möglich machen.
  2. Die Beschreibung soll den Entwickler “abholen” und den Inhalt der Story in den Kontext des Projekts stellen. Sie ist immer gleich formuliert und nennt die Rolle des Anfordernden, eine Beschreibung der Anforderung und ein Ziel, was damit erreicht werden soll.
  3. Die Akzeptanzkriterien beschreiben die einzelnen Eigenschaften und werden bei der Qualitätssicherung nacheinander abgehakt.

Zusätzlich bekommen Stories in den meistens Verwaltungssystemen auch eine eindeutige Nummer.

Ein Beispiel: ich möchte eine leicht scharfe, herbstliche Kürbissuppe essen.

Beschreibung: Als Restaurantbesucher möchte ich eine leicht scharfe, herbstliche Kürbissuppe essen, damit ich danach satt bin und mir das nasskalte Wetter nichts mehr ausmacht.

Akzeptanzkriterien:

  • Gekocht wird eine pürierte Kürbissuppe mit Stücken
  • Die Stücke werden vor dem Ablöschen angebraten
  • Die Schärfe soll zwischen 100 und 500 der Scoville-Skala liegen
  • Es sollen mindestens zwei Portionen herauskommen
  • Die Kosten pro Portion sollen 5 Euro nicht überschreiten

Die prosaische Qualität der Formulierungen ist hierbei unerheblich. Wichtig ist, dass die Anforderungen eindeutig und auch im Kontext stimmig sind. Der Entwickler soll wissen, was er tun soll und möglichst nicht selbst recherchieren, nachfragen oder gar entscheiden müssen, WAS zu tun ist. Diese Klarheit erfordert vom Verfasser der User Story einiges an Disziplin. Je mehr Gedanken wir uns über die Formulierungen machen, desto näher werden wir dieser Anforderung kommen.

Oft werden wir dabei auf Probleme stoßen, die wir bisher nicht bedacht haben und die uns später bei der Umsetzung auf die Füße gefallen wären. Und wer nicht genau weiß, was er erreichen will, hat wenig Chancen, es zu bekommen. Die Inhalte der User Stories werden auch maßgeblich von des Reviews vergangener Sprints beeinflusst, denn das ist ja gerade die Essenz der agilen Vorgehensweise.

Kurz und aufgereiht

Außerdem ist es wichtig, dass eine User Story nicht zu viel Inhalt hat und vom Entwickler schnell abgearbeitet werden kann. Lieber teilen wir eine Funktion in mehrere Stories auf, die aufeinander aufbauen und so kurz wie irgendwie möglich sind. Wie gut sich das machen lässt, hängt vor allem von der Art des Projekts ab. Stories können sich also aufeinander beziehen (“Wird der rote Knopf aus Story XY gedrückt, passiert dies und das”) und sie können als Gruppe unter einer Überschrift zusammengefasst werden. Manche Systeme zur Verwaltung von User Stories erlauben auch eine hierarchische Gliederung. Da Stories aber nacheinander abgearbeitet werden, halte ich davon wenig und rate zur Vorsicht. Eine Verschlagwortung (“Tagging”) bietet jedes System und damit kann man genauso gut die Übersicht behalten ohne die Dinge unnötig zu verkomplizieren.

Von der Idee zur User Story

An dieser Stelle möchte ich auf den Weg von der ersten Idee zur ersten User Story eingehen. Wie auch der Rest der agilen Vorgehensweise hängt dieser von vielen Faktoren ab und es ist schwer einen generellen Ratschlag zu erteilen. Sicher ist aber, dass eine ganze Reihe von Dokumenten entstehen werden, bevor die erste User Story geschrieben werden kann. Je nach Projektinhalt kann das eine Beschreibung der Infrastruktur sein oder eine Festlegung einer Systemarchitektur. Es können Produktvisionen entworfen werden, Prototypen, Klick-Dummies oder Feature-Listen, Risikobewertungen und Listen mit offenen Fragen. Lassen Sie Ihrer Fantasie hier freien Lauf und bringen Sie zu Papier, was auch immer aus Ihnen heraus will.

Die Projektkultur eines Unternehmens, eben jene Prozesse, von denen wir am Anfang gesprochen haben, muss hierfür Sorge tragen. User Stories werden auch immer wieder auf solche Dokumente verweisen aber es ist wichtig, dass wir sehr gründlich darüber nachdenken, welche Information wohin soll. User Stories sind kein Platz für Fragen oder Ideen. Sie müssen unmissverständliche Anweisungen enthalten. Alle Unklarheiten müssen in den Prozessen vorher geklärt worden sein.

Das Backlog

In agilen Projekten nennen wir die Sammlung aller User Stories den “Backlog”. Dieser ist eine Liste aller Stories, die nach ihrer zeitlichen Priorität sortiert ist. Wenn wir einen Agile-Zyklus (Sprint) planen, nehmen wir uns vor, eine bestimmte Anzahl von Stories aus dem Backlog innerhalb des Sprints zu bearbeiten. Ist am Ende des Sprints noch Zeit übrig, können wir weitere Stories aus dem Backlog aussuchen. Im Idealfall einfach jeweils die erste. Es ist also wichtig, dass Stories an der Spitze des Backlogs möglichst bereit sind für eine Umsetzung. Es spricht aber nichts dagegen, den Backlog dafür zu verwenden, auch erste Ideen schon mal festzuhalten und diese dann nach und nach zu schärfen, umzuschreiben und zu ergänzen oder aufzuteilen. Schließlich arbeiten wir deshalb ja agil und wollen nicht alles gleich von Anfang an festlegen.

Wichtig ist, dass wir dabei aufpassen, keine unfertigen Stories in den Sprint gelangen zu lassen. Oder aber wir lassen Stories in Begleitdokumenten entstehen und nehmen sie erst in den offiziellen Backlog auf, wenn sie soweit sind. Das ist eine Frage der Kultur und der Prozesse. Eine ständige Auseinandersetzung mit den Inhalten des Backlog (genannt “Backlog-Grooming”) ist daher unerlässlich und ein wichtiger Teil des agilen Prozesses. Das Team überprüft die Stories, diskutiert und schätzt sie und plant Ressourcen zu ihrer Umsetzung ein. Auch Wechselwirkungen mit anderen Teilprojekten oder dem Unternehmen sind zu berücksichtigen und ggf. bei der Konzeption zu beachten.

Systeme zur Verwaltung von Stories

Theoretisch kann man User Stories, Backlog und auch Sprints mit Papierkarten und Pinwänden verwalten. Wenn man aber mehr als eine Kürbissuppe entwickeln will, wird das schnell unübersichtlich. Auch ist es möglich, einzelne Textdokumente zu verwalten aber auch hier kommt man schnell an Grenzen, wenn man zum Beispiel ein verteiltes Team hat oder regelmäßig Statistiken erstellen möchte. Aufgrund dieser erweiterten Anforderungen hat sich eine Reihe verschiedener Software-Systeme zur Verwaltung von agilen Projekten am Markt etabliert, die sich meistens auf ein bestimmtes Einsatzszenario spezialisiert haben. Manche Systeme sind gut für kleine Projekte, manche für große. Fast alle haben Spezialfunktionen für Software-Entwicklung, weil Agile hier seine Wurzeln hat und einige können regulatorische Anforderungen erfüllen, die zum Beispiel in der Medizintechnik eine Rolle spielen.

Fast alle Systeme bieten außerdem jederzeit einen sehr guten Überblick über den Fortschritt des Projekts und des laufenden Sprints, den Umfang des Backlogs oder einzelner Funktionen darin und die bisher aufgewendete Zeit für einzelne Stories, den Sprint oder das ganze Projekt. Selten muss man noch etwas aufsummieren, meist können Berichte wie der beliebte Burn-Down-Chart jederzeit einfach abgerufen werden. Auch Product Owner, Abteilungs- und Geschäftsleitung können sich jederzeit live ein Bild des Projektstandes machen, ohne den Projektleiter oder Scrum Master jedes Mal um eine aufwendige Zusammenfassung bitten zu müssen.

Einige der Systeme sind als freie oder quelloffene Software erhältlich, andere gibt es nur gegen Bezahlung. Es finden sich Systeme, die man selbst betreibt oder aber Saas-Systeme (Software as a Service), die man in der Cloud mieten kann. Einige dieser Systeme werden wir in weiteren Beiträgen kurz vorstellen.

Zusammenfassung

Wir haben in diesem Beitrag also einige Faktoren kennengelernt, die das Arbeiten mit Requirements und User Stories beeinflussen. Während hier jedes Unternehmen und jedes Projekt seinen eigenen Weg finden muss, können Sie sich mit den genannten Ideen vielleicht den einen oder anderen Irrweg ersparen. Und natürlich helfen wir Ihnen jederzeit gerne bei der Etablierung eines entsprechenden Projektumfeldes oder bei der Schulung eines zukünftigen Projektteams anhand konkreter Beispiele und im direkten Gespräch.

Autor: Nico Nabholz – unser Experte für Agile Requirements bei proaquila

Haben wir Ihr Interesse geweckt? Wünschen Sie sich mehr Informationen über dieses oder ein anderes Thema?