As summer time, I want to be simulated
Grafik: Pixabay / Julius H. - Lizenz |
Auf den ersten Blick eine klassische User Story mit dem bewährten Format. As <Role> I want to Perform <Action> so that I can have a <Business Value>. Auf den zweiten Blick durchaus problematisch, denn es fehlt der konkrete Endanwender/Kunde/Auftraggeber, für den diese Anforderung geschrieben wurde. Gerade dafür sind User Stories aber eigentlich da, sie sollen fachlich formuliert und geschnitten sein, damit die gerade genannten Personen sie verstehen und ihr Ergebnis überprüfen können. Hätte man also nicht eher formulieren müssen Als <Anwender> möchte ich auch nach der Zeitumstellung <Aktion X durchführen können> um <Mehrwert Y zu haben>? Im Prinzip schon, in diesem Fall wäre das allerdings schwierig gewesen. Der Bug trat in einer internen Logging-Funktion auf, die über die Benutzeroberfläche nicht einsehbar war.
Die an vergleichbaren Stellen oft auftretende Notlösung ist die Formulierung <Als Entwicklungsteam möchte ich> ... . Das ist zwar in speziellen Einzelfällen möglich, grundsätzlich halte ich es aber für ein Antipattern von dem ich meinen Teams immer abrate. Ein Team entwickelt Software so gut wie nie für sich selbst sondern fast immer für jemanden anderen, weshalb ich diese Formulierung sehr problematisch finde. Wenn aber eine Story sehr technisch/backendlastig ist, wegen der sonst auftretenden Kommunikationshindernisse aber die klassische Formatierung beibehalten werden soll, dann können durchaus kreative Formulierungen wie die in dem oben genannten Beispiel benutzt werden. Selbst wenn sie auf den ersten Blick albern wirken mögen - die Kollegen aus den Fachabteilungen können sie verstehen und die dafür nötigen Ressoucen freigeben, und das ist es worauf es ankommt.
1Um sicherzustellen, dass nur Features mit Nutzerbezug entwickelt wurden gab es die Vorgabe aus allen Anforderungen User Stories zu machen, wie hier zu sehen mit z.T. schrägen Ergebnissen