Ist Dokumentation eine User Story? [geschlossen]

Wir müssen einige Benutzerdokumentationen für ein Produkt erstellen, an dem wir in den letzten Sprints gearbeitet haben. Wir starten jetzt ein neues Projekt im nächsten Sprint und die PO erstellt aus der Dokumentation für das zuvor produzierte Produkt eine User Story für diesen Sprint.

Ich frage mich nur Ihre Meinung zu diesem Ansatz. Persönlich stimme ich nicht zu, dass Dokumentation eine User Story innerhalb von Scrum ist, da sie keinen Code produziert.

EDIT: Danke für eure Meinungen Jungs. Ich hatte es im Hinterkopf, dass ein Sprint ein Inkrement funktionierender Software implementieren sollte, aber Ihre Ansichten haben meine Sichtweise verändert. Vielen Dank für alle Ihre Antworten.

"Als Benutzer von X muss ich wissen, wie X funktioniert" scheint mir eine legitime User Story zu sein. Dies kann zu schriftlicher Dokumentation oder Online-Hilfe führen.

Der Punkt ist nicht nur Code - er entspricht den Anforderungen der Benutzer.

Im Idealfall ist die Dokumentation Teil jeder User Story und wird nie aufgebaut. Aber in der realen Welt passiert das oft nicht. In diesem Fall sollten Sie eine User Story erstellen, um eine bestimmte fehlende Dokumentation nachzuholen.

Du hast recht, es wird kein Code erzeugt. Es erfüllt jedoch eine Benutzeranforderung und sollte gegenüber anderen Benutzeranforderungen priorisiert werden.

Wenn dies bedeutet, dass es nie erledigt wird, weil an dieser und jener Funktionalität gearbeitet wird, dann haben Sie die Dokumentation wahrscheinlich nicht so dringend gebraucht.

Ich stimme der Beurteilung der Dokumentation von pdr zu, wenn es um Anforderungen, technische Dokumentation oder Projektdokumentation geht. Idealerweise sollte es in die Sprintarbeit einbezogen werden.

Ich bin der Meinung, dass die Produktdokumentation sehr unterschiedlich ist, da sie von einem tatsächlichen Benutzer als lieferbar angefordert wird und dem Benutzer einen direkten Mehrwert bietet. Dies sollte selbstverständlich so verstanden werden, dass die Produktdokumentation im Wesentlichen keine technische Aufgabe, sondern eine funktionale Aufgabe ist und möglicherweise eine geeignete Aktivität für eine technische Ressource im Projekt darstellt.

Ich denke, es sollte eine User Story sein, aber ich bin der Meinung, dass eine Projektressource, die die Geschäftsanforderungen, die Benutzerperspektive und gute technische Schreibfähigkeiten genau kennt, mit diesen Aufgaben beauftragt werden sollte. Idealerweise ist dies ein Business Analyst, falls verfügbar, oder ein QS-Tester höherer Ordnung, der die Anforderungen, Anwenderberichte und guten technischen Schreibfähigkeiten genau kennt. Dies kann auch ein Entwickler sein. Die von Entwicklern erstellte Produktdokumentation ist jedoch in der Regel nicht so hochwertig oder nützlich, da Entwickler den technischen Details in der Regel zu nahe kommen.

In unserer Organisation verwendet das Tooling-Team, das für die Aufrechterhaltung und Verbesserung unseres kontinuierlichen Integrationssystems zuständig ist, Scrum, um die Verwaltung ihrer Arbeit zu unterstützen. Sie schreiben keinen Code, aber sie üben trotzdem Scrum.

Um Ihre Frage konkret zu beantworten, würde ich fragen, ob das Team der Ansicht ist, dass die Dokumentation Teil der "Definition of Done" ist oder nicht.

Wenn das Team der Ansicht ist, dass die Dokumentation Teil der "Definition of done" ist, ist keine zusätzliche Story erforderlich und die Story kann nur akzeptiert werden, wenn die Dokumentation geschrieben und validiert ist.

Wenn das Team der Ansicht ist, dass die Dokumentation nicht Teil der "Definition von erledigt" ist, würde ich eine separate Story erstellen, damit der Product Owner seine Arbeit verwalten kann.