Agile Softwareentwicklung mit Scrum und User Stories

Das agile Vorgehensmodell Scrum erfreut sich in der Softwareentwicklung zunehmender Beliebtheit, da es ein einfaches und flexibles Vorgehen erlaubt. Allerdings gibt es in Scrum keine Vorgaben, wie Anforderungen von Anwendern erfasst und spezifiziert werden sollen. Ein etablierter Weg dafür ist die Verwendung von User Stories. Ralf Wirdemann erklärt, wie User Stories funktionieren und wie sich die Anforderungen eines Scrum-Projekts mit Hilfe von User Stories beschreiben und verwalten lassen.

Agile Softwareentwicklung mit Scrum und User Stories

Das agile Vorgehensmodell Scrum erfreut sich in der Softwareentwicklung zunehmender Beliebtheit, da es ein einfaches und flexibles Vorgehen erlaubt. Allerdings gibt es in Scrum keine Vorgaben, wie Anforderungen von Anwendern erfasst und spezifiziert werden sollen. Ein etablierter Weg dafür ist die Verwendung von User Stories. Ralf Wirdemann erklärt, wie User Stories funktionieren und wie sich die Anforderungen eines Scrum-Projekts mit Hilfe von User Stories beschreiben und verwalten lassen.

Das Vorgehensmodell Scrum erfreut sich durch wenige Regeln und klare Verantwortlichkeiten in der Softwareentwicklung zunehmender Beliebtheit. So erlaubt Scrum ein einfaches und flexibles Vorgehen – wie die Beteiligten den Entwicklungsprozess gestalten und organisieren, bleibt ihnen selbst überlassen. (Siehe auch "Agiles Projektmanagement. Scrum – eine Einführung", Projekt Magazin, Ausgabe 21/2009.)

Allerdings enthält Scrum keine konkreten Vorgaben, wie die Anforderungen an die zu entwickelnde Software erfasst und spezifiziert werden sollen. Die agile Softwareentwicklung verfolgt jedoch den Ansatz, die Anforderungen auf eine Art und Weise zu beschreiben, die es dem Entwicklungsteam ermöglicht, nach jedem Sprint nutzbare Software für den Kunden zu liefern.

Ein etablierter Weg, dies zu tun, ist die Verwendung von User Stories. Dabei handelt es sich um einfache Formulierungen der Anforderungen aus Sicht des späteren Anwenders. Dieser Artikel beschreibt, wie man die Anforderungen eines Scrum-Projekts mit Hilfe von User Stories beschreiben und verwalten kann.

Praxisbeispiel

Zum besseren Verständnis soll das Prinzip der User Stories innerhalb eines Scrum-Projekts am Beispiel eines webbasierten Job-Portals erläutert werden: Eine Gruppe von Investoren möchte ein Portal für die Stellenvermittlung im High Professional-Umfeld entwickeln, das Firmen und Recruitern Zugriff auf nachgewiesen hoch qualifiziertes Fachpersonal ermöglichen soll. Im Gegenzug bietet das Portal Job-Suchenden die Möglichkeit, Kontakte zu renommierten und interessanten Arbeitgebern aufzubauen.

Ein Auszug aus der zentralen Anforderungsliste des Job-Portals, dem sog. Product Backlog, könnte wie folgt aussehen:

  • Datenbankmodell entwerfen
  • OR-Mapping-Framework (Mapping zwischen den Objekten des Systems und der unterliegenden relationalen Datenbank) entwickeln
  • User Interface für die Job-Suche entwerfen
  • Security Framework (Authentifizierung und Autorisierung von Nutzern) implementieren
  • Suchmaschine entwickeln und integrieren
  • ...

Das Problem: Scrum enthält keine Spezifikation der Anforderungen

Das Product Backlog in Scrum ist eine priorisierte Liste mit sämtlichen Anforderungen des Projekts. Die Einträge im Backlog werden als Backlog Items bezeichnet. Für jeden Eintrag liegt eine Schätzung des Aufwands vor; die Priorität des Eintrags bestimmt seine Position in der Liste. Während Scrum zwar mit dem Product Backlog sehr genau vorgibt, wie und womit Anforderungen verwaltet werden, trifft es keinerlei Aussagen darüber, wie die einzelnen Einträge des Backlogs formell genau auszusehen haben. Von "Die Software muss in Java programmiert werden" bis hin zu nicht-funktionalen Anforderungen, wie "Die Applikation muss skalierbar sein" ist alles erlaubt, was irgendwie getan werden muss.

Beide Beispiele sind notwendige Anforderungen, liefern aber keinen offensichtlichen Mehrwert für die Nutzer der Anwendung. Und darum geht es schließlich bei Scrum – der Entwicklung und regelmäßigen Auslieferung von nutzbarer Software für den Kunden. Entsprechend sollte das Product Backlog nur Einträge enthalten, die einen klar ersichtlichen Wert für die späteren Nutzer der Anwendung liefern. Hier hat der Product Owner die Aufgabe, ein Backlog zu erstellen, das diesen Kriterien genügt.

Ein Beispiel für Anforderungen ohne praktische Funktion für den Nutzer ist das oben genannte Backlog Item "OR-Mapping-Framework entwickeln". Die Entwicklung eines solchen OR-Mappers ist sinnvoll und notwendig, nur bietet der OR-Mapper für sich allein genommen keinerlei Mehrwert für die späteren Anwender des Portals. Entsprechend schwierig ist es für den Product Owner, der ja die Sicht des Kunden repräsentiert, dieses Backlog Item im Verhältnis zu den anderen Anforderungen im Sinne des Geschäftswerts zu priorisieren. Der Begriff Geschäftswert beschreibt in diesem Zusammenhang den Wert, den ein neues Feature für das Geschäftsfeld liefert, für das die Software entwickelt werden soll. Dieses kundenorientierte Anforderungsmanagement zielt folglich auf die regelmäßige Produktion und Lieferung von Features mit dem größtmöglichen Geschäftswert ab.

Die Lösung: User Stories im Kontext von Scrum

User Stories sind ein Werkzeug der agilen Softwareentwicklung, mit dem sich Software-Anforderungen kurz und prägnant aus Sicht des Nutzers beschreiben lassen. Viele Teams in der Softwareentwicklung setzen aktuell auf Scrum, so dass sich ein genauerer Blick auf die Verwendung von User Stories im Kontext von Scrum lohnt.

Ein wichtiges Prinzip von Scrum ist, dass die Auftraggeber regelmäßig in kurzen Abständen die aktuelle Version der Software zu sehen bekommen, um möglichst früh Kurskorrekturen vornehmen zu können. Deshalb muss der Product Owner die wichtigsten Anforderungen so früh wie möglich vom Team umsetzen lassen, um dem Kunden funktionsfähige Software präsentieren zu können. Damit diese relevanten Anforderungen auch hoch priorisiert werden, eignen sich User Stories, da sie für den Product Owner sehr viel greifbarer sind und sich gegeneinander abwiegen lassen.

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 5
Comments 3

Alle Kommentare

Michael
Heinrichowski
Dr.
Vermutlich nur für Kollegen ohne IT-Hintergrund schwer zu verstehen und noch schwerer zu adaptieren.
Christian
Cartus
Dipl.-Ing.
@Michael: Dem kann ich zustimmen. Während eines Workshops habe ich kurz über Agile Methoden und eben SCRUM referiert. Für die Teilnehmer aus einem Nicht-IT-Umfeld war diese Vorgehensweise völlig absurd. Teilnehmer aus dem IT-Umfeld konnten sich schon eher
Markus
Puttlitz
Dr.
Sehr hilfreich!
Alle anzeigen