Mit der Verbreitung agiler Vorgehensweisen in IT-Projekten stellt sich immer häufiger auch die Frage, auf welche Weise Anforderungen am besten beschrieben werden sollten. Vor allem die sog. "User Stories", in welchen Anforderungen aus Sicht des Nutzers beschrieben werden, erfreuen sich dabei steigender Beliebtheit: Sie haben einen klaren, einfachen Aufbau und konzentrieren sich auf die wesentlichen Elemente einer Anforderung.

Eine User Story darf inhaltlich nur so komplex sein, dass sie innerhalb eines Sprints umgesetzt werden kann und am Ende des Sprints dem Kunden – oder dem Product Owner, der die Kundensicht einnimmt – ein abnahmefähiges Teilprodukt gezeigt werden kann.

Im Artikel "Agile Softwareentwicklung mit Scrum und User Stories" (Projekt Magazin 02/2010) haben Sie erfahren, wie User Stories grundsätzlich aufgebaut sind und wie sich die Anforderungen eines Scrum-Projekts durch User Stories beschreiben, priorisieren und abarbeiten lassen.

Ergänzend hierzu sollten Sie bei der Konzeption von User Stories einiges beachten. Auch müssen die entsprechenden Rahmenbedingungen im Unternehmen geschaffen werden, damit die Software-Entwicklung mit dieser Vorgehensweise erfolgreich ist.

In diesem Artikel erfahren Sie,

• was eine User Story ist,
• warum es sinnvoll ist, mit User Stories zu arbeiten,
• welche formalen und strukturellen "Stolpersteine" es bei der Konzeption von User Stories gibt und
• wie Sie diese umgehen können.

Was ist eine User Story?

Ende der 90er Jahre arbeiteten die Software-Entwickler Ron Jeffries und Kent Beck in einem Projekt zur Entwicklung einer Gehaltsabrechnungssoftware bei Chrysler. Für die Softwareentwicklung nutzten sie die Methode XP (Extreme Programming) und verwendeten erstmals für die Beschreibung der Anforderungen User Stories, die Funktionalitäten der Software aus Anwendersicht und in einfachen Worten darstellten. So stellten sie sicher, dass die entwickelte Software auch wirklich den Anforderungen der Anwender entsprach.

Die Realisierung einer User Story besteht aus folgenden drei Elementen:

1. Die Anforderung wird in einfacher Form auf einer Indexkarte festgehalten (Card):
2. Als <Nutzerrolle> will ich <das Ziel>, sodass <Grund für das Ziel>.
3. Beispiel:
4. "Als Kunde eines Online-Shops kann ich meine Bankverbindung in meinem Profil abspeichern, sodass ich diese bei einer weiteren Bestellung nicht erneut eingeben muss."
5. Das Entwicklungsteam stimmt sich direkt mit dem Anforderungssteller – oder dem Vertreter des Anforderungsstellers, d.h. dem Product Owner – ab. Die Details einer User Story werden in einer gemeinsamen Diskussion kurz vor Beginn der nächsten Iteration, d.h. des nächsten Entwicklungsabschnitts, geklärt (Conversation).
6. Jede User Story beinhaltet Testfälle, die sog. "Akzeptanzkriterien", die genau beschreiben, wie die Funktionalität nach der Umsetzung der User Story durch die Entwickler funktionieren soll (Confirmation).
7. Beispiel:
8. "Wenn die Bankleitzahl weniger als neun Ziffern enthält, führende Nullen oder Buchstaben eingegeben werden, gibt das System eine Fehlermeldung aus.
9. Die Kontonummer kann bis zu zehn Stellen umfassen und darf nur Ziffern beinhalten; führende Nullen sind erlaubt …"

Warum User Stories sinnvoll sind

Die Firma cyclespeed24 konnte in der Vergangenheit ihre Software-Entwicklungsprojekte nicht immer erfolgreich abschließen. Sie wurden zwar häufig "in time" und "in budget" beendet, aber die entwickelten Features entsprachen nicht den Erwartungen der Anwender in den Fachbereichen. Dies erschwerte die Akzeptanz dieser Anwendungen durch die Fachbereiche und mit dem Image der IT-Abteilung war es innerhalb des Unternehmens auch nicht zum Besten bestellt.

Da die interne Entwicklungsmannschaft die größeren Projekte häufig nicht alleine umsetzen konnte, wurden mit einem externen Dienstleister Werkverträge zu Festpreisen geschlossen. Die Anforderungen so zu beschreiben, dass sie eine juristisch verwertbare Grundlage für den Werkvertrag bildeten, bedeutete erhebliche Aufwände für die anfordernden Fachbereiche, war aber Voraussetzung dafür, dass ein Projekt überhaupt genehmigt und ausgeschrieben werden konnte.

Die erstellten Lastenhefte nahmen schon einmal 200 Seiten und mehr ein. Sie enthielten alle denkbaren Anforderungen an das System, ohne dass jeweils eine Aufwand-Nutzen-Betrachtung erfolgt wäre, und damit auch jede Menge unnötige Funktionalitäten. Die Begeisterung (und in der Folge das Engagement) der Mitarbeiter, die sich in der Vor-Projekt-Phase in der korrekten Abwicklung ihres Tagesgeschäfts beeinträchtigt sahen, fiel entsprechend gering aus.