Wie viel Zeit sollten Product Owner eigentlich in das Schreiben von User Stories investieren? Wenn der Kalender voll ist und die To-do-Liste überquillt, wirkt das Story-Schreiben schnell wie eine lästige Pflicht. Viele sehen es als reine Schreibarbeit. Doch in Wahrheit ist es vor allem Denk- und Teamarbeit. Eine gute User Story entsteht nicht allein am Schreibtisch, sondern im Gespräch. Sie ist das sichtbare Ergebnis gemeinsamer Klärung; ein Zeichen dafür, dass sich ein Team verstanden hat. Wer User Stories schreibt, arbeitet also nicht an Texten, sondern am gemeinsamen Verständnis. Eine Story ist kein Dokument, sondern ein Kommunikationswerkzeug. Sie erinnert an ein Gespräch, in dem klar wurde, welches Nutzerproblem wirklich gelöst werden soll.
Manche Teams versuchen, Sicherheit durch besonders ausführliche Formulierungen zu schaffen. Dabei verlieren sie leicht das eigentliche Ziel aus den Augen. Gute User Stories entstehen, wenn Teams gemeinsam begreifen, worum es geht – nicht, wenn sie jedes Detail zu Papier bringen. Tim beschreibt User Stories als Einladung zum Dialog. Sie sollen Empathie für Nutzer:innen wecken und den Blick auf deren Bedürfnisse richten. In dieser Haltung wird das Schreiben von Stories zu einem Werkzeug, das Orientierung schafft. Wenn Teams verstehen, warum etwas wichtig ist, finden sie auch den passenden Weg dorthin. Dann reicht manchmal ein einziger Satz, um eine Idee zu verankern und das Gespräch darüber am Laufen zu halten. Dominique beobachtet, dass Organisationen sehr unterschiedlich mit User Stories umgehen. In großen Unternehmen wird oft zu viel dokumentiert, vielleicht, weil man es immer so gemacht hat. Startups dagegen schreiben häufig zu wenig auf. Beides zeigt ein Ungleichgewicht zwischen Vertrauen und Kontrolle. Ein Team, das seine Prozesse kennt und sich gegenseitig vertraut, braucht keine langen Texte. Es verlässt sich auf Dialog und gemeinsame Verantwortung. Wie viel Zeit also in die Story-Erstellung fließt, hängt stark von der Reife eines Teams ab. Wer schon lange zusammenarbeitet und den Produktkontext kennt, kommt mit wenigen Worten aus. Neue Teams dagegen brauchen mehr Austausch, um ein gemeinsames Verständnis aufzubauen. In jedem Fall sollte die Energie lieber in Nachdenken und Reflexion fließen als in das Polieren von Formulierungen.
Hilfreich ist die bekannte Zehn-Prozent-Regel: Rund zehn Prozent der Sprintzeit sollten in die Erstellung und das gemeinsame Refinement des Backlogs investiert werden. Diese Zeit zahlt sich aus, weil sie Klarheit schafft – über Ziele, Annahmen und Prioritäten. Wer hier spart, zahlt später mit Missverständnissen und Nacharbeit. Auch Künstliche Intelligenz kann dabei unterstützen, etwa durch Strukturvorschläge oder Formulierungsideen. Doch sie ersetzt kein gemeinsames Denken. Eine automatisch erzeugte Story ist noch keine Story, solange das Team nicht darüber spricht. KI kann inspirieren, aber kein echtes Verständnis schaffen und am Ende braucht es immer jemanden, der beurteilen kann, ob das Ergebnis wirklich gut ist. Gute User Stories entstehen also in Gesprächen, nicht in Tools. Sie schaffen ein gemeinsames Bild des Nutzerproblems und machen Produktentwicklung wirkungsvoller. Wer sich Zeit für den Austausch nimmt, gewinnt Klarheit und diese Klarheit ist die beste Grundlage für jedes gute Produkt.
Mehr zum Thema User Stories? Wie wäre es mit diesen Folgen:
Sie sehen gerade einen Platzhalterinhalt von Podigee. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenWie ist deine Erfahrung bei der Erstellung von User Stories? Lässt du dich bereits bei der Arbeit mit User Stories von KI unterstützen oder willst du es noch gar nicht versuchen? Teile deine Meinung und Erfahrungen mit uns und anderen Produktmenschen auf unserer LinkedIn Seite oder unter diesem Blogpost! Der gemeinsame Austausch hilft allen Produktmenschen zu wachsen und auf das nächste Level zu kommen.
2 Gedanken zu „Wie viel Zeit darf User Story Erstellung kosten – hilft uns KI dabei?“
Moin moin,
wir haben die Rovo-KI von Jira zuletzt ein paarmal genutzt. Genau genommen zwei der 5 Features: „Beschreibung verbessern“ und „Untergeordnete Vorgänge“ vorschlagen.
Besonders bei den untergeordneten Vorgängen (wir haben das genutzt, um die Untertickets eines Epics zu erstellen) ist es (wie immer bei KI) ausschlaggebend, wie gut man die Beschreibung des Epics geschrieben hat. Die KI kann schließlich nur mit den Infos arbeiten, die man ihr gibt. Wenn man es so sehen will, ist vielleicht deshalb schon einmal positiv, dass der geplante Einsatz der KI einen dazu zwingt, die Vorarbeit besser zu machen, also macht man sich dadurch vielleicht auch direkt mehr Gedanken dazu.
Ist man bei der Epic-Beschreibung dann ausführlich und versucht nichts zu vergessen, können bei den Vorschlägen für untergeordnete Vorgänge ganz brauchbare Dinge herauskommen. Die KI schlägt dann Tickets vor mit einem Titel und jedes Ticket enthält zwei, drei Sätze. 1:1 übernommen haben wir das noch nie, aber ganz unbrauchbar ist es auch nicht. Ob das am Ende Zeit gespart hat, weiß ich nicht. Vielleicht ein bisschen. Ein Projekt, für das wir die Tickets mit Rovo erstellt haben, geht bei uns gerade in die Umsetzung, also kann ich bald sagen, wie gut das mit den KI-generierten Tickets hingehauen hat.
Nutzt man das Feature „Beschreibung verbessern“, packt die KI die vorhandene Beschreibung in Kategorien. Es beginnt immer mit einer „User Story“, was dann der gängige Satz „Als Rolle möchte ich das und das, weil Grund“. Je nachdem, wie gut man die Inhalte für diesen Satz vorher in der Beschreibung hatte, kommen dabei auch mal ganz „spannende“ Dinge heraus (immer, wenn die KI etwas nicht weiß, rät sie halt).
Was die KI dann ausführlich macht, ist Akzeptanzkriterien zu erstellen. Die sind wirklich sehr granular, aber das muss nicht schlecht sein.
Die von Rovo erstellten Beschreibungen habe ich manchmal als Vorlage genommen und dann nochmal angepasst. Manchmal habe ich sie auch als komplett unbrauchbar verworfen.
Die anderen drei Features habe ich noch nicht genutzt.
Zum jetzigen Zeitpunkt würde ich sagen, dass die Rovo-KI eine Hilfe sein kann, aber nicht unbedingt sein muss. Sie ist definitiv kein Gamechanger oder eine Revolution bei der Arbeit mit Jira, wer weiß, ob sie das noch werden kann.
Ich bin auch bereit die Inhalte der Tickets, für die ich Rovo verwendet habe zu teilen, aber vielleicht nicht hier öffentlich :). Schreibt mich sonst gerne an.
Hallo Philipp,
sorry für die verzögerte Antwort und erstmal DANKE fürs Teilen eurer Erfahrungen mit der Rovo-KI – gerade der Punkt, dass man durch den KI-Einsatz fast automatisch sorgfältiger in der Vorbereitung wird, ist spannend! 👍
Was mich aber besonders interessiert:
Wie habt ihr die automatisch generierten Akzeptanzkriterien erlebt – eher im Lösungsraum formuliert (so à la “das System soll XY können”) oder waren sie im Problemraum gehalten, also hilfreich zur Klarstellung des Warum und Was?
Genau da sehen wir ja oft die Stellschraube: KI kann beim „Formulieren“ helfen – aber was formuliert wird (und in welcher Tiefe), ist am Ende immer noch ein menschliches Qualitätskriterium. Und natürlich ob/wie darüber gesprochen wird.
Bin gespannt, wie du das einschätzt – schick uns gerne auch mal die AK’s an feedback@produktwerker.de, wenn du magst.
Nochmals Danke für Deinen echt spannenden Kommentar/Feedback zur dieser Podcastfolge und unserem Aufruf darin.
Herzlicher Gruß, Tim