Der Beginn eines Happy Ends: Initialer Anforderungs-Workshop für erfolgreiche Projekte

Bevor Auftraggeber und Dienstleister in die Realisierung eines Software-Entwicklungsprojekts einsteigen, ist es wichtig, dass sich beide Parteien darüber im Klaren sind, ob sie tatsächlich das gleiche gemeinsame Ziel vor Augen haben. Ein Anforderungs-Workshops bietet die Möglichkeit, das Ziel der Reise in Form einer Produktvision sowie die einzelnen notwendigen Schritte (User-Stories), die in der Gesamtheit den Product Backlog bilden, zu bestimmen.

Um es mit Ken Schwabers Worten zu sagen :

The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is. (Schwaber 2004, p. 68)

Den meisten Dienstleistern dürfte die Situation bekannt sein, dass man eine Anfrage für ein Angebot auf Basis einer groben Projektbeschreibung erhält. Kunde und Dienstleister sind in dieser Situation schlecht beraten, wenn ein Angebot erstellt wird, ohne in einem persönlichen Treffen das gemeinsame Ziel herausgearbeitet zu haben und zu einem gemeinsamen Verständnis des Projekts gekommen zu sein.

Die Folge ist in der Regel, dass es bei der Angebotskalkulation aus nachvollziehbaren Gründen zu einer falschen Interpretation der Beschreibung im Spezifikationsdokument kommt, das Angebot deckt die Anforderungen des Kunden nicht wirklich ab. In der Konsequenz startet das Projekt auf der Grundlage falscher Annahmen und wird wahrscheinlich auf eine Enttäuschung hinauslaufen, die Frage ist nur, welche der beiden Parteien am Ende als Verlierer dasteht.

Ein schlechter Start in ein Projekt ist mit einem Anforderungs-Workshop vermeidbar, und selbst, wenn sich herausstellen sollte, dass das geplante Projekt nicht sinnvoll gemeinsam umgesetzt werden kann, erzielt man im Workshop wertvolle Erkenntnisse und Arbeitsergebnisse, die weiterverwendet werden können. Wie ein solcher Anforderungs-Workshop ablaufen kann, soll nachfolgend beschrieben werden.

Schritt 1: Den Blick auf das Wesentliche richten – Die Produktvision

Zunächst ist es wichtig, ein gemeinsames Verständnis für das Ziel des Projekts zu entwickeln. Festgehalten wird dieses in der Produktvision, die den Projektbeteiligten hilft, während des Projekts gemeinsam in die gleiche Richtung zu steuern. Um eine griffige Produktvision zu formulieren, ist es hilfreich, Antworten auf die folgenden Fragen zu finden (siehe Scrum Alliance – Product vision):

  1. Wer soll das Produkt kaufen bzw. nutzen? Wer bildet die Zielgruppe?
  2. Welche Kundenbedürfnisse wird das Produkt abdecken?
  3. Welche Produktmerkmale stechen heraus und dürfen auf gar keinen Fall fehlen?
  4. Gibt es Konkurrenzprodukte und worin besteht das Alleinstellungsmerkmal der eigenen Idee?
  5. Wann soll das Produkt auf den Markt kommen und welches Budget steht dafür zur Verfügung?

Damit alle Beteiligten vom Marketingfachmann bis zum Techniker die Vision nachvollziehen können, soll sie leicht verständlich und frei von Fachjargon sowie nicht zu umfangreich formuliert sein, sondern kurz und prägnant die Essenz der Antworten auf die obigen Fragen abbilden. Eine wirklich schlagkräftige Vision findet Platz auf einem DIN-A3-Plakat und erhält in dieser Form einen prominenten Platz im Teambüro.

Schritt 2: Das Produkt mit den Augen der Benutzer entwerfen – Die Benutzerrollen

Bei der Entwicklung der Produktvision wird bereits die Zielgruppe umrissen, allerdings lassen sich die Benutzer eines Software-Systems noch detaillierter nach ihren Bedürfnissen kategorisieren. Zur Identifikation von Benutzerrollen gibt es verschiedene Verfahren, z.B. die Entwicklung von Personas.

In einem klassischen Job-Portal beispielsweise kann man sich folgende Benutzerrollen vorstellen:

  • Stellenanbieter
  • Jobsuchender
  • Personalvermittler
  • Plattformbetreiber

Durch die Identifikation spezifischer Benutzerrollen fällt es im anschließenden Schritt leichter, konkrete Funktionen zu benennen und den Wert einer Funktion für das Gesamtsystem zu bestimmen: Eine Funktion, die auf eine Benutzerrolle mit voraussichtlich hoher Nutzerzahl oder aber hoher Zahlungsbereitschaft zugeschnitten ist, ist in der Regel wertvoller als eine Funktion, die sich an eine zahlenmäßig kleinere oder weniger lukrative Benutzerrolle richtet.

Schritt 3: Funktionen für den Erfolg sammeln – Der Product Backlog

Nachdem im ersten Schritt das grundsätzliche Ziel formuliert und im zweiten Schritt die anzusprechenden Benutzerrollen konkretisiert worden sind, ist es an der Zeit, die Funktionen zu erfassen, die das Produkt bieten sollte, um die Bedürfnisse der einzelnen Benutzerrollen abzudecken.

Jede geplante Funktion wird dabei in Form einer User-Story erfasst, die Gesamtheit aller User-Stories bildet den Product Backlog. Dabei wird der im Anforderungs-Workshop aufgebaute initiale Product Backlog mit Sicherheit auch User-Stories umfassen, die im Projektverlauf durch neue Erkenntnisse als irrelevant erkannt und deswegen verworfen werden. In weiteren Anforderungsmeetings werden im Laufe des Projekts wiederum User-Stories hinzukommen, die zu Beginn nicht beachtet wurden.

Man sollte also nicht verbissen versuchen, jede denkbare Funktion für jede Benutzerrolle in den initialen Product Backlog zu pressen, sondern sich vielmehr darauf konzentrieren, diejenigen User-Stories zu finden, die die Erfüllung der Produktvision sicherstellen, wenn eine erste Version des geplanten Produkts ausgeliefert wird. In der Regel ist hier ein klassisches Brainstorming die zielführende Methode.

Grundsätzlich liegt die Anforderung an eine sinnvolle User-Story in der Erfassung der folgenden drei Punkte:

  1. Für welche Benutzerrolle ist die Funktion?
  2. Welche Wirkung hat die Funktion im System?
  3. Welchen Mehrwert bietet die Funktion für den Nutzer?

Eine beispielhafte User-Story für ein Job-Portal könnte somit lauten: Als Jobsuchender [1] möchte ich Stellenanzeigen nach Stichwörten durchsuchen können [2], um für mich interessante Stellenanzeigen zu finden [3].

Vor der konkreten Umsetzung müssen selbstverständlich weitere weitere wesentliche Bestandteile von User-Stories, wie z.B. Akzeptanzkriterien, ergänzt werden. (Mit Akzeptanzkriterien als Grundlagen für die notwendigen Akzeptanztests in Software-Projekten befassen wir uns in einem separaten Artikel ausführlich.)

Schritt 4: Wissen was wichtig ist – Die Priorisierung des Backlogs

Die Ergebnisse aus Schritt 3 sind naturgemäß ungeordnet, da sie durch ein Brainstorming entstehen. Im vierten und letzten Schritt gilt es nun also, Ordnung in das Product Backlog zu bringen, denn für den weiteren Projektverlauf ist es essenziell, die wichtigsten bzw. wertvollsten User-Stories zuerst umzusetzen.

Die Frage hierbei ist: Wie ist der Wert einer User-Story zu bestimmen? Einen tatsächlichen monetären Wert zuzuweisen, ist wenig zielführend, da zu Projektbeginn zu viele Unbekannte im Spiel sind. Deswegen vereinfacht man das Problem und behilft sich mit Priorisierungskategorien. Eine sinnvolle Kategorisierungsmöglichkeit bietet das Vorgehen nach dem MoSCoW-Prinzip (Must, Should, Could, Won’t).

Grundsätzlich stehen sich der angenommene Nutzwert, den eine Funktion dem User bietet, und die geschätzten Kosten gegenüber. Der Gesamtwert einer User-Story ergibt sich aus dem Verhältnis dieser beiden Größen. Unserer Erfahrung nach ist es jedoch sinnvoll, im ersten Anforderungs-Workshop zunächst nur Aussagen zum Nutzwert zu treffen und nachgelagert den Aufwand zu beschätzen sowie eine Re-Priorisierung vorzunehmen.

Fazit

In einem Anforderungs-Workshop werden also die Grundlagen für einen erfolgreichen iterativen Entwicklungsprozess geschaffen, der auf kurzen, festen Zeitintervallen basiert und bei dem Auftraggeber und Dienstleister auf ein gemeinsames Ziel hinarbeiten. Die im Product Backlog enthaltenen konkreten Anforderungen sind priorisiert, sodass das Team genau nach den Prioritäten vorgehen kann, die der Kunde gesetzt hat. Somit besteht immer die Gewissheit, dass die am höchsten priorisierten Anforderungen in hoher Qualität realisiert werden, ehe es zur Umsetzung von weniger wichtigen Funktionen und Nice-to-haves kommt.

Haben Sie Fragen zu Scrum? Möchten Sie Agilität in Ihrem Unternehmen einführen? Planen Sie ein Software-Projekt und möchten sich agile Vorgehensweisen zunutze machen? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Mit mehr als 20.000 Stunden Projekterfahrung in internen und externen Projekten mit agilen Entwicklungsmethoden gehört //SEIBERT/MEDIA zu den erfahrenen und größten Anbietern für Scrum in Verbindung mit den Atlassian-Tools Jira/Greenhopper und Confluence in Deutschland. Gerne helfen wir Ihnen bei der Etablierung agiler Prinzipien und Verfahren – sprechen Sie uns einfach unverbindlich an. Weiterführende Informationen finden Sie auch auf unserer speziellen Seite zum Thema Agilität in Unternehmen.

Quellen und weiterführende Informationen

Schwaber, Ken: Agile Project Management with Scrum. Microsoft Press. 2004.

Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
User-Stories: Anforderungen aus Nutzersicht dokumentieren
Die Scrum-Meetings und ihre Bedeutung
Agile Projekte und Scrum in der Praxis: Elemente, Nutzen, Tools, Hürden

Hinterlassen Sie eine Antwort

Kommentare