Planungsaufgaben für Product Owner und Team

Zuerst einmal ist es für ein neu formiertes Team eine große Herausforderung, herauszufinden, wie hoch seine Entwicklungskapazität in einem Sprint ist und wie viele Items vom Team in einen Sprint eingeplant werden können. Hierzu empfiehlt es sich, die ersten Sprints sehr kurz laufen zu lassen, sogar als Wochen- oder Zweiwochensprints, damit sich das Team zeitnah justieren kann. Auf längere Drei- oder sogar Vierwochensprints sollte das Team erst nach guten Erfahrungen mit kürzeren Zyklen setzen, dann aber die Sprintlänge beibehalten.

Anforderungsaufnahme und deren Dokumentation


Über die direkten Schätzungen hinaus hat das Projekt selbstverständlich noch einige weitere Planungsaufgaben, die erfüllt sein müssen, damit Sprints ans Ziel gelangen. Diese weiteren Tätigkeiten, wie zum Beispiel das Beachten von eingeplanten Urlaubstagen und sonstigen Verfügbarkeiten und Nicht-Verfügbarkeiten der Teammitglieder werden in den Planning-Meetings vor jedem Sprint organisiert.

Ebenen der Anforderungsspezifikation

In den verschiedenen Projektphasen werden unterschiedlich detaillierte Anforderungsebenen benötigt, wobei jede Ebene ihre eigenen Artefakte hat.

Die Ebenen reichen vom Vision-Document (z. B. einem klassischen Projektauftrag mit einem Business-Case) über modellierte Geschäftsprozesse in Form von Anwendungsfällen (Use Cases) bis hin zur Spezifikation von Schnittstellen und GUI-Prototypen sowie UML-Anwendungsdiagrammen (z. B. Klassen- oder Sequenzdiagrammen).

Pyramide der Anforderungen

Abbildung 22 – Ebenen der Anforderungsspezifikation


In umfangreichen oder streng regulierten Produktumgebungen (z. B. bei der Entwicklung von Medizinprodukten) müssen die Artefakte produziert, gepflegt und geprüft werden. Sie können zwar für einzelne Anforderungen sequentiell erstellt werden, doch bedeutet dies nicht, dass die Erstellung aller Anforderungen ebenfalls sequentiell verläuft. Wir erinnern uns, dass nur die Anforderungen, die Stufe 2 des Product Backlog erreichen, alle Schritte durchlaufen müssen.

Anforderungen entstehen nicht aus heiterem Himmel. Sie müssen weiterentwickelt werden, um zu reifen und schließlich einen ROI zu erwirtschaften. In einem iterativen Prozess arbeitet der Product Owner mit seinen Stakeholdern an der Nutzenmaximierung und mit dem Team an der besten Lösung einer Anforderung.

Qualität und Verständnis einer Anforderung wachsen mit der Zeit. Der gesamte Prozess der Verfeinerung lässt sich auch als Konsensfindung aller Stakeholder betrachten.

All diese formal erscheinenden Schritte lassen sich im Sinne einer agilen Praxis enger Zusammenarbeit und Kommunikation durchführen: Product Owner, Team und Stakeholder kooperieren auf verschiedenen Ebenen, um das Projekt bestmöglich zu verwerten.


Schätzen von Anforderungen und Aufgaben

Ü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.