Die Produktwerker

Dominique & Tim im Gespräch Eine Organisation beginnt agil zu arbeiten und benötigt dann Product Owner:innen. Oft werden ehemalige Projektleiter oder Teamleiter als Product Owner:innen bestellt. Dass sich durch diese Veränderung bestimmte Herausforderungen ergeben, liegt nahe. Dies zeigt sich auch in eurem Wunsch, sich einmal über dieses Thema zu unterhalten. Daher sprechen in dieser Folge Dominique und Tim über den Übergang von der alten Verantwortung zur neuen. Im Gespräch wird schnell deutlich, dass es einige Verhaltensweisen gibt, die Projektleiter:innen durchaus hilfreich sein können, aber auch andere, die Schwierigkeiten verursachen. Projektleiter:innen sind oft sehr auf die Auslieferung fokussiert, wobei der Output über dem Outcome steht. Auch die direkte Zuweisung von Aufgaben an Personen mag Projektleiter:innen nützlich sein, aber im agilen Kontext als Product Owner wird dieses Verhalten nicht gut funktionieren. Ähnliches gilt auch für Teamleiter:innen. Die Aufgaben der Personalentwicklung und der Personalbeschaffung fallen schlichtweg weg, sobald man die Verantwortung als Product Owner übernimmt. Das macht den Wandel nicht so einfach. Dabei kann vor allem Transparenz helfen. Damit ist nicht nur die Zusammenarbeit mit dem Team und den Stakeholdern gemeint, sondern auch die persönliche Reflexion. Ehemalige Rollenmuster müssen bewusst umgedeutet werden. Feedbackgeber wie das Team, insbesondere im Rahmen der Retrospektive, und Menschen in der Verantwortung als Scrum Master können dabei hilfreich sein. Diese spielen eine besonders wichtige Rolle, weshalb eine agile Transformation ohne Scrum Master, besonders für Personen aus den vorherigen Rollen als Projektleiter oder Teamleiter, schwierig ist. Dennoch ist eine solche Veränderung gut möglich. Im Gespräch wurde auf folgende Folgen verwiesen: POEM – Product Ownership Evolution (https://produktwerker.de/poem-product-ownership-evolution-model/) Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern (https://produktwerker.de/sei-dein-eigenes-produkt/) Außerdem erwähnten die beiden noch folgende Quellen: Das Role Model Canvas Blogpost von Roman Pichler "Be a Balanced Product Leader not a Feature Broker or Product Dictator" Blogpost von Roman Pichler "Six Types of “Product” Owners” Wenn ihr selbst aus der Projekt- oder Teamleitung heraus in die Verantwortung als Product Owner gekommen seid freuen wir uns über eure Erfahrungen. Teilt sie gerne im Blogpost zur Folge als Kommentar oder auf unserer LinkedIn-Companyseite als Kommentar. Diese Folge ist übrigens auch unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!

Dominique & Tim im Gespräch Eine Frage, die immer wieder aufkommt, ist die nach dem notwendigen technischen Wissen, dass man in der Verantwortung als Product Owner braucht. Dominique und Tim stellen sich in dieser Folge diese Frage und teilen ihre Erfahrungen sowie ihre Einschätzung dazu. Dazu muss man sich zuerst fragen, warum die Frage nach dem technischen Verständnis eigentlich aufkommt. Das kann einerseits an dem zugang zur Verantwortung als Product Owner liegen. Wenn man vorher in verwandten Rollen wie beispielswerise Business Analyst, oder Softwareentwickler gearbeitet hat, bringt man fast schon natürlich ein technisches Verständnis mit. Das könnte zumindest ein Grund sein, warum viele Product Owner bereits ein solches Verständnis haben und dadurch die Erwartungshaltung ihres Umfeldes entsprechend prägen. Ob das technische Verständnis aber immer hilft ist auch fraglich. Immerhin hat das Team in ihrer Domäne Expertenwissen und so manch ein Product Owner kann nicht aus der eigenen Haut und will mitmischen. Am Ende geht es aber in erster Linie darum, dass die Menschen, die zusammen versuchen ein erfolgreiches Produkt zu entwicklen miteinander sprechen können. Sie müssen sich gegenseitig verstehen. Daher ist ein sehr grundsätzliches technisches Verständnis durchaus hilfreich. Es muss nicht umfangreich sein und ein Informatikstudium ist garantiert zu viel des Guten. Wir haben in dieser Folge auf folgende Folgen verwiesen: Stellenausschreibungen für Product Owner (https://produktwerker.de/product-owner-stellenausschreibungen/) Vom Entwickler zum Product Owner (https://produktwerker.de/vom-entwickler-zum-produkt-owner/) Wie No-Code Tools Produktteams helfen (https://produktwerker.de/no-code-tools/) Darüber hinaus haben wir folgende Quellen genutzt: Six types of a “product” owners von Roman Pichler (https://www.romanpichler.com/blog/six-types-of-product-owners/) The Product Trio von Teresa Torres (https://www.producttalk.org/2021/05/product-trio/) Code it! (Coding Courses for Kids) (https://code-it-studio.de/) Diese Folge ist unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!

Stefan Vosskötter im Gespräch mit Tim "Ich denke die Konferenz als Produkt - nicht nur als das Event, denn ich bin auch als Gründer immer schon in der Produktmanager-Rolle gewesen" sagt unser heutiger Gast Stefan Vosskötter, Founder und Gründer, u.a. vom Digitale Leute Summit. Aus Sicht der Teilnehmenden ist eine Konferenz vermutlich vor allem ein Lernprodukt, eine Vernetzungsplattform oder halt ein großes Partyerlebnis. Aber aus Anbieter- und Veranstaltersicht stehen wohl oft eher der Event-Charakter und die Herausforderungen das Event Managements im Vordergrund. Doch wenn eine Konferenz über Jahre erfolgreich ist und auch den unterschiedlichsten Rahmenbedingungen des Marktes oder der Gesellschaft (z.B. Pandemie) trotz, dann hilft es eine Konferenz als Produkt zu verstehen. bUnd aus diesem Blickwinkel der Produktentwicklung betrachtet Tim Klein heute mit seinem Gast Stefan Vosskötter die Entwicklung einer Konferenz. Wie ist es zu der Idee gekommen? Was ist die Produktvision, wie ist die Wettbewerbssituation, welche Zielgruppen spreche ich an? Dies mögen noch die eher üblichen Fragestellungen bei der Organisation einer Konferenz sein. Und diese Fragen lassen sich im Zweifel auch auf Inhouse Konferenzen und Veranstaltungen übertragen. Doch die Unterhaltung der beiden geht deutlich darüber hinaus und beleuchtet die folgenden Fragen: Welche Hypothesen standen zu Beginn im Raum? Welche Experimente habt ihr durchgeführt? Welche davon waren erfolgreich? Welche sind fehlgeschlagen oder sogar krachend gescheitert? Welche grundsätzlichen Learnings habt ihr über die Jahre gemacht - insbesondere aus der Remote-Zeit? Was sind eigentlich Features eines Konferenzproduktes? Wie sieht die Roadmap des Produkts aus? Und wie lässt sich ein Produkt denn überhaupt hypothesenbasiert entwickeln, welches nur einmal im Jahr eine Iteration ausgeliefert wird? Aus dieser Betrachtung einer Konferenz aus dem Blickwinkel der Produktentwicklung lassen sich daher auch sicherlich spannende Impulse für das eigene Produkt ableiten. Also: einfach mal über den Tellerrand schauen - bzw. hier "hören"! Weitere Erfahrungsberichte über die Entwicklung nicht ganz alltäglicher Produkte findet ihr in diesen früheren Episoden: Product Owner für mein Buch - ein Erfahrungsbericht Meine Erfahrung als Product Owner von JOYclub Wer weitere Fragen an Stefan Vosskötter hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil. Neugierig bzgl. des Digitale Leute Summit und den StartUp-Aktivitäten von Stefan geworden? Dann gibt es weitere Infos unter digitale-leute.de bzw. deutsche-startups.de. Dass wir viele Konferenz- und Eventveranstalter in der unserer Hörerschaft haben glauben wir zwar nicht. Aber vielleicht organisierst du ja stattdessen eine Inhouse Konferenz, einen Learning Day, Agile Day oder ähnliches bei euch im Unternehmen? Betrachtet ihr dabei auch diese Konferenz als Produkt? Falls du den einen oder anderen Aspekt deiner Insights oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Oliver und Tim im Gespräch POEM steht für "Product Ownership Evolution Model" wurde 2017 von den beiden Produktwerkern Oliver Winter und Tim Klein erfunden und entwickelt. Es ist ein Modell, welches hilft mehr Product Ownership in einer Organisation zu etablieren. Es unterstützt dabei, die aktuell gelebte und zukünftig angestrebte Ausgestaltung der Product Ownership, vor allem im Sinne der Entscheidungsverantwortung, zu visualisieren, zu diskutieren und so gemeinsam weiterzuentwickeln. Auf diesen Ergebnissen aufbauend kann das Modell genutzt werden, um Verantwortlichkeiten für die Product Ownership zwischen den Rollen verbindlich(er) zu vereinbaren. Letztlich kann so auch ein möglicher Coaching-Bedarf der handelnden Personen/Rollen identifiziert werden, den Scrum Master und/oder Agile Coaches abdecken müssen. Oliver Winter und Tim Klein, die beiden Erfinder des Models, beleuchten in dieser Episode noch mal die Entstehungsgeschichte von POEM und welches Problem sie dazu führte, die Fragestellung von Entscheidungsverantwortung expliziter machen zu wollen. Die beiden erklären die Idee hinter dem Tool und erläutern Aufbau und Mechanik des Modells. Weiterhin beleuchten Sie seine Stärken und Schwächen und geben insbesondere Tipps und Hinweise, wie man POEM als Hilfsmittel in der Diskussion besonders effektiv einsetzen kann. So können insbesondere Scrum Master, Agile Coaches und Organisationsentwickler:innen - aber natürlich auch Product Owner - das Modell wirkungsvoll einsetzen. Download des POEM Templates inkl. Erklärungen zur Anwendung hier: produktwerker.de/poem/ In dieser Episode empfohlene Podcast Folgen: Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Welche Aufgaben gehören zur Product Owner Rolle? (POCC - Product Ownership Context Canvas) Wie No-Code Tools Produktteams helfen können Tim's Gastauftritt zu POEM und POCC im Podcast "Mein Scrum ist kaputt" (Folge 103) Die Produktwerker veranstalten auch offene Trainings - hier die Liste der nächsten Trainingstermine Auswahl von Videos zum Product Ownership Evolution Model Aufzeichnung Produktwerker Live-Event: Product Ownership mit POEM klären Talk beim Telekom Agilista Barcamp 2020: "POEM - Product Ownership Evolution Model" Tools4AgileTeams 2017: "POEM – Product Owner Evolution Model" Bücher, in denen POEM empfohlen wird: Frank Düsterbeck, Ina Einemann: Product Ownership meistern Sabina Lammert et al.: Das große Handbuch Digitale Transformation: 222 Methoden und Instrumente für mehr Wandlungsfähigkeit im Unternehmen Wie sind deine Erfahrungen mit Product Ownership? Wie macht ihr die Verteilung von Entscheidungsverantwortung explizit? Habt ihr dabei vielleicht sogar schon einmal POEM (Product Ownership Evolution Model) genutzt? Welche Erfahrungen habt ihr dabei gemacht? Hat sich durch den Einsatz etwas an der Diskussion des Themas verändert? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Daniel Dubbel im Gespräch mit Tim Man kann es wohl als besondere Herausforderung bezeichnen, Product Owner im Konzern zu sein. Die Frage ist dann immer, wie viel Produktverantwortung habe ich überhaupt oder anders gesagt: mit wie vielen anderen Menschen muss ich mir diese Verantwortung teilen? Tim hat heute Daniel Dubbel von der DB Systel zu Gast, um dieses diese Fragestellungen zu besprechen. Daniel ist langjähriger und erfahrener Agile Coach bei der DB Systel, dem internen IT-Unternehmen im DB Konzern. Daniel ist dort eine Führungskraft und in der Rolle als Agility Master aktiv an der Organisationsentwicklung des Unternehmens beteiligt. Im Rahmen dieser Verantwortung hat er die DB Systel auch im sogenannten DACH30 Netzwerk vertreten, einem Zusammenschluss von 30 Konzernunternehmen aus Deutschland, Österreich und der Schweiz, die sich seit einigen Jahren viermal im Jahr regelmäßig treffen, um über Agilität in solch großen Unternehmen zu diskutieren. In diesem Zuge wurden auch Diskussionen zu agilen Rollen im Konzern geführt und in sogenannte "Mindeststandards für Unternehmensagilität" entwickelt. Da es hierbei natürlich auch um die Product Owner Verantwortlichkeit ging, fanden wir es besonders spannend, Daniel Dubbel als Gast für diese Folge einzuladen und mit ihm darüber zu sprechen, was für Product Owner im Konzern vielleicht besonders oder anders ist. Aber auch bzgl. DACH30 wollte Tim wissen: Was war die Motivation, solche expliziten Rollenbeschreibungen für Konzernagilität zu definieren? Und inwiefern unterscheidet sich die Product Owner Rolle, die in diesen Mindeststandards als "Value-Verantwortlicher" beschrieben wird, vom Product Owner, wie er im Scrum Guide definiert wird? Einen spannenden Ausflug machen die beiden auch noch zur Fragestelleung, wie Kunden und Nutzer im Konzernumfeld eingebunden werden können. Am Ende des Gesprächs gibt Daniel Dubbel auch noch seine ganz persönlichen Tipps für Product Owner im Konzern. Tim verweist im Gespräch u.a. auf das "Lean Coffee für Agilität in Versicherungen", einer freiwilligen, ehrenamtlichen Netzwerk-Initiative, von Mitarbeitenden aus Versicherungsunternehmen. Alle sechs Wochen treffen sich hier Angestellte aus Unternehmen der Versicherungsbranche in einem selbstorganisierten, geschützten Raum. Wer festangestellt in einem Versicherungsunternehmen arbeitet, kann sich in der LinkedIn-Gruppe anmelden und bekommt dort dann die Einladungen mit. Achtung: Berater und Vertriebler werden explizit nicht in die Gruppe aufgenommen! Hier der Link zur Gruppe "Lean Coffee Agilität in Versicherungen". Die "Mindeststandards für Unternehmensagilität" von 30 börsennotierten Großunternehmen aus Deutschland, Österreich und der Schweiz sowie drei deutschen Beratungsunternehmen sind in folgendem Artikel von Daniel Dubbel sehr gut dokumentiert: https://www.inspectandadapt.de/agile-rollen-kompetenzen/. Infos über das DACH30-Netzwerk gibt es unter dach30.net im Netz. Frühere Episoden unseres Podcasts passen gut zur aktuellen Folge: Product Ownership im Konzernumfeld mit Felix Stein Customer Journey Management im Konzern - ein Erfahrungsbericht mit Martin Sallge Wer weitere Fragen an Daniel Dubbel hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über seine Webseite inspectandadapt.de. Welche Erfahrungen hast Du als Product Owner im Konzern bislang gesammelt? Wie lässt sich die Product Owner Verantwortung im Konzernumfeld leben? Falls du den einen oder anderen Aspekt deiner Insights oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Oliver & Dominique im Gespräch In vielen der vorherigen Podcastfolgen haben wir immer wieder einzelne Verhaltensmuster von Product Owner*innen angesprochen, die wir als Produktwerker eher kritisch sehen. Daher war es an der Zeit, eine Episode zu veröffentlichen, in denen Dominique und Oliver einmal viele relevante Antipattern an einer Stelle zusammenfassen. So bekommst Du als PO die Chance, diese Antipattern mit Deinem Verhalten zu vergleichen und ggf. kritisch zu hinterfragen, ob Du an dem einen Muster arbeiten möchtest. Die beiden klären zuerst ihr Verständnis von Antipattern, unter denen sie Lösungsansätze verstehen, die ungünstig oder schädlich für den Erfolg der eigenen Produktentwicklung oder des eigenen Unternehmens sind. Dabei unterteilen Oliver und Dominique diese PO Antipattern in drei Bereiche: eigenes Verhalten, Zusammenarbeit mit den Developer bzw. Produktentwicklungsteam und Kommunikation mit den Stakeholdern. Wir üblich versuchen die beiden auch ganz konkrete Beispiele aus ihrer eigenen Erfahrung sowie Tipps und Tricks zu nennen, wie ich an mir als Product Owner:in arbeiten kann, um wirksamer in meiner Rolle zu werden. ANDERE PODCASTFOLGEN, AUF DIE VERWIESEN WIRD Nein sagen als Product Owner Dein Freund der Scrum Master Seine Stakeholder kennen und richtig analysieren Epic. Sinnvoll oder nicht?

Tilman Büttner im Gespräch mit Dominique Wer sich in der UX-Community bewegt, kam in den letzten Monaten nicht um das Thema UX-Writing herum. Durch den richtigen Text an der richtigen Stelle soll das Nutzererlebnis verbessert werden. Grund genug, dass wir mal einen tieferen Blick in das Thema werfen und uns auch fragen, wie Product Ownern, Product Managern und Product Leadern UX-Writing helfen kann, bessere Produkte zu entwickeln. In dieser Folge spricht Dominique mit Tilman Büttner (https://www.linkedin.com/in/tilmanbuettner/), Senior UX Writer der Modulr.Design GmbH und Mitglied des Arbeitskreises UX-Writing der German UPA (https://germanupa.de/arbeitskreise/arbeitskreis-ux-writing), dem Berufsverband der deutschen UX-Professionals. Tilman erklärt, was UX-Writing ist und wie es sich beispielsweise vom klassischen Texten unterscheidet. Dabei wird schnell klar, dass sich hierbei ein großes Potenzial für den Erfolg oder Misserfolg von Produkten ergibt. Das beliebteste Beispiel sind Darstellungen eines Produkts ohne seine textlischen Inhalte. Da versteht man schnell, dass Bilder alleine nicht ausreichen und das jedes Wort relevant sein kann. Daher sprechen die beiden auch darüber, wie man eigentlich gute Texte für das eigene Produkt schreibt. Beispielsweise ist die Tonalität wichtig. Dabei zeigt sich auch der klare Bezug zum Beispiel zur UX-Vision (https://produktwerker.de/ux-vision/) und dem absichtsvollen Gestalten der User Experience. Aber wie immer gibt es einige Fehler, die vermieden werden können. Über diese spricht Tilman in der Folge ausführlich und gibt uns somit Tipps und Tricks, wie wir einerseit smit UX-Writern zusammenarbeiten sollten aber auch wie wir notfalls ohne UX-Writer wenigstens etwas bessere Texte verfassen können. Wer über diese Folge hinaus noch Unterstützung sucht, dem sei die kostenlose Einführung ins UX Writing vom "UX Writing Hub" (https://course.uxwritinghub.com/free_course) empfohlen. Auch der Blog auf derselben Website ist für Interessierte empfehlenswert. Ein paar weitere praktische Tipps gibt es darüber hinaus auf der Website der Nielsen Norman Group (https://www.nngroup.com/articles/ux-writing-study-guide/). In einer langen Serie aus Artikeln und Videos bereitet sie das Thema gut verständlich auf.

Dominique & Oliver im Gespräch Als Product Owner kann ich im Alleingang niemals erfolgreich sein. Ohne Team bist Du nichts! Grund genug, für Dominique und Oliver einmal auf die Bedeutung des Teams für Product Owner zu schauen. Die beiden diskutieren dabei sowohl über die Developer– als auch über die Stakeholder–Seite und geben wie immer eine ganze Reihe von Tipps und Tricks aus der eigenen Praxis. Natürlich ist es spannend, was der Scrum Guide zum Team sagt und welche Auswirkungen dies auf die Arbeit der Product Ownerin hat. Besondere Wichtigkeit kommt der Zusammenstellung des Teams und der Fähigkeiten / Skills der eigenen Teammitglieder zu. Hier motivieren Oliver & Dominique, sich als PO einzumischen und zu positionieren, damit wir im möglichst optimalen Kontext unterwegs sein können. Mit Unterstützung des Scrum Masters müssen wir uns alle weiterentwickeln. Dabei ist das Mindset der Teammitglieder von Bedeutung, die beiden empfehlen eher auf interessierte, lernwillige Allrounder mit einer besonderen Expertise zu setzen als auf Spezialisten.

Sohrab Salimi im Gespräch mit Tim Die Transformation hin zum Product Operating Model ist das neue zentrale Thema von Marty Cagan seit diesem Sommer. Er hat es Ende Juli in London im Rahmen des TRANSFORMED Workshops vorgestellt. Unser heutiger Gesprächsgast Sohrab Salimi war vor Ort in London und tauscht sich dazu mit Tim Klein. Tim war seinerseits im letzten Jahr drei Tage im Coach-the-Coaches Retreat von und mit Marty Cagan und seinen Kollegen der svpg. Dort wurden die ersten Ansätze zum Product Operating Model auch schon angesprochen. Das ganze wird sich dann ab kommendem Frühjahr (vermutlich März 2024) im neuen Marty Cagan Buch "TRANSFORMED" nachlesen lassen. Von Sohrab, der ein sehr gern bei uns gesehener und somit wiederkehrender Gast bei uns im Podcast ist, können wir also quasi von echtem Insider-Wissen, zumindest aber mit Infos aus erster Hand, profitieren. Falls ihr Sohrab noch nicht kennt: Sohrab ist Gründer & CEO der Scrum Academy GmbH und seit fast zehn Jahren Certified Scrum Trainer® sowie Certified Agile Leadership Educator der Scrum Alliance, wo er bis Ende 2020 Mitglied des Board of Directors war. Wer noch mehr wissen möchte, hört sich am besten nochmal eine der weiteren Folgen mit ihm an: Sohrab Salimi in Folge 11: "Product Owner als Agile Leader" Sohrab Salimi in Folge 54: "Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen?" (mit Markus Andrezak) Weitere passende Quellen zum Product Operating Model Vortrag von Marty Cagan "Moving to the product operating model" im Webinar der Product-Led Alliance Weitere Vorab-Infos zum kommenden Buch von Marty Cagan "TRANSFORMED" "10 takeaways from a day spent with 50 European product leaders talking about ‘Transforming to the Product Model’" - von Product Coach Nick Jemetta, den Tim letztes Jahr beim Coach-the-Coaches Event von Marty Cagan kennengelernt hat Agile Insights Interview von Sohrab Salimi im Gespräch mit Marty Cagan: Product Leadership Teresa Torres bei Product at Heart: Even You Can Do Continuous Discovery. Bringing the Discovery Habits to Every Organization Wenn du mit Sohrab Salimi direkt in Kontakt treten möchtest, folge ihm am Besten auf LinkedIn oder kontaktiere ihn über sein LinkedIn-Profil. Eine weitere Empfehlung ist seinen regelmäßigen LinkedIn-Newsletter zu folgen. Hier teilt es immer wieder (i.d.R. wöchentlich) tolle Leadership Tipps und Gedanken. Hast du bereits vom Product Operating Model gehört? Oder seid ihr anderweitig auf der Transformationsreise zu einem produktzentrierten Organisationsmodell? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Tim & Dominique im Gespräch "Wie groß ist ein Epic?" oder "Ab wann ist eine User Story ein Epic?" - mindestens eine dieser beiden Fragen hören wir tatsächlich in quasi jedem Training, wenn es um die Arbeit mit User Stories oder Product Backlog Management geht. Offenbar besteht einiges an Unsicherheit rund um dieses Thema. Also haben sich Tim und Dominique das Thema "Epic" in dieser Episode mal vorgeknöpft. Sie klären nicht nur den Unterschied zu User Stories, sondern erzählen auch vom historischen Hintergrund des Begriffs. Die Frage lautet nämlich eigentlich viel eher: Warum gibt es keine Saga und Novel mehr? …zumindest in Jira haben es diese anderen Begriffe nicht geschafft. Tim folgt eher die These (von Mike Cohn): "eine Story ist eine Story, ist eine Story…" Demnach ist ein Epic nur ein Label oder Kunstbegriff für eine sehr große Story. Aber andersrum: Wenn wir Stories aufteilen bzw. splitten, entstehen daraus doch ja auch nur wieder Stories. Und selbst wenn diese nochmals geschnitten werden müssen, kommen doch wieder nur (kleinere) Stories dabei heraus. Warum wir "nach oben" denn dann so ein "mythischer" Begriff verwendet. Dominique nutzt hingegen gerne Epics und berichtet im Gespräch davon ausführlich. Auch ein Umgang mit Epics in Jira wird von ihm entsprechend erläutert. Besonders spannend dürfte sein, was er macht, wenn nicht alle User Stories eines Epics umgesetzt werden. Einig sind sich beide, dass ein Epic einen Wert liefern muss. Es sei der Hinweis erlaubt, dass es im Skalierungs-Framework SAFe explizit den Begriff Epic verwendet. Dort ist es eine "significant solution development initiative") und es werden Business Epics und Enabler Epics unterschieden. Eine weitergehende Erklärung gibt es hier. Tim und Dominique gehen in dieser Episode aber bewusst nicht näher auf den Epic-Begriff in SAFe ein, sondern konzentrieren sich auf die aus dem Extreme Programming (XP) stammende Herkunft des Begriffes. Lieber beleuchten die beiden nämlich, welche Vorteile, aber auch welche Herausforderungen in der Arbeit mir Epics gibt. Und es ist auch spannend zu diskutieren, was denn fehlen würde, wenn man ganz auf die Verwendung von Epics verzichten würde. Wie in unserem Format üblich schließt die Folge mit einigen Tipps & Tricks zu diesem Thema. Passende Podcast-Folgen zum Thema "Epic" Erfolgreich mit User Stories arbeiten User Story Splitting: Wie geht das "richtig"? Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? Feature Breakdown: schnell User Stories finden und grob schätzen Passende Themen in unserer Produktwerker Box: In der Produktwerker Box findest du zu den typischen Herausforderungen von Product Ownern von uns empfohlene Literatur, Artikel, Videos, Tools, Übungen etc. - ein Blick in folgende Themenbereiche lohnt sich im Kontext dieser Episode: Gute User Stories schreiben bzw. formulieren User Story Splitting: Anforderungen schneiden Wie sind deine Erfahrungen mit Epics? Hast du vielleicht eine andere Sicht oder arbeitest ganz anders mit Epics als wir berichtet haben? Vielleicht hast Du auch spezielle Tipps zum Umgang mit Epics in den diversen Tools: Jira, Azure DevOps (Team Foundation Server), Redmine, Trello, Asana, … Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]