product backlog

"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: https://scaledagileframework.com/epic/. 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 In der Produktwerker Box (https://produktwerker.de/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

In dieser Folge unterhält sich Dominique mit Roman Pichler über das Thema Produktstrategie. Roman hat gerade erst eine neue Auflage seines Buchs Strategize veröffentlicht und die beiden nehmen dies zum Anlass, um über dieses wichtige Thema zu sprechen. Roman sieht dabei die Produktstrategie als einen Plan bzw. den Weg wie man eine Produktvision erreichen möchte. Die beiden sprechen auch über die Probleme beim Entwickeln von Strategien. Oft beobachtet Roman beispielsweise, dass in einer Organisation gar nicht richtig klar ist, was das Produkt ist. Daneben sieht er auch eine fehlende Bevollmächtigung der Produktmanager bzw. Scrum Product Ownern. Aus der Produktstrategie werden dann Teilziele abgeleitet und eine zielorientierte Roadmap entwickelt. Mit Hilfe der zielorientierten Roadmap können Entwicklungsteams angeleitet und Stakeholder miteinander abgestimmt werden. Von Feature Roadmaps rät Roman dabei aber explizit ab, da es ihm weniger um die Auslieferung von Features geht, sondern mehr um das Erreichen von Zielen. Ein besondere Idee hat Roman noch für die Überführung der Strategie ins Product Backlog. Das aktuelle Product Goal wird als alleiniges Kriterium für die Elemente im Product Backlog genommen und nur Elemente, die auf dieses Ziel einzahlen sollten im Backlog aufgenommen werden. Damit wird das Product Backlog recht schlank aber sehr auf das Produktziel fokussiert. Roman war bereit einmal bei uns zu Gast und hat darüber gesprochen, welche Herausforderungen und Praktiken bestehen, um als Product Owner zu führen (https://produktwerker.de/how-to-lead-in-product-management/). Wenn euch das Thema Produktstrategie interessiert, empfehlen wir euch noch folgende Folgen: - The Product Field (https://produktwerker.de/product-field/) - Eine Produktstrategie entwickeln (https://produktwerker.de/produktstrategie-entwickeln/) - Wardley Mapping - Produktstrategie ist wie Schach (https://produktwerker.de/wardley-mapping/)

In dieser Folge unseres Product Owner Podcast sprechen Dominique & Oliver über die agile Praktik Magic Estimation. Und natürlich legen sie den Fokus ihrer Diskussion auf den besonderen Nutzen dieser Schätzmethode für Produkt Owner. Die Idee geht ursprünglich auf einen Vorschlag von Lowell Lindstrom aus dem Jahr 2008 zurück. Er nannte seine Idee „Affinity Estimation“. Boris Gloger griff den Ansatz auf und überarbeitete diesen zu Magic Estimation. Das Magische: sehr viele Product Backlog Items in sehr kurzer Zeit durchschätzen, um beispielsweise für ein bestimmtes Release eine grobe Idee zu einem Termin abgeben zu können. Dominique erläutert, wie er eine solche magische Schätzsession vorbereitet und dann mit dem Team durchführt. Er teilt viele hilfreiche Tipps und Tricks, die auch die Aufgaben eines Product Owners nach einer solchen Session betreffen: Wir überführe ich die Schätzungen ins Product Backlog? Und warum macht es Sinn, die Ergebnisse der Schätzungen im Product Backlog besonders zu markieren?

Durch das Refinement wird das Product Backlog zu einem gut gepflegten Product Backlog und ist dadurch ein wichtiges Werkzeug für Product Owner. Tim und Dominique unterhalten sich in dieser Folge über das Refinement des Product Backlogs und welche Bedeutung es für uns als Product Owner hat. Zu Beginn klären wir erst einmal, was Refinement eigentlich ist und wie es in Scrum passt. Das Refinement wird zwar oft als Termin gesehen, ist aber eigentlich ein Prozess. Deshalb sprechen wir über den allgemeinen Ablauf des Refinements, wer alles mitwirkt und was wir als Product Owner vorbereiten sollten. Wir sind nämlich davon überzeugt, dass wir neben Vision und Product Goal auch eine aktuelle Roadmap dabei haben sollten. Dank dem Refinement haben wir dann nicht nur ein gepflegtes Product Backlog; wir erhalten auch neuen Input für die Priorisierung von Product Backlog Items und erlangen ein Verständnis über Umfang, Kosten, Risiken und anderer Aspekte der ganzen Backlog Items. Wir können daher dank des Refinements bessere Entscheidungen treffen. Und wie in jeder Folge wollen wir mit ein paar Tipps abschließen. Habt ihr beispielsweise mal daran gedacht das Refinement eines bestimmten Themas als Product Backlog Item einzuplanen, damit im nächsten Sprint an diesem Thema gearbeitet wird? In der Folge erwähnen wir übrigens kurz das Product Backlog Refinement Canvas, eine gut geeignete Vorlage, um sich eine strukturierte Übersicht zu machen. Ihr findet es unter https://www.kaizenko.com/the-product-backlog-refinement-canvas/ Wenn ihr noch mehr über das Product Backlog hören wollt, dann empfehlen wir euch die folgenden Folgen: - Das Product Backlog (https://produktwerker.de/product-backlog/) - Ist dein Product Backlog voll bzw. zu groß? (https://produktwerker.de/product-backlog-voll/) - Product Backlog Einträge sind nicht nur User Stories! (https://produktwerker.de/product-backlog-eintraege/) Wenn euch dieser Podcast gefällt, freuen wir uns auch über eine positive Bewertung in eurer Podcast App oder als Feedback per Mail an podcast@produktwerker.de oder via Instagram oder Twitter (@produktwerker).

Jeder macht Fehler und jeder sammelt Erfahrungen. Wie oft denken wir uns dabei, hätten wir das doch früher gewusst. Als das einem von uns vor kurzem wieder mal passiert ist haben wir uns entschieden unsere bisherigen Erfahrungen zu reflektieren und zu sammeln, was wir gerne zu Beginn gewusst hätten. Daher sprechen Oliver und Dominique in dieser Folge über all die Erkenntnisse und Erfahrungen, die sie gerne vorher gewusst hätten. Sie sprechen über Themen wie dem Schnitt der eigenen Verantwortung, die Gesamtheit aller Aufgaben, den eigenen Wirkungskontext, Nutzen verschiedener Backlogs, den Umgang mit anderen Disziplinen und vielem mehr. Im Gespräch verweisen die beiden auf das Buch "Escaping the Build Trap: How Effective Product Management Creates Real Value" von Melissa Perri. In diesem geht es vor allem darum nicht immer nur neue Features zu bauen, sondern das Produkt als Ganzes weiterzuentwickeln und ggf. auch mal Features zu entfernen, wenn sie keinen Mehrwert liefern. Was die Rolle als Product Owner angeht referenziert Oliver auf das "POEM", ein Instrument zum besseren Verständnis der Product Ownership. Mehr dazu findet ihr hier: https://productownership.de/poem/ Und nun ist es auch an euch eure Erfahrungen zu teilen. Was hättet ihr gerne vorher schon gewusst?

Wie groß sollte eigentlich ein Product Backlog sein? Auch wenn es auf diese Frage keine konkret quantifizierbare Antwort gibt, widmen wir uns diesmal dem Problem, dass das Backlog "zu groß" ist. Dominique und Tim diskutieren zunächst, was für sie selbst "zu groß" wäre. Dann gehen sie den Gründen nach, warum ein Product Backlog explodiert sein könnte. Natürlich kann ein simpler Grund auch sein, dass man als Product Owner ein bestehendes Product Backlog übernimmt, was bereits überquellt. Und wie bekomme ich das Problem wieder in den Griff? Welche Tipps und Praktiken gibt es also, um das Backlog wieder zu verkleinern? Zudem diskutieren Tim und Dominique, mit welchen Strategien ich vorsorgen kann, damit das Product Backlog nicht zu voll wird bzw. nicht zumüllt. In dieser Episode genannte Quellen: - Roman Pichler: Be a Balanced Product Leader, not a Feature Broker or Product Dictator Im Zusammenhang mit Product Backlog Management solltet ihr auch diese Podcast Folgen anhören: - Das Product Backlog - Features wegwerfen - was braucht es dafür außer Mut? - Product Backlog Einträge sind nicht nur User Stories! - Story Mapping nutzen, um über Outcome zu sprechen Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

User Stories werden von vielen Product Ownern ihren Product Backlogs als eine Form von Product Backlog Items genutzt. Aus der Perspektive von Nutzern beschreiben wir so den Mehrwert, den wir mit unseren Produkten ermöglichen wollen. Allerdings gibt es einige Herausforderungen beim Verwenden dieses Formats. Darum unterhalten sich Dominique und Tim in dieser Folge über User Stories als Möglichkeit Anforderungen zu formulieren und klären welche Vorzüge dieses Vorgehen hat und welche Herausforderungen gemeistert werden müssen. Diese Folge verweist u. A. auf folgende Folgen des Podcasts: - Akzeptanzkriterien richtig einsetzen: https://produktwerker.de/akzeptanzkriterien-richtig-einsetzen/ - Product Backlog Einträge sind nicht nur User Stories: https://produktwerker.de/product-backlog-eintraege/ - Story Mapping nutzen, um über Outcome zu sprechen: https://produktwerker.de/story-mapping/ Literatur/Quellen: - User Stories - für die agile Software-Entwicklung mit Scrum, XP u.a.https://www.mountaingoatsoftware.com/books/user-stories-applied - Fifty Quick Ideas to Improve Your User Stories: https://gojko.net/books/fifty-quick-ideas-to-improve-your-user-stories/ - Specification by Example - How Successful Teams Deliver the Right Software: https://gojko.net/books/specification-by-example/ - User Story Mapping - Nutzerbedürfnisse besser verstehen als Schlüssel für erfolgreiche Produkte: https://www.amazon.de/Mapping-Nutzerbed%C3%BCrfnisse-verstehen-Schl%C3%BCssel-erfolgreiche/dp/3958750672 - Persona-driven User Stories: https://www.designik.de/2015/03/persona-driven-user-stories/

Über Product Backlog Einträge sagt der Scrum Guide nur, es seinen "Dinge, die zur Produktverbesserung benötigt werden." Neben User Stories gibt's also noch andere Arten von Product Backlog Einträgen (mache sagen auch Product Backlog Items - kurz: PBI). Ein weit verbreitetes Missverständnis und Anti-Pattern behauptet zudem, ins Product Backlog würden nur User Stories gehören. Aber User Stories sind gar kein Bestandteil des Scrum Frameworks und demnach können auch andere Arten von Product-Backlog-Einträgen (englisch: Product Backlog Items) im Product Backlog enthalten sein. Wir beleuchten in dieser Folge daher mal, welche Arten von Product-Backlog-Einträgen es geben kann und wie man sie klassifizieren könnte. Neben Bugs (Defects) müssen ggf. ja auch sog. "technische Aufgaben" (technical tasks) am Produkt vorgenommen werden. Viele Teams sind aber auch unsicher, wie sie mit Analysen oder organisatorischen Aufgaben umgehen sollen. Letztlich gucken wir uns auch übliche Anti-Patterns an und teilen unsere Haltung mit Euch. Insgesamt ist ein bunter Ritt entlang von User Stories, Bugs, Analyseaufgaben und technische Tätigkeiten entstanden. Im Zusammenhang mit dieser Episode empfehlen wir Euch, ggf. auch nochmal diese Podcast-Folgen anzuhören: - Das Product Backlog - Akzeptanzkriterien richtig einsetzen - Warum Personas für Product Owner wertvoll sind - Das Product Goal und seine Bedeutung für Product Owner Wenn euch die Folge gefällt freuen wir uns über eine positive Bewertung in Apple Podcasts, Spotify, in eurem Podcatcher oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Das Product Backlog gehört zu den wichtigsten Artefakten eines Produkts und damit auch der Arbeit eines Product Owners. Darum sprechen Dominique und Oliver in dieser Folge darüber was das Product Backlog ist, wer dafür verantwortlich ist und was das Product Backlog Management alles umfasst.

Nach einiger Zeit sitzen wir – Daniel und David – mal wieder gemeinsam im virtuellen Studio und nehmen uns in dieser Episode das Product Backlog vor. Wie immer erst einmal aus der Vogelperspektive: Was kann man sich überhaupt unter einem „Product Backlog“ vorstellen, wie funktioniert es und warum ist es ein so zentraler Teil von Scrum und agilem Arbeiten. Im Anschluss wird der Scrum Guide ausgepackt und wir erläutern einige wichtig Details, die im Scrum Guide stehen und in einigen Scrum Teams auch mal gerne übersehen werden. Mit einigen praktischen „don´ts“ schließen wir dann die Folge ab. Viel Spaß beim Hören.