Im Verlaufe des ersten User Story Workshops hat einer der Teilnehmer die oben genannte Frage gestellt. Die Frage kam von einem Mitarbeiter im Produktmanagement, der bisher häufig mit Dokumentationen wie Pflichtenheften etc. gearbeitet hat und nun verstärkt User Stories nutzen möchte. Für den Mitarbeiter ist insbesondere die Empfehlung für die Praxis interessant sowie Eure Erfahrung und ggf. ein konkretes Beispiel. Obgleich ich hierzu auch eine Meinung habe, möchte ich der Teamprove Wissen Community die Möglichkeit bieten hierauf zu antworten.
2 Antworten
Ich würde die Frage gerne etwas weiter fassen da ich mir sonst mit der Antwort etwas schwer tue.
Wenn ich die Frage stelle, ob in einer User Story ein Verweis auf die Anforderungsquelle enthalten sein sollte, dann würde ich jederzeit mit "Ja" antworten, da somit immer und allen klar ist, wo diese Anforderung herkommt und wer ggf. die Ansprechperson ist falls es noch Fragen oder ähnliches gibt.
Falls es sich bei dem Verweis auf Dokumente darum handelt, dass auf Informationen in Dokumenten verwiesen wird, "Nein". Eine User Story sollte meines Erachtens alle notwendigen Informationen haben um sie auch umzusetzen. So kann sie als "Single Source of Truth" dienen. Wenn ich immer die aktuellen Informationen bei einer Story habe muss ich nicht erst nachschauen, ob sich das Dokument geändert hat und wo in diesem Dokument die Informationen zu finden sind. Hier gibt es ja einige Tools, welche einen bei der Verwaltung der User Stories unterstützen.
Beides würde ich allerdings nicht als Bestandteil des Satzes "Als ___ möchte ich, das___, damit ___." sehen, sonder viel mehr als Zusatzinformation, welcher gemeinsam mit der Story festgehalten wird. So bietet der Satz noch immer einen guten und schnellen Überblick und alle weiteren Informationen kann ich mir dann anschauen, wenn es relevant ist.
Jetzt hoffe ich auch, dass ich die Frage richtig verstanden habe. 
Da es immer wieder auch Situationen gibt, in denen man auf Pflichtenhefte nicht verzichten kann, ist es durch aus denkbar, aus den darin festgehaltenen Pflichten User Stories abzuleiten und so quasi die Anforderungen in kleine, überschaubare Einheiten zu übersetzen.
Ich halte nichts davon bei der Arbeit mit User Stories noch zusätzliche Anforderungsdokumentationen wie Pflichtenhefte zu pflegen. Aus meiner Sicht ist es extrem wichtige, dass es eine eindeutige Quelle gibt. Dies sehe ich durch die parallelen Pflichtenhefte absolut gefährdet, da es sehr leicht dazu kommen kann, dass die beiden Stellen dann unterschiedlich gepflegt sind und sich damit widersprechen. Das ist im Zweifel schlimmer als überhaupt keine Beschreibung zu haben.
Besonders wichtig ist aus meiner Sicht, dass eine User Story nicht nur die Beschreibung (Ich als <Rolle> möchte <Ziel/Wunsch> um <Nutzen>) ist, sondern vor allem in den Gesprächen zwischen allen Beteiligten während der Umsetzung lebt. Damit gibt die Beschreibung erst einmal den groben Rahmen vor, der dann gemeinsam erläutert und vor allem von allen verstanden wird. Hier zeigt sich auch, dass User Stories vor allem im agilen Kontext, in dem man in regelmäßigen kurzen Abständen miteinander die nächsten Schritte der Weiterentwicklung abstimmt, sehr gut passen. Wenn ich wenige Tage vor der Umsetzung und damit Fertigstellung (Test) einer User Story über deren Inhalt gesprochen habe und alle Details verstanden habe, brauche ich keine Dokumentation, die mehrere Seiten umfasst.
Damit muss die "Entwicklung" der Anforderungen eben auch parallel zur Entwicklung in kleinen Schritten erfolgen und kann somit besser auf neue Erkenntnisse eingehen. Damit muss auch nur das beschrieben und besprochen werden was jetzt wirklich wichtig ist. Der Aufwand für die Beschreibung eines umfangreichen Pflichtenheftes entfällt dadurch. Da das auch nicht jeder lesen muss wird weitere Zeit eingespart, die besser in Gespräche zum gemeinsamen Verständnis investiert werden kann.
Wenn es dann doch Details gibt, die z.B. zum späteren wiederholten Testen festgehalten werden sollen, bin ich ein Freund von Test-Notizen und angehängten Test-Fällen direkt an der User Story. Damit habe ich eine zentrale Stelle an der alles relevante, aber eben nicht mehr steht.
Besonders wichtig ist aus meiner Sicht, dass eine User Story nicht nur die Beschreibung (Ich als <Rolle> möchte <Ziel/Wunsch> um <Nutzen>) ist, sondern vor allem in den Gesprächen zwischen allen Beteiligten während der Umsetzung lebt. Damit gibt die Beschreibung erst einmal den groben Rahmen vor, der dann gemeinsam erläutert und vor allem von allen verstanden wird. Hier zeigt sich auch, dass User Stories vor allem im agilen Kontext, in dem man in regelmäßigen kurzen Abständen miteinander die nächsten Schritte der Weiterentwicklung abstimmt, sehr gut passen. Wenn ich wenige Tage vor der Umsetzung und damit Fertigstellung (Test) einer User Story über deren Inhalt gesprochen habe und alle Details verstanden habe, brauche ich keine Dokumentation, die mehrere Seiten umfasst.
Damit muss die "Entwicklung" der Anforderungen eben auch parallel zur Entwicklung in kleinen Schritten erfolgen und kann somit besser auf neue Erkenntnisse eingehen. Damit muss auch nur das beschrieben und besprochen werden was jetzt wirklich wichtig ist. Der Aufwand für die Beschreibung eines umfangreichen Pflichtenheftes entfällt dadurch. Da das auch nicht jeder lesen muss wird weitere Zeit eingespart, die besser in Gespräche zum gemeinsamen Verständnis investiert werden kann.
Wenn es dann doch Details gibt, die z.B. zum späteren wiederholten Testen festgehalten werden sollen, bin ich ein Freund von Test-Notizen und angehängten Test-Fällen direkt an der User Story. Damit habe ich eine zentrale Stelle an der alles relevante, aber eben nicht mehr steht.