Szenario 2
Randbedingungen
Dieses Szenario zeichnet sich durch folgende Randbedingungen aus:
- Ein einziger Microservice enthält die zur Umsetzung der Vision komplette Funktionalität.
- Ein einziges Scrum Team ist für diesen Microservice zuständig
- Alle Entwickler sind Spezialisten und kennen sich nur in einem der folgenden Themen aus:
- Frontend (Angular)
- Business Logic (Java)
- Persistence Layer (Database)
Ablauf
Mit diesen Randbedingungen könnte der Ablauf für unsere Beispielvision wie folgt aussehen:
 | Der Product Owner formuliert die Vision: Unsere Kunden können ihre Rechnungsart selbständig im Kundencenter auf Direct debit, eBill oder Papierrechnung wechseln. |
 | Experience Designer und Requirements Engineer kreieren das Experience Design und erstellen folgende User Stories: - Als Kunde kann ich meine Zahlungsart auf paper bill wechseln (Frontend) - Als Kunde kann ich meine Zahlungsart auf paper bill wechseln (Business Layer) - Als Kunde kann ich meine Zahlungsart auf paper bill wechseln (Backend) - Als Kunde kann ich meine Zahlungsart auf eBill wechseln (Frontend) - Als Kunde kann ich meine Zahlungsart auf eBill wechseln (Business Layer) - Als Kunde kann ich meine Zahlungsart auf eBill wechseln (Backend) - Als Kunde kann ich meine Zahlungsart auf Direct debit wechseln (Frontend) - Als Kunde kann ich meine Zahlungsart auf Direct debit wechseln (Business Layer) - Als Kunde kann ich meine Zahlungsart auf Direct debit wechseln (Backend) |
 | Der Scrum Master weist die User stories einem Sprint zu und stellt sicher, dass die Abhängigkeiten zwischen den Stories korrekt berücksichtigt werden. |
 | Entwickler, Tester, Sicherheitsverantwortliche und der Betriebsverantwortliche arbeiten gemeinsam an der Implementierung der User Stories, den Tests und stellen sowohl Sicherheit wie Betrieb sicher. |
Zahlen zur Effizienz
Folgende Kennzahlen geben Aufschluss über die Effizienz dieses Szenarios:
- Formulierte Visionen: 1
- Geschriebene User Stories: 9
- Benötigte Sitzungen / Abstimmungen (Total: 4-10)
- 1 zwischen dem Produkt Owner, Requirements Engineer und dem Experience Designer
- 3-9 zwischen dem Requirements Engineer und den Entwicklern/Testern/Verantworlichen für Security und Betrieb
- Potentielle Lieferung der Funktionalität: in 4-6 Wochen
- Involvierte Personen: 13
- Verantwortlichkeitsgefühl der involvierten Personen: Mittel
Fazit
Das Szenario 2 ist massiv weniger effizient als Szenario 1.
Um dieselbe Funktionalität umzusetzen werden
- Statt 2-4 Meetings nun bereits 4-10 Meetings benötigt!
- Statt 3 User Stories nun 9 User Stories mit starken Abhängigkeiten benötigt!
- Weil die eigentliche Businessfunktionalität nun über drei Layer und somit über 3 Entwickler verteilt implementiert werden muss, müssen die User Stories neben den fachlichen Anforderungen nun auch technische Details wie Interfacedefinitionen enthalten. Wenn der Requirements Engineer diese nicht selbständig erstellen kann, kommen hier noch weitere Meetings hinzu!
- Weil die Interfaces bereits vom Requirements Engineer vorgegeben werden müssen, sind die Entwickler in der Umsetzung eingeschränkt und müssen allenfalls unnötige Mappingfunktionalität implementieren.
- Frühester Lieferzeitpunkt in 6 Wochen: Weil die User Stories starke Abhängigkeiten haben, werden sie in der Praxis oft in aufeinanderfolgende Sprints verteilt. Somit werden in unserem Fall mindestens 3 Sprints benötigt.
- Das Team kann sich nicht auf eine Funktionalität konzentrieren. Weil die User Stories voneinander abhängig sind, wird in der Praxis nur der Backendentwickler im Sprint 1 an dieser Vision arbeiten. Die Entwickler für die anderen Layer werdern mit der Umsetzung einer anderen Vision beschäftigt sein.
- Die eigentliche Funktionalität muss über die Layer verstreut immer von mehreren Entwicklern umgesetzt werden. Dies mindert das Verantwortlichkeitsgefühl des einzelnen. Zumindest entsteht diese Funktionalität im selben Team und die Verantwortung als Team kann wahrgenommen werden.