Agiles Spezifizieren: Just in Time für User Stories

Es ist mir schon fast unangenehm, das Wort agil nun auch in diesem Kontext zu verwenden. Jedoch halte ich es für notwendig, einen genaueren Blick darauf zu werfen, was bei der Spezifikation von Anforderungen in einem agilen Umfeld zu beachten ist. Zu oft sehe ich, dass nun statt umfangreichen Spezifikationen noch umfangreichere Mengen von umfangreichen User Stories entstehen.

Agiles Arbeiten bedeutet für alle Beteiligten – nicht nur für Requirements Engineers – an vielen Stellen ein Umdenken. Und eben auch beim Spezifizieren. Es bedeutet nämlich nicht, eine fertige Spezifikation nun einfach auf mehrere Iterationen zu verteilen oder „seitenweise“ weiterzugeben. Es bedeutet auch nicht, gar nicht mehr zu spezifizieren. Und es bedeutet nicht, Spezifikationen als eine lose– oder im besten Fall eine der Bearbeitungsreihe nach sortierte – Sammlung von User Stories zu tarnen.

Agiles Spezifizieren hat vielmehr zwei Aspekte: Erheben von Anforderungen und Spezifizieren von Anforderungen. Die Aktivitäten „Erheben“ und „Spezifizieren“ lassen sich allerdings nur schwer voneinander trennen, denn die Anforderungen, die erhoben werden, werden gleichzeitig in irgendeiner Form dokumentiert – also spezifiziert.

Just-in-time für Anforderungen

Das Just-in-time-Prinzip gilt in agilen Projekten für das Erheben und das Spezifizieren von Anforderungen gleichermassen. Hier muss das Umdenken erfolgen: Während in „konventionellen“ Projekten versucht wird, ein System möglichst vollständig vorab zu beschreiben, werden in agilen Projekten die wichtigsten und dringlichsten Merkmale (Features), die das System beinhalten soll, identifiziert und priorisiert.

Zu diesen Merkmalen werden wiederum die wichtigsten und dringlichsten Anforderungen (z.B. in Form von User Stories) erhoben, also die Anforderungen, die dem Anwender unmittelbaren Nutzen liefern, bzw. die für das Funktionieren des Systems unerlässlich sind. Auch diese werden nicht sofort vollständig ausspezifiziert, sondern liegen erstmal in Form sogenannter „Epics“ vor. Epics sind noch nicht ausformulierte, grobe User Stories (das Konzept der Epics kennt der Requirements Engineer als „Platzhalteranforderungen“).

Die Priorisierung oder besser, die geplante Bearbeitungsreihenfolge der Features, Epics und User Stories bestimmt deren Lebenszyklus und Detaillierungsgrad. Zu Features, die in naher Zukunft bearbeitet werden, werden zeitnah Anforderungen bzw. User Stories erhoben. Zu Features, die erst zu einem späteren Zeitpunkt umgesetzt werden sollen, werden die Anforderungen bzw. User Stories erst dann erhoben, wenn der Zeitpunkt näher rückt – also Just-in-Time.

Genauso funktioniert es mit der Ausdetaillierung von Epics und User Stories. Rückt der Zeitpunkt der Umsetzung näher, also die Einplanung in einen der kommenden Sprints, werden die Detailinformationen, wie Akzeptanzkriterien oder andere notwendige (!) Zusatzinformationen (wie zum Beispiel Geschäftsregeln, Geschäftsprozesse, Mock-Ups) ergänzt. Die Detaillierung erfolgt ebenso just-in-time.

Kleine Kritik am Konzept

Der Begriff Just-in-Time kommt natürlich aus der Produktionslogistik. Die Idee ist, A-Teile, die einen hohen Wert haben, nicht auf Lager zu legen, sondern die Lagerkosten zu minimieren, indem man diese just-in-time ans Band liefert. Das zu liefernde Produkt ist genau definiert und spezifiziert, der Lieferant weiss, was er liefern muss und der Empfänger weiss, was er bekommt.

Das ist bei der just-in-time Erstellung von Anforderungen nicht der Fall, denn wir kennen die Stückliste und damit die A-Teile nicht. Trotzdem können wir die Analogie zur Lagerhaltung übernehmen. Anforderungen, die erst spät im Projekt oder vielleicht sogar gar nicht umgesetzt werden, legen wir nicht auf Lager, da sie veralten und ständig gepflegt werden müssen.

Die Kunst besteht nun darin, herauszufinden, welche Anforderungen ich just-in-time erheben und spezifizieren kann und welche ich mir tatsächlich „auf Lager“ legen muss (z.B. Constraints oder Architekturvorgaben). Das Konzept der „Deferred Decisions“ hilft hierbei weiter.

Ausblick

Weitere Blogeinträge zum Thema „Agiles Spezifizieren“ sind in Arbeit, z.B

– Lagerhaltung von Anforderungen: „Deferred Decisions“

– die Kunst, das richtige Feature Set zu finden: Minimum Marketable Product

– Umdenken beim Erheben und Spezifizieren: Was ist dringlich und wichtig?

Susanne Mühlbauer

Kontaktieren Sie Susanne Mühlbauer

Susanne Mühlbauer ist als Agile Coach für die HOOD GmbH tätig. Sie arbeitet mit Leidenschaft und viel persönlichem Engagement mit Menschen, Teams und Organisationen auf ihrem Weg zu mehr Agilität. Aus ihrer Zeit als Consultant, Scrum Master, Projektleiter, Business Analyst und Requirements Engineer bringt sie langjährige Erfahrungen und die unterschiedlichsten Erlebnisse aus dem Projektgeschäft und in der Entwicklung komplexer Produkte und Systeme mit. Ein Schwerpunkt stellt hierbei sicherlich das Requirements Engineering dar. Sie hat zu diesen Themen Artikel veröffentlicht und ist gerne Referentin auf Fachkongressen. Ihr Leitsatz: Agilität muss man erleben. Hierfür steht Agile-by-HOOD.