Anforderungsaufnahme und deren Dokumentation

Die Aufgabe des Product Owners ist es, alle Arten von Anforderungen seines Projektes zu kennen und zu managen. Grundsätzlich können Anforderungsarten unterschieden werden. Dabei ist zu beachten das Anforderungen von unterschiedlichen Stakeholdergruppen stammen können.

Requirements Engineering mit Scrum


Beispielsweise würde sich der klassische Product Owner, der ein fachliches Interesse an dem zu realisierenden System hat, eher auf die Realisierung von funktionalen Anforderungen konzentrieren. Hier würden dann technische Aspekte des IT-Betriebs vernachlässigt. Somit ergeben sich auch in agilen Methoden einige Ansprüche an das Anforderungsmanagement, um sicher zu stellen, dass die Erwartungen von allen Stakeholder-Gruppen berücksichtigt werden.

Scrum definiert keine inhaltlichen Kriterien an Anforderungen, sondern sagt lediglich aus, dass allein der Product Owner für das Management der Anforderungen verantwortlich ist.

Somit hat der Product Owner darauf zu achten, dass alle relevanten Anforderungen in das Product Backlog einfließen. In der Realität ergeben sich hieraus einige Herausforderungen, da der Product Owner nur sehr schwer die Anforderungen aller Stakeholder vertreten und einschätzen kann.

Wir empfehlen, durch eine anfangs durchgeführte Stakeholder-Analyse die relevanten Anforderungssteller herauszufinden und in größeren Projekten nicht nur einen einzelnen Product Owner zu ernennen, sondern ein Product Owner Team aufzustellen. Dieses Team ernennt einen »Chief Product Owner«, der die vollständige Verantwortung trägt und bei Uneinigkeit Entscheidungen trifft.

Scrum Aufbau von Anforderungen

Abbildung 19 – Balance zwischen verschiedenen Anforderungsarten


Die hier dargestellte Abbildung zeigt auf, welche zusätzlichen Informationen durch den Anforderungssteller, den Product Owner, formuliert sein müssen, um Systeme ganzheitlich zu formulieren und auch nach initialem Entwicklungsabschluss in eine Betriebsphase zu überführen.

Im Product Owner Team sollten sich dann die folgenden Rollen wiederfinden:

  • fachlicher Anforderungssteller
  • Verantwortlicher für den Betrieb des Systems
  • Unternehmensarchitekt
  • Prozessverantwortlicher
  • professioneller Anforderungsanalyst

Ermitteln / Dokumentieren / Verifizieren

Scrum Anforderungen Verfeinern

Abbildung 20 – Verfeinerung der Anforderungen


Der Anforderungsanalyst hilft dem Product Owner mit professionellen Methoden, Anforderungen zu finden und diese zu formulieren. Hier eignen sich besonders Interviewtechniken und auch moderierte Workshops.

Weiterhin hilft der Analyst, die Anforderungen so festzuhalten, dass sie den Qualitätsaspekten

  1. Inhalt
  2. Form der Dokumentation
  3. Abgestimmtheit

genügen (vgl. Rupp, Pohl[1]). Sinnvolle und hilfreiche Qualitätskriterien an Anforderungen können zum Beispiel die durch den Standard IEEE 830 definierten Qualitätskriterien, die Kriterien der Sophist Group oder auch die INVEST-Kriterien nach Cohn sein (siehe hierzu Abschnitt »Standards«).

Zu Beginn eines Projektes äußern die Stakeholder ihre Erwartungen und definieren welche Qualitätskriterien zu erfüllen sind.

Budget und Anforderungen: Das Dilemma

Zu Beginn eines Projekts ergibt sich oft das Requirements Dilemma: Die Anforderungen sind noch unklar aber das Budget steht schon fest.

Wie genau Sie ihre Anforderungen kennen müssen, hängt von der Projektstufe sowie gegebenenfalls vertraglichen Festlegungen in Ihrer Organisation ab. Im Laufe des Projekts steigt im Allgemeinen die Kenntnis und nimmt die Unsicherheit ab. Dieser Zusammenhang wird im Cone of Uncertainty dargestellt:

Scrum Cone of Uncertainty

Abbildung 21 – Cone of Uncertainty


Agile Projekte konzentrieren sich auf das frühzeitige Schaffen von funktionierender Software. Nur diese kann einen Wertbeitrag für ein Unternehmen leisten. Ein integrierter Requirements-Engineering und Entwicklungsprozess reduziert Risiken, da Ergebnisse regelmäßig bewertet werden und eine kontinuierliche Wertschöpfung stattfindet.

In Wirklichkeit steht das Projektbudget jedoch oft fest, bevor mit allen Stakeholdern gesprochen wurde und bevor alle Anforderungen definiert sind. Es gibt jedoch verschiedene Möglichkeiten, um mit diesem Problem umzugehen und eine Bewertung unter Unsicherheit zu ermöglichen:

  • Nehmen Sie keine Schätzungen vor. Liefern sie häufig hochwertige und lauffähige Software und beenden Sie ihre Arbeit, wenn das Budget erschöpft ist.
  • Reduzieren Sie die Unsicherheit mit verschiedenen Bewertungsmethoden wie
    • parametrischen Schätzmodellen mit historischen Projektdaten
    • Function-Point-Verfahren
    • Projektstrukturplänen mit PERT-Schätzungen
    • Regelmäßigen Planning Poker Sitzungen
  • Weisen Sie Feature-Sets oder Epics eigene Budgets zu. Danach können Sie den Requirements-Engineering-Prozess daraufhin überprüfen, ob die gesamten Feature-Sets dem Budget entsprechen. Hierzu sind regelmäßige Bewertungen erforderlich.

Mit diesen und vielen anderen Methoden lässt sich die Unsicherheit bereits vor dem Projektbeginn in den Griff bekommen. Scrum beseitigt die anfängliche Unsicherheit nicht, sondern ist lediglich eine iterative Methode, um in jedem Sprint Wert zu erzeugen und das Risiko zu begrenzen, dass ein Projekt scheitert.

Anforderungen verstehen

Grundvoraussetzung für gute Schätzung und Planung ist ein hinreichendes Verständnis der Anforderungen. Um dieses zu erreichen, gibt es bei Scrum verschiedene Methodiken:

  1. Refinement: Reservieren Sie 10–15% der Sprint-Zeit für das Backlog Refinement. Überlassen Sie es dem Team, wie es sich auf ein effektives Planungsmeeting vorbereitet. Unerfahrene Teams sind von dieser Freiheit oft überwältigt und bereiten sich kaum auf die Meetings vor, sondern verbessern in dieser Zeit eher die Features, die von ihnen entwickelt werden.

  2. Planen Sie Time-Boxes ein, in denen Sie gemeinsam mit dem Product Owner Anforderungen verfeinern oder an technischen Details (z. B. Konzepten oder Projektstrukturplänen) arbeiten.

  3. Halten Sie regelmäßige Planungspoker-Sitzungen ab, um bestehende Anforderungen zu verfeinern und neue Anforderungen zu behandeln, und nehmen Sie Story-Point-Schätzungen vor.

Es gibt viele Möglichkeiten, die o.g. Qualitätskriterien zu verbessern. Bei größeren Projekten in regulierten Umgebungen empfiehlt es sich jedoch, den Requirements-Engineering-Prozess teilweise zu formalisieren.


Planungsaufgaben für Product Owner und Team

Über itemis

Die itemis AG ist ein unabhängiges IT-Beratungs­unternehmen, das leistungsfähige Software für Unternehmens­anwendungen, eingebettete Systeme und mobile Applikationen entwickelt – und über diese Themen bloggt.