NBA69: Wie wichtig sind User Stories?

00:00:00: Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Jede Woche spreche

00:00:07: ich hier kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge ging es

00:00:11: um Elastic Leadership. Das ist ein Denkmodell, das die verschiedenen Phasen von Teams mit

00:00:15: verschiedenen Führungsstilen verknüpft. Wenn dich das interessiert, hör da gerne rein. Den Link wie

00:00:20: alle Links, die ich hier erwähne, findest du, wie sich das gehört, in den Shownotes. Heute in Folge

00:00:26: 69 geht es mir um die Bewertung der Wichtigkeit von User Stories. Ich hatte da in letzter Zeit

00:00:31: immer wieder mal drüber nachgedacht und habe mir gedacht, komm, fass doch mal so ein bisschen die

00:00:36: Meinung von anderen zusammen und ich gebe ein bisschen meine Meinung mit dazu. Bevor wir dazu

00:00:41: kommen, ein bisschen Housekeeping. Ich hatte es beim letzten Mal schon erzählt. Ich habe es auf

00:00:45: Mastodon ein bisschen erzählt. Wenn ihr Lust habt auf einen Sticker von No Bullshit Agile für das

00:00:52: Laptop oder für eine Wasserflasche oder wo auch immer ihr Sticker hinklebt, meldet euch gerne

00:00:56: bei mir. Ich habe ein paar über und die würde ich euch gerne schicken. Auch den Link, den gibt es in

00:01:01: den Shownotes. Dann würde ich sagen, wir steigen mal ein. User Stories kennt ihr ganz sicherlich

00:01:07: alle und ich weiß nicht so genau, ob ihr teamintern da auch immer mal wieder Gespräche darüber habt

00:01:13: oder nicht, aber für mich ist es immer mal wieder ein Thema und war jetzt letzte Woche auch wieder

00:01:18: ein Thema und deswegen habe ich mir gedacht, was ist so eine User Story, wie viel Zeit investiert

00:01:24: man in eine? Und ich mache Gänsefüßchen in der Luft. Gute User Story. Was sagt das Internet denn

00:01:30: dazu? Wie bewertet das das? Und ja, deswegen habe ich mich hingesetzt und habe einfach mal ein paar

00:01:37: Meinungen zusammengesammelt. Wir fangen einfach mal an. Viele sagen, eine User Story bietet einem

00:01:43: eine große Chance, klare Rollen und Ziele zu definieren. Das zielt vor allen Dingen natürlich

00:01:49: auf diese klassische Formulierung ab. Wie formuliert man eine User Story? Und natürlich

00:01:55: ist es so, sehe ich auch so, eine User Story grundsätzlich mal hilfzubeschreiben. Für wen ist

00:02:02: das überhaupt? Was ist der Anlass? Warum möchte jemand etwas haben? Und worum geht es hier überhaupt?

00:02:09: Ich finde wichtig an der Stelle und das ist schon so ein erster Denkansatz, vielleicht sogar ein

00:02:15: Kritikpunkt. Es geht darum, wer möchte was? Es geht nicht darum, wie machen wir das? Das Wie

00:02:24: kommt einer ganz anderen Stelle. Und ich habe das Gefühl, immer mal wieder fällt man in diese Falle

00:02:30: rein, wenn man eine User Story schreibt oder mehrere, dass man auch sofort über das Wie spricht.

00:02:35: Und das ist vielleicht gar nicht schlau. Wir wollen erst mal ja, ich sage mal, versuchen,

00:02:41: die Anforderung zu verstehen. Das heißt, es geht nicht darum, technische Details zu beschreiben. Das

00:02:47: sagen tatsächlich auch viele. Es geht darum, ja, aus dem Nutzen heraus zu beschreiben, was wollen

00:02:56: wir damit erledigen? Ein Punkt, der immer wieder auftaucht, ist tatsächlich eine User Story und

00:03:03: da vor allen Dingen Acceptance Criteria können helfen, ja A, ein gutes Agreement darüber zu

00:03:10: erzielen, was soll hinten rauskommen und B, erhöht es auch die Testbarkeit. Denn die Idee ist fundamental

00:03:18: zu sagen, die Acceptance Criteria können ein sehr guter Input sein für automatisierte Tests. Ich

00:03:27: sehe den Punkt. Ich sehe aber auch in der Praxis, zumindest bei uns, ist es wirklich sinnvoll, so

00:03:34: viel Zeit in meistens dann relativ detaillierte Acceptance Criteria zu investieren, wenn die

00:03:43: Anforderung aus der Testbarkeit kommt. Die Testbarkeit zielt oft genug auch auf das Wie ab.

00:03:51: Eben gerade hatten wir ja gesagt, das Wie sollte keine große Rolle bei einer Story sprechen. Da

00:03:57: sehe ich, ja, da sehe ich einen Konflikt, würde ich nicht sagen, aber zumindest ein Ding, auf das

00:04:02: man achten kann, investiert man zu viel Zeit in die Acceptance Criteria und kriegt man diese

00:04:10: investierte Zeit hinten wieder raus. Das nächste Thema, was ich gelesen habe, was auch immer wieder

00:04:15: kam, naja, eine User-Story schafft ja auch eine Nachvollziehbarkeit. Und ja, na klar, gerade wenn

00:04:22: man jetzt Jira benutzt, kann man schön, und das tue ich auch in der Story, allerdings auch in einem

00:04:28: Test oder in einem Bug, auch in einem Subtest, in die History gehen und sagen, ja gut, wann haben

00:04:32: wir was gemacht, in welchem Status war die, wann. Das ist schon richtig, aber ehrlich gesagt, das

00:04:39: ist jetzt dem Tool geschuldet, das man benutzt. Nutzt man ein anderes Tool oder ein Whiteboard, auf

00:04:45: das man wirklich physikalisch Karten durchspalten zieht, hat man das natürlich deutlich weniger.

00:04:51: Und ist es wirklich die Grundidee einer User-Story und eine Grundanforderung einer User-Story,

00:04:57: Nachvollziehbarkeit zu haben? Ich glaube nicht. Ich glaube, das ist zwar ein ganz schönes Abfallprodukt,

00:05:04: aber schlussendlich ja ein Abfallprodukt auf Basis des Tools, in dem wir User-Stories schreiben

00:05:10: und verwalten. Ich bin dann noch darüber gestolpert, dass einige das Argument vorbringen, naja, das ist

00:05:17: ja eigentlich ein schöner Leitfaden, so eine User-Story, dass man keine typischen Probleme begeht.

00:05:23: Und die Idee ist, glaube ich, ein bisschen, man kann ja Templates machen, man kann ja sagen, okay, wir

00:05:30: haben einen Rahmen, den wir in der User-Story vorgeben können, unsere Pflichtfelder zum Beispiel.

00:05:35: Und deswegen, ja, kann man damit verhindern, dass typische Probleme einer Story entstehen. Und ja,

00:05:43: wir nutzen teilweise auch Templates, wir haben auch in Jira teilweise Custom-Fields, um genau

00:05:49: sowas abzubilden. Und trotzdem bleibt ja die Frage, ist das überhaupt noch ein Rahmen einer User-Story

00:05:56: oder ist es etwas, wo wir versuchen, einen Prozess zu steuern und dafür wieder, ich sage mal, die

00:06:02: Möglichkeiten des Tools nutzen. Die User-Story, und da komme ich gleich auch noch drauf, hat ja

00:06:08: eigentlich fundamental gesehen einen ganz anderen Zweck. Der nächste Punkt, und ich finde, der ist

00:06:15: ja ziemlich zentral für mich und ja, vielleicht auch für dich, ist eine User-Story eben vor allen

00:06:23: Dingen ein Gesprächsanker. Ich weiß, das ist fast eine Plattitüde, das ist mir schon klar, aber wenn

00:06:30: die User-Story oder mehrere User-Stories irgendwie in eine Richtung eines Pflichtenhefts geht, ja,

00:06:36: dann haben wir halt einfach nichts gewonnen. Ich will nicht sagen, User-Story, da reicht ein Satz.

00:06:43: Natürlich gibt es weitere Hinweise, die man miterfasst oder weitere Anforderungen, die man

00:06:49: damit formulieren will und das ist ja auch gut und richtig und trotzdem, wenn wir zurück zum

00:06:54: Fundament kommen, finde ich es total wichtig, dass man die User-Story nicht als gegeben hinnimmt und

00:07:01: deswegen auch nicht darauf abzielt, dass die einen Anspruch auf Vollständigkeit hat. Sie soll ein

00:07:09: Gesprächsanker sein und sie soll dazu dienen, nicht nur am Anfang, sondern auch während wir an der

00:07:15: User-Story arbeiten, darüber zu sprechen. Auf der anderen Seite könnte nämlich Folgendes passieren,

00:07:21: wir verstecken uns hinter einer User-Story. Wir sagen eben ganz klar, na gut, das steht aber nicht

00:07:27: in der Story, warum soll ich denn nachfragen, ob es so ist, sondern das wird dann nicht erwähnt,

00:07:32: also mache ich es nicht oder ich mache es genauso, wie in der Story steht, obwohl ich feststelle beim

00:07:38: Entwickeln, oh, eigentlich gibt es zwei schlauere Ansätze, die man jetzt besprechen müsste und das

00:07:44: ist sicherlich ein ganz zentraler Punkt hier von der Folge von heute. Warum geht es mir auch, was

00:07:51: ist der grundsätzliche Sinn einer User-Story und wie gesagt, wenn man sich dahinter versteckt, wenn

00:07:56: es so stark zu einem Pflichtenheft wird, ja, ich glaube, dann ist es wirklich eine gewisse Grenze

00:08:02: überschritten. Der nächste Punkt ist im Prinzip eine Ergänzung dazu. Wir wollen grundsätzlich ja

00:08:09: lean arbeiten und für mich bedeutet das unter anderem, Perfektionismus ist eigentlich nicht das,

00:08:16: was wir wollen. Das klingt auch verlockend, etwas Perfektes zu haben, aber perfekt zu definieren

00:08:23: und dann später zu sagen, das ist perfekt, ist unheimlich schwer und wird oft auch nicht benutzt.

00:08:29: Ich will nicht fuschen, darum geht es mir nicht. Es geht mir darum, diese Waage zu treffen zu,

00:08:35: wie gut ist gut genug und wenn eine User-Story perfekt sein muss, habe ich immer die große Angst,

00:08:43: dass sie trotzdem nicht vollständig ist, sondern einfach nur einen perfekten Anschein erwirkt und

00:08:51: das zweite eben ist, wollen wir wirklich perfekt erreichen. Zum Format und da komme ich gleich auch

00:08:58: nochmal drauf, kann ich sagen, ich bin kein großer Fan, dass das Format ein Selbstzweck ist.

00:09:05: Mir ist es wichtig, dass wir im Zweifelsfall auch, sage ich mal, ja, Formate nicht zu ernst nehmen.

00:09:13: Das ist schon ganz gut, bestimmte Formate definiert zu haben, das hilft insgesamt bei der Sicherheit,

00:09:20: aber eine formal richtige Story nutzt halt keinem was, wenn sie keinen Wert schafft und inhaltlich

00:09:28: einfach auch nicht passt. Und ja, das habe ich auch tatsächlich gefunden, dass mehrere das auch so

00:09:34: sehen und sagen, ja, sehen sie in der Praxis auch. Für mich passt hier auch noch der Punkt, den ich

00:09:40: auch immer wieder gerne mache, nämlich löst euch von dem Tool. Also ihr nutzt Jira. Jira hat eine

00:09:48: gewisse Denkweise. Das muss überhaupt nichts mit euren Prozessen zu tun haben. Es kann sein,

00:09:54: dass Jira euch sogar irgendwie, sage ich mal, ja, so eine Scheinwahrheit vorgibt und ihr zum Beispiel

00:10:02: denkt, okay, ist das jetzt hier eine User Story, so wie Jira das vorsieht? Ist es ein Task, so wie

00:10:09: Jira das vorsieht? Oder ist es ein Bug? Vielleicht habt ihr sogar noch mehr von diesen Arten und

00:10:15: Templates und dann ist es für mich so, dass ich denke, oh, allein die Diskussion darum und der

00:10:22: Gedanke dazu, was ist es? Das ist mir ehrlich gesagt schon zu viel Overhead. Ich denke nicht

00:10:28: lange darüber nach, mache ich jetzt, wir nutzen Jira, wähle ich jetzt das Blaue oder das Grüne

00:10:34: aus für die Leute, die jetzt auch Jira nutzen? Also wähle ich eine Story oder wähle ich ein Task? Für

00:10:39: mich hat das früher eine Bedeutung gehabt. Mittlerweile hat das für mich ehrlich gesagt

00:10:43: überhaupt keine Bedeutung mehr. Es kommt doch auf den Inhalt an, ne? Und deswegen denke ich,

00:10:48: lasst euch nicht vom Tool da steuern. Jira denkt in Epic Story und Tasks und eine Story und ein

00:10:55: Task können auch Subtasks haben. Das ist schön, dass Jira das so denkt, aber verschwendet nicht

00:11:00: so viel Zeit darum, solche Formalien zu diskutieren, wäre mein ganz klarer Tipp. Ja,

00:11:06: und das soll tatsächlich diese Bewertung auch schon sein. Wie immer, mir geht es ja darum,

00:11:11: so ein bisschen Gedanken mal reinzuschmeißen und gucken, was wohl kleben bleibt. Für mich ist es

00:11:18: einfach so, ich sage nicht, User Story macht keinen Sinn. Ich sage, überlegt mal und beobachtet mal,

00:11:25: wie eure User Stories so aussehen. Wenn die zu aufgebläht sind, muss es wirklich so sein. Und

00:11:30: redet ihr wirklich noch darüber, ob eine Story gut ist oder nicht? Ob da nicht was fehlt? Ob man

00:11:36: es nicht doch anders machen will? Oder sagt ihr wirklich, so steht es in der Story, das hat

00:11:40: lange gedauert, diese Story so zusammenzubauen und deswegen möchte ich meinen Plan nicht

00:11:44: verändern. Das wäre halt eben schwierig im agilen Arbeiten. Ja, und das soll es tatsächlich für

00:11:52: heute auch schon gewesen sein. Wie immer bin ich an deinem Feedback interessiert. Deswegen schreib

00:11:57: mir gerne. Die Kanäle findest du in den Shownotes. Da freue ich mich drauf. Ansonsten habe ich noch

00:12:02: eine ganz große Bitte. Wenn dir die Folge hier gefallen hat, wenn dir vielleicht der ganze

00:12:06: Podcast gefällt, dann teile das gerne mit deinen Kolleginnen und Kollegen. Teile es gerne auf

00:12:11: Social Media. Mir ist es wichtig, dass wir hier die Diskussion möglichst groß halten, dass viele

00:12:17: Leute an der Diskussion teilnehmen. Ich glaube, dann kann ich viel davon wieder aufnehmen und

00:12:22: in neuen Folgen verpacken. Und das kommt dir schlussendlich ja auch zugute. Ansonsten sage

00:12:28: ich, habe noch eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.