NBA73: Stories ohne Stories?

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

00:00:06: Jede Woche spreche ich hier kurz und knapp über Themen rund um agiles Arbeiten. In der letzten

00:00:11: Folge ging es um den Simple Guide to Scrum. Das ist ein Vorschlag für einen Scrum Guide auf einer

00:00:17: DIN A4 Seite. Wenn dich das interessiert, hör da gerne rein. Den Link, wie alle Links, die ich hier

00:00:22: erwähne, findest du in den Shownotes. Heute in Folge 73 will ich darüber sprechen, wie viele

00:00:28: Informationen braucht eine Story? Was ist gut genug? Was lenkt vielleicht ab? Was ist vielleicht

00:00:33: sogar waste? Ja und ich würde sagen, wir steigen da auch gleich rein. Das Thema beschäftigt mich

00:00:39: tatsächlich schon ein bisschen länger. Ich frage mich und ich denke jetzt vor allen Dingen auch an

00:00:43: Jira. Ist es gut, was ich alles so in so eine Story rein packe? Also klar, da gibt es ein Ziel,

00:00:51: da gibt es eine Beschreibung, da gibt es Acceptance Criteria, aber da gibt es ja noch viel, viel mehr.

00:00:56: Labels. Bei uns ist es so, dass wir einige Custom Fields haben, um zum Beispiel Auswertungen zu

00:01:03: machen. Man ordnet das einem Epic zu. Man packt Screenshots mit in die Beschreibung oder weitere

00:01:10: Konzeptdokumente. Man verlinkt auf ein Confluence. Also, es steht schon ziemlich viel in so einer

00:01:16: Story drin. Und im ersten Blick ist es ja auch so, dass das Sinn macht. Ich möchte ja ganz gerne,

00:01:24: dass das Team möglichst gut darüber informiert ist. Was soll die Story erreichen? Dass wir eine

00:01:31: gleiche Idee davon haben. Und dann möchte ich natürlich dem Team weiteres Futter geben. Also,

00:01:37: ich hatte ja schon gesagt, vielleicht irgendwelche Screenshots oder Dokumentationen zu einer API oder,

00:01:43: oder, oder. Ihr kennt das selber. Und das fühlt sich für mich zumindest erst einmal natürlich

00:01:49: und richtig an. Auf der anderen Seite, wenn man ein bisschen länger darüber nachdenkt,

00:01:55: könnte das dazu führen, dass man auch Dialog vermeidet. Denn, wie gesagt, es steht ja alles

00:02:04: in der Story drin. Also kann man ja auch sagen, naja, warum soll ich denn nochmal über die Story

00:02:09: reden? Ich habe ja alles runtergeschrieben, was denn hinten rauskommen soll. Und Dialog ist doch

00:02:17: eins der großen Dinge im agilen Arbeiten. Und der Dialog soll ja deswegen stattfinden,

00:02:24: weil wir wissen, dass wir das, was rauskommen soll, gar nicht vollständig beschreiben können. Und wir

00:02:30: eigentlich nur durch so Micro-Feedback und Diskussionen dazu, während wir an einer Story

00:02:36: arbeiten, zu der für diesen Zeitpunkt richtigen Lösungen kommen. Und deswegen komme ich immer

00:02:44: wieder auf den Punkt, dass ich überlege, ja, wie viel ist genug für so eine Story? Ich bin

00:02:51: jetzt nicht so mutig, das muss ich auch klar sagen. Und ehrlich gesagt, ich kann es mir auch

00:02:56: nicht so richtig vorstellen, im Prinzip ganz auf eine Story zu verzichten. Also man könnte ja mal

00:03:02: hingehen, Mann, ich, und sagen, wisst ihr was? Wir lassen mal vier Wochen Jira zu und wir schreiben

00:03:11: einfach nur Karten und kleben die uns auf ein Whiteboard. Und tatsächlich, so was hatten wir

00:03:18: mal. Das ist auch schon ganz lange her, aber wir hatten mal ein riesiges Whiteboard und haben im

00:03:23: Prinzip mit allen vor diesem Whiteboard gestanden und sind dann die Karten in den verschiedenen

00:03:29: Spalten durchgegangen. Und wenn jemand was fertig hatte, ist er aufgestanden, hat auf dem Whiteboard

00:03:34: so eine Karte in einen anderen Status verschoben. Also wirklich ein physikalisches Board. Aus der

00:03:40: Zeit weiß ich aber auch, dass es eben alles nicht so trivial ist, denn ein paar grundsätzliche Infos,

00:03:45: die muss man ja dem Team mitgeben. Ich bleibe jetzt einfach bei API-Dokumentation. Das kann

00:03:51: man woanders machen, das kann man natürlich ins Confluence oder in Wiki oder in was weiß ich was

00:03:56: packen. Trotzdem ist es natürlich eigentlich auch wieder ganz gut, wenn es in der Nähe von der

00:04:01: Story ist. Die Leute also eben nicht auch noch dann im Confluence suchen müssen, ja, wo finde ich

00:04:07: denn jetzt die Doku dazu? Also die Idee ist zu sagen, wie detailliert muss eine Story sein? Und

00:04:16: es gibt natürlich zwei Extreme. Ein Extrem ist, es steht einfach alles, alles, alles in einer Story.

00:04:23: Und das andere Extrem ist, es steht so gut wie nichts in einer Story. Habe ich alles da drin

00:04:29: stehen, ist meine Hypothese und das ist glaube ich nicht nur meine, dass dann zu wenig über die

00:04:37: Story geredet wird. Steht gar nichts drin, ist die große Gefahr, dass zu viel über die Story

00:04:43: geredet wird oder deswegen Waste produziert wird, weil die Leute vielleicht nicht reden. Ich glaube,

00:04:49: ich denke, du weißt, worum es heute gehen soll und was ich damit meine. Ich würde ganz gerne jetzt

00:04:56: mal ein bisschen durchgehen, welche Vor- und welche Nachteile ich so sehe. Und wir wollen mal

00:05:00: anfangen mit den Vorteilen von minimalistischen Storys. Ich definiere jetzt nicht, was ist denn

00:05:07: minimalistisch. Ich glaube, auch das ist eher individuell. No size fits all. Und je nachdem,

00:05:14: wo ihr gerade steht, was für ein Projekt ihr habt, wo euer Team steht, ob ihr eine gewisse

00:05:20: Kundenbeziehung habt oder nicht, ist es auch unterschiedlich. Aber trotzdem. Also ein Vorteil

00:05:26: ist ganz klar, den hatten wir jetzt schon. So eine minimalistische Story lenkt den Fokus eher

00:05:31: aufs Gespräch. Man ist sicherlich fast genötigt, sage ich mal, mehrfach über das Ziel der Story

00:05:39: zu reden. Und das ist was Gutes. Ich habe das jetzt so Micro Feedback Loop genannt,

00:05:44: dass man mehr als einmal die Woche über eine Story spricht, sondern wahrscheinlich sogar mehrfach

00:05:52: am Tag. Der zweite Vorteil kann sein, es ist insgesamt weniger Overhead. Also ich produziere

00:05:58: vielleicht nichts Falsches, sondern wir reden regelmäßig darüber. Deswegen ist ziemlich klar,

00:06:02: was genau passieren soll. Man muss beim Pflegen einer Story weniger Zeit investieren. All die

00:06:10: Metainformationen müssen gar nicht mehr in diese Story rein. Ein dritter Vorteil kann sein,

00:06:15: weniger Micro Management, auch wenn das erst mal komisch klingt. Aber wie gesagt,

00:06:19: wir haben schon ein paar mehr Metainformationen in unseren Storys, weil Jira eben ja auch Custom

00:06:27: Fields ermöglicht. Und einige davon dienen tatsächlich auch für einen operativen Prozess.

00:06:34: Also wie funktioniert Zeiterfassung zum Beispiel? Daraus werden vielleicht Rechnungen erstellt.

00:06:39: Aber eben auch gewisse Dinge wie Kontrollen, sage ich mal. Also bestimmte Werte, die vielleicht

00:06:48: erhoben werden. Und das sind alles leichte Anzeichen. Ich würde das bei uns eher als

00:06:55: gering noch einschätzen. Ich weiß nicht, wie eure Boards so aussehen und was noch so in der Story

00:07:00: erfasst wird. Aber da kann eine Tendenz zum Micro Management drin sein. Der nächste Vorteil von so

00:07:07: minimalistischen Storys kann sein, dass damit so Team Engagement und Ownership verstärkt wird. Bei

00:07:17: einer Story, die im Prinzip allumfänglich beschreibt, kann man natürlich sagen, ja,

00:07:22: das habe ich nicht entwickelt oder das habe ich so und so entwickelt, weil das steht ja so in

00:07:26: der Story oder eben nicht. Also man nutzt die Story. Das meine ich nicht im aktiven Nutzen,

00:07:33: aber eine Story verleitet eventuell dazu, dann gar nicht mehr zu reden und alles, was da drin

00:07:38: steht, als gegeben anzunehmen. Im Sinne von, na ja, da hat sich einer schon ganz viele Gedanken

00:07:44: gemacht und da steht eben genau das nicht drin. Warum sollte ich jetzt nochmal nachfragen? Soll

00:07:49: es nicht besser so sein? Und bei einer sehr simplen Story ist man ja systemimmanent, sage ich mal,

00:07:58: ja, gezwungen, ja, selber zu überlegen, was kann da wohl mit gemeint sein? Da muss ich nochmal

00:08:05: nachfragen. Und das kann dazu führen, dass es einfach mehr Ownership gibt. Was man als Nachteil

00:08:11: sehen kann für so minimalistische Storys ist sicherlich, hatte ich vorhin schon mal kurz

00:08:18: angedeutet, Verlust von Informationen oder ich muss Informationen woanders her haben,

00:08:23: denn ich brauche ja, ich bleibe jetzt einfach bei diesem Beispiel, die API-Doku, da kann ich

00:08:28: nicht drüber reden. Also muss irgendwo zu der Story oder zu dem Projekt natürlich irgendeine

00:08:35: Art von Informationspool sein. Also bei uns wäre das Confluence, das kann auch irgendwie ein

00:08:40: File-Server sein oder was auch immer ihr nutzt, aber es gibt natürlich fachliche Informationen,

00:08:46: die irgendwo zur Verfügung stehen müssen. Das ist natürlich schön, dass man das gleich in

00:08:50: Jira machen kann. Das wäre natürlich jetzt mit so einer extrem schmalbrüstigen Variante von

00:08:55: der Story, wenn sie nur auf einer Karte steht, schon wieder schwieriger, dann müsste ich mir

00:09:00: irgendwie überlegen, dass ich da eine Indexnummer dran schreibe oder so und im Confluence finde ich

00:09:04: dann eine Seite zu dieser Indexnummer. Irgendwas in dieser Art müsste man sich dann halt überlegen.

00:09:09: Das zweite, Jira ist natürlich auch eine gewisse Art von Dokumentationspool, je nachdem wie man es

00:09:16: dann nutzt. Das heißt, Leute, die nicht direkt im Projekt beteiligt sind, also vielleicht kommt

00:09:21: eine neue Kollegin ins Team, hätten halt mit minimalistischen Storys überhaupt keine Möglichkeit,

00:09:27: wirklich nachzuvollziehen, was ist da passiert, es gibt keine Historie, man sieht die Komits nicht,

00:09:32: all das, was Jira halt so kann. Und ja, das ist natürlich dann ein großer Vorteil, wenn man so

00:09:38: Systeme wie zum Beispiel Jira einsetzt und das im Zweifel mit anderen Systemen, wie gesagt,

00:09:43: Git-Komits oder so, auch noch verknüpft. Der nächste Punkt ist, wenn ich dann ein stark

00:09:50: verteiltes System, wenn ich dann ein stark verteiltes Team habe oder mehrere Teams an

00:09:56: einem Produkt arbeiten und die sind verteilt, dann habe ich mit so einer simplen Variante

00:10:02: auch ein Skalierungsproblem. Ich habe auch noch ein ganz anderes Skalierungsproblem,

00:10:06: nämlich dieser permanente Dialog ist halt eine richtig gute Idee, unbestritten, aber mit wem

00:10:12: sprechen die Leute, wenn die immer mit dem gleichen Menschen sprechen, dann ist der natürlich

00:10:17: irgendwann auch ein Flaschenhals. Und insofern muss man das auch in die Waagschale schmeißen,

00:10:21: dass man mit, ja, ich sag mal, detaillierteren Storys auch ein bisschen besser in einer

00:10:28: asynchronen Kommunikation ist. Eine detaillierte Story verhindert ja auch nicht die Kommunikation,

00:10:33: es ist aber so, wie ich vorhin schon gesagt habe, man neigt eher dazu, das, was in der Story steht,

00:10:39: für wahrzunehmen und weniger zu sprechen. Und je detaillierter die Story ist, desto größer ist,

00:10:46: glaube ich, dieser Effekt. Ja, es gibt natürlich noch einen Punkt, der auch relevant sein kann,

00:10:51: nämlich wenn das Unternehmen aufgrund von gesetzlichen Vorgaben oder anderen Rahmenbedingungen

00:10:59: eine Nachvollziehbarkeit auf irgendeine Art garantieren muss, dann ist natürlich eine

00:11:05: elektronische Software, die zum Beispiel eine detaillierte Historie mitführt, die durchsuchbar

00:11:11: ist, die archivierbar ist, ja, viel besser als eine simple Story auf einer Karte. Das ist einfach

00:11:17: ganz klar auch ein Argument. Ja, wie ich ganz am Anfang gesagt habe, ich bin auch nicht mutig

00:11:23: genug, das wirklich einfach mal auszuprobieren. Ich sag jetzt nicht, das ist der einzige Weg,

00:11:29: den man gehen kann. Nur dann macht man nochmal einen großen Schritt in Richtung agiles Arbeiten.

00:11:33: Ich habe ein bisschen rumgeguckt. Es gibt Leute, die sind dieser Meinung. Ich kann das auch

00:11:38: nachvollziehen. Und trotzdem sehe ich bei uns zumindest genügend Rahmenbedingungen, dass ich

00:11:45: sage, ja, die Vorteile einer elektronischen Story und die Vorteile einer etwas ausführlichen Story

00:11:52: überwiegen. Und trotzdem muss es ja nicht schwarz-weiß sein. Und das ist für mich sicherlich

00:11:58: ein Schritt, über den ich ein bisschen mehr nachdenken will. Wie detailliert muss eine Story

00:12:02: sein? Wo finde ich die Grenze zwischen, die ist noch detailliert genug, um zum Beispiel asynchron

00:12:08: zu arbeiten oder auch den Arbeitsprozess im Team nicht zu stören oder zu verlangsamen? Und wo ist

00:12:15: zu viel Information eher hinderlich? Weil ich den Punkt auf jeden Fall sehe, dass eine zu detaillierte

00:12:22: Story ein gewisses Hemmnis für das Sprechen über die Story ist. Und ich rede hier natürlich von

00:12:28: Storys, die ein bisschen gehaltvoller sind. Ich glaube, dass man schon auch ein Potenzial hat,

00:12:35: indem man regelmäßiger über, wo stehen wir bei der Story und was ist wirklich jetzt der Sinn,

00:12:42: welche neue Erkenntnisse haben wir, reden will. Dieses, ja, ich sage mal, Micro-Feedback-Loop,

00:12:49: die will man eigentlich haben. Und ja, wie gesagt, das steht jetzt bei mir zumindest auch

00:12:54: nicht ganz oben auf der Prioritätenliste, aber es ist etwas, wo ich denke, da lässt sich wahrscheinlich

00:13:00: sogar noch was rausholen. Ja, und das soll es dann tatsächlich für heute auch gewesen sein. Wie immer,

00:13:05: kurz und knapp. Mir geht es ja vor allen Dingen darum, ja, ich sage mal, ein Gespräch zu starten,

00:13:11: dass ihr vielleicht dann intern habt, dass ihr vielleicht sogar ein bisschen inspiriert seid.

00:13:15: Das wäre natürlich ganz toll. Da freue ich mich, wie immer, auch auf euer Feedback,

00:13:20: auf all den bekannten Kanälen, die ihr auch in den Shownotes findet. Wie immer habe ich noch eine

00:13:25: ganz große Bitte. Wenn dir die Folge hier gefallen hat, vielleicht hast du schon mehr

00:13:29: gehört und dir gefällt der ganze Podcast, dann teile das gerne mit anderen, teile das mit deinen

00:13:34: Kolleginnen und Kollegen, teile es auf deinen Social-Media-Kanälen. Der Hintergrund ist,

00:13:39: je mehr Leute von dem Podcast erfahren, desto größer wird die Diskussion, desto mehr Themen

00:13:43: kann ich hier aufnehmen und aus verschiedenen Blickwinkeln beleuchten. Und ja, das kommt,

00:13:48: wenn es gut läuft, dir ja auch wieder zugute. Ich sage auf jeden Fall ganz vielen Dank dafür

00:13:52: und ich sage, habt noch eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit Agile.