User Story Pattern: Teilen nach Schnittstellen

Dass User Stories dem INVEST-Prinzip genügen sollen, ist keine Neuigkeit und leicht zu verstehen. Wie man es in der Praxis erreichen kann, dass Stories diesen Prinzipien entsprechen, ist schon schwieriger. Sucht man bei Google nach Pattern für Story Schnitt findet man eine ganze Reihe von Ideen und Empfehlungen.
Ich möchte in einigen kurzen Artikeln einige Pattern vorstellen, die mir in Projekten begegnet sind – oder die ich mir gewünscht hätte 🙂

Beginnen möchte ich mit dem Pattern Teilen nach Schnittstellen (Split along interfaces).

Eine Änderung im System bedingt, dass eine Reihe von Schnittstellen, z.B. Web Services, angepasst werden müssen. Das kann z.B. bei Anpassungen am Datenmodell der Fall sein, wenn die gleichen Daten von verschiedenen Web Services für unterschiedliche Kontexte oder Anwendungsfälle benutzt werden.

Hier würde ich für jede Schnittstelle immer eine separate Story erstellen. Das wirkt vielleicht zunächst sehr aufwändig, weil vielleicht jede Story die gleiche Änderung beschreibt. Tatsächlich vereinfacht es aber meine Aufgaben als Product Owner.

Der Vorteil einer Story pro Schnittstelle liegt darin, dass ich als Product Owner die Möglichkeit habe, zu priorisieren. Habe ich nur ein Entwicklungsteam, kann ich entscheiden, welche Schnittstellen am wichtigsten sind und die Stories in eine entsprechende Reihenfolge zu bringen. Habe ich mehr als ein Team zur Verfügung kann ich bei getrennten Stories eine höhere Parallelisierung erreichen.

Ein gutes Schnittstellen-Design vorausgesetzt, sind sämtliche Stories isoliert voneinander testbar. Neben der Priorisierung schafft dieses Pattern auch Transparenz für mich als Product Owner. Ich kann jederzeit erkennen, wie weit mein Team mit den Änderungen fortgeschritten ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.