Podcasts about product backlog

The final ingredient of my Agile-inspired personal productivity system is the cool-off week. In this video, I share its origin story, explain what it is, describe what I do during this week, and reveal why it has been the key to staying consistent with my productivity system for the last 10 years.The Calm Ambition Club: https://monthlymethod.com/calm-ambition-club/Blogpost mentioned:When feeling down, turn to aesthetics https://monthlymethod.com/aesthetics/Timeline:00:00 - Why I invented the cool-off week01:44 - What is a cool-off week?03:30 - What's the point of a cool-off week?05:03 - I'd rather take the breaks on my own terms06:33 - What do I do during the cool-off week?09:50 - Benefit: No burnout in the last 10 years10:52 - Benefit: Gult-free rest11:31 - Benefit: Looking forward to the next sprint13:27 - Benefit: Interesting projects get done15:07 - Benefit: Time and space to think15:42 - Benefit: Serves as a reward for my long-term efforts18:17 - Benefit: Creates a nice rhythm in my life19:30 - If you want to actually DO the things you want to do. Learn how to apply Agile to your life in a free course: http://monthlymethod.com/school/If you want to stay in touch:

Sprint retrospective is the most important ritual in Agile philosophy. I'll share how you can build your own goal management system that is perfectly tailored to your life circumstances. The Calm Ambition Club: https://monthlymethod.com/calm-ambition-club/Blog posts mentioned:Sprint-end celebration https://monthlymethod.com/sprint-end-celebration/The baby shower story https://monthlymethod.com/failed-sprint-goals/Optimizing life for a regular Tuesday https://monthlymethod.com/regular-tuesday/Timeline:00:00 - Overview00:38 - What is a sprint retrospective?01:07 - The shocking part02:58 - Agile take on growth04:03 - Sprint retrospective in teams05:48 - Personal sprint retrospective07:17 - Becoming your own guru and building your own system08:51 - Cathedral Effect09:18 - What got done?10:46 - What didn't get done?13:01 - How accurate was your sprint capacity calculation?13:38 - Quality of life review14:48 - Creating a Notes file for sprint retrospectives15:50 - Example: Deeper Why18:55 - Don't add to your to-do list20:08 - Example: Making a promise21:44 - Example: Leaving my phone at home22:51 - Example: Reddit goal25:54 - Going a level deeper into why we should do sprint retrospectives26:54 - Life craftsmanship. The art of living. 28:50 - Curation in a function of time. Learn how to apply Agile to your life in a free course: http://monthlymethod.com/school/If you want to stay in touch:

Die Granularität, oder auch Kleinteiligkeit, von Product Backlog Items ist eine ständige Herausforderung für Product Owner. Manchmal sind die Product Backlog Items zu groß oder man leider unter viel zusätzlicher Verwaltungsarbeit, weil immer wieder ganze Pakete an kleinteiligen Items repriorisiert werden müssen. Das zentrale Thema der Folge ist also die Größe eines Backlog Items. Während der Scrum Guide lediglich fordert, dass Einträge innerhalb eines Sprints abgeschlossen sein sollten, empfehlen Dominique und Oliver eine zusätzliche Regel: Ein Item sollte nicht mehr als die Hälfte des Sprints in Anspruch nehmen. Diese Daumenregel hilft dabei, das Risiko zu minimieren, dass sich ein einzelnes Item über den gesamten Sprint zieht und zu wenig Spielraum für Anpassungen bleibt. Doch Granularität ist nicht nur eine Frage der Planung, sondern auch der langfristigen Produktstrategie. Items, die erst in ferner Zukunft relevant sind, können zunächst grob formuliert sein. Je näher der Umsetzungstermin rückt, desto feiner werden sie definiert. Oliver betont, dass eine zu frühe Detailierung oft überflüssig ist, weil sich Prioritäten im Laufe der Zeit ändern. Das Zusammenfassen und Neuformulieren von Items kann deshalb ebenso sinnvoll sein wie das Zerteilen größerer Einträge. Ein weiteres Thema ist die Handhabung von Granularität im Sprint. Unterschiedlich große Items innerhalb eines Sprints sind kein Problem, solange sie alle einen Mehrwert liefern und das Team die Zusammenhänge versteht. Eine gesunde Mischung aus kleinen, mittleren und größeren Items kann sogar dabei helfen, besser zu lernen und das Forecasting zu verbessern. Ein rein auf gleich große Einträge ausgerichtetes Backlog – wie es beim No Estimates-Ansatz oft gefordert wird – kann zwar die Vorhersagbarkeit erhöhen, schränkt aber unter Umständen die Flexibilität ein. Die Diskussion zeigt, dass Product Owner die Granularität ihrer Backlog Items bewusst steuern sollten. Refinement-Aktivitäten sind notwendig, um sicherzustellen, dass ein gemeinsames Verständnis im Team herrscht. Dabei ist jedoch auch Mut zur Lücke gefragt: Nicht jedes Item muss bis ins kleinste Detail ausformuliert werden. Gerade bei sehr kleinen Verbesserungen kann es sinnvoller sein, sie direkt umzusetzen, anstatt sie ins Backlog aufzunehmen. Letztlich ist die optimale Granularität immer vom jeweiligen Produkt und Team abhängig. Product Owner sollten sich bewusst machen, dass sie nicht nur für den Inhalt des Backlogs verantwortlich sind, sondern auch für seine Struktur und Handhabbarkeit.

In this Ask a Professional Scrum Trainer episode, Patricia Kong moderates a discussion with Simon Flossmann and Stas Pavlov tackling listener questions on the challenges of Product Backlog Management. They explore techniques for prioritization, balancing technical debt, and improving transparency with stakeholders. From leveraging the Kano model and Magic estimation to using tools like Miro and Monte Carlo simulations for forecasting, they provide actionable insights to help teams refine their backlog effectively. Tune in for expert advice on optimizing backlog management for better product outcomes!

Why the advice to disappear for a year is problematic. And what you can do instead. Enrollment for the Calm Ambition Club - February sprint closes tomorrow https://monthlymethod.com/calm-ambition-club/Chapters:00:00 - YouTube, we have a problem01:23 - The only way to change our lives02:04 - What happens if you manage to disappear for a year?03:00 - My favourite quote03:43 - Celebrating limitations06:26 - If you were feeling hopeless07:56 - On young generation being lost08:46 - If you can't escape your lifeIf you want to stay in touch:

Alle, die Scrum Master oder Product Owner werden wollen und mehr über die Prüfung erfahren wollen, kommen in dieser Folge voll auf ihre Kosten. Ich bespreche mit Kim Berger über die verschiedenen Möglichkeiten der Scrum Zertifizierung und wir pauken mit euch ein bisschen. Perfekte Prüfungsvorbereitung für Selbstlerner, perfekter Einstieg für alle, die sich mal erkundigen wollen, was so ein Zertifikat denn genau ist. Viel Spaß beim Hören und beim Pauken :) Fragebogen zum Herunterladen: https://www.dropbox.com/scl/fi/ej8ugbzidef1ygjn0dez4/Scrum-Testfragen.pdf?rlkey=163fxef6erngr8hyt1n8lwmam&st=9s0jdbk4&dl=0 Probefragen, die wir besprechen: What are three ways Scum promotes self-management? (Choose the best three answers) A, B, D A - By removing titles from Scrum Team members. B - By being a lightweight framework. C - By having the Scrum Master protect the Scrum Team from interruptions. D - By the Scrum team deciding what work to do in a Sprint Several Sprints into a project, the Product Owner tells the Scrum Master that a key stakeholder just started using the product. The stakeholder is unhappy with the quality of the product, and the Product Owner agrees with the stakeholders assessment that the quality is low. How should the Scrum Master respond to the Product Owner? B, C A - Explain to the Product Owner that it is up to the Developers to decide on acceptable quality standards B - Encourage the Product Owner to include quality specifications in the Product Backlog and to communicate the stakeholders concerns to the developers C - Work with the Product Owner to understand their desired resolution and help formulate an approach for raising the concern with the Developers D - Bring the concern to the testers to improve how the Product is verified E - Tell the Product Owner they have noted the concern and will raise this issue at the Sprint Retrospective When does a Developer become accountable for an item in the Sprint Backlog? (Choose the best answer) C A - At Sprint Planning when all of the Sprint Backlog items are split evenly across the Developers B - During the Daily Scrum C - Never. All Developers on the Scrum Team share accountablility for items in the Sprint Backlog D - As soon as a Developer oh the Scrum Team can accommodate more work An increment must be released to customers or users at the end of each sprint True False

Scrum com Escopo Fechado: Uma Análise Crítica A afirmação de que usar o Scrum com escopo fechado é mais tranquilo pode parecer intuitiva à primeira vista, mas requer uma análise mais profunda para entender suas implicações e desafios. Em um projeto com escopo fechado, os requisitos e funcionalidades são definidos de forma rígida no início do projeto. Isso significa que as mudanças são limitadas e qualquer alteração pode gerar impactos significativos no cronograma e no orçamento. O Scrum, por sua vez, é uma metodologia ágil que valoriza a flexibilidade, a adaptação às mudanças e a entrega incremental de valor. A ideia de um escopo fechado contrasta com os princípios ágeis, que buscam responder às mudanças e às necessidades dos clientes de forma rápida e eficiente. Por que pode parecer mais tranquilo usar o Scrum com escopo fechado? Certeza inicial: Um escopo bem definido pode proporcionar uma sensação de segurança e previsibilidade no início do projeto. Facilidade de planejamento: Com um escopo fechado, é mais fácil criar um plano detalhado e estimar o tempo necessário para cada tarefa. Menor pressão por mudanças: A resistência a mudanças pode ser menor, pois o escopo já está definido. No entanto, quais são os desafios e riscos de usar o Scrum com escopo fechado? Rigidez: O escopo fechado pode limitar a capacidade de responder às mudanças e às novas necessidades dos clientes. Perda de oportunidades: Novas ideias e tecnologias podem surgir durante o desenvolvimento, mas podem não ser exploradas devido ao escopo fechado. Dificuldade em lidar com incertezas: Projetos de software são inerentemente incertos, e um escopo fechado pode não ser capaz de lidar com essa incerteza. Diminuição da colaboração: A equipe pode se tornar menos colaborativa e mais focada em cumprir o escopo definido, em vez de buscar soluções inovadoras. O Scrum é mais eficaz quando: Há um alto grau de incerteza: O Scrum permite que a equipe se adapte às mudanças e às novas informações à medida que o projeto avança. O cliente está envolvido: A colaboração contínua com o cliente garante que o produto esteja alinhado com as suas necessidades. A equipe é auto-organizada: A equipe tem autonomia para tomar decisões e resolver problemas. Em vez de um escopo fechado, o Scrum sugere: Um Product Backlog: Uma lista priorizada de itens a serem desenvolvidos, que pode ser constantemente refinada e atualizada. Sprints: Ciclos curtos de desenvolvimento, nos quais a equipe entrega um incremento de software funcional. Revisão do produto: Uma oportunidade para o cliente fornecer feedback e validar o trabalho realizado. Retrospectiva: Uma reunião para a equipe refletir sobre o processo e identificar áreas de melhoria. Conclusão Usar o Scrum com um escopo fechado pode parecer mais tranquilo a curto prazo, mas pode levar a problemas a longo prazo. A flexibilidade e a adaptação são características essenciais do Scrum, e um escopo fechado pode limitar essas capacidades. Para obter o máximo benefício do Scrum, é recomendado: Adotar um Product Backlog priorizado: Isso permite que a equipe se adapte às mudanças e entregue valor de forma incremental. Realizar revisões regulares com o cliente: Garanta que o produto esteja alinhado com as necessidades do cliente. Promover a colaboração e a autonomia da equipe: Incentive a equipe a tomar decisões e a encontrar soluções inovadoras. Em resumo, o Scrum é mais eficaz quando combinado com um escopo adaptável, permitindo que as equipes respondam às mudanças e entreguem produtos de alta qualidade que atendam às necessidades dos clientes. O que é um Escopo Fechado?Scrum e Escopo Fechado: Uma Contradição?

Cost of Delay, auf Deutsch Verzögerungskosten, beschreibt die wirtschaftlichen Verluste, die entstehen, wenn ein Produkt oder Feature später als geplant auf den Markt kommt. In der neuen Folge von der Produktwerker diskutieren Tim und Dominique, warum dieses Konzept für Product Owner zentral ist und wie es uns bei strategischen Entscheidungen helfen kann. Dominique definiert Cost of Delay als die Summe aller wirtschaftlichen Kosten, die durch Verzögerungen entstehen. Das reicht von entgangenen Umsätzen und Marktanteilen bis hin zu Lizenz- oder Wartungskosten für alte Systeme. Ein Beispiel zeigt, wie ein verspäteter Systemwechsel zu Millionen Euro zusätzlichen Lizenzgebühren führen kann. Aber auch weiche Faktoren wie verlorene Marktreputation oder Kundenzufriedenheit können in die Bewertung einfließen. Besonders praktisch wird Cost of Delay bei der Priorisierung von Backlog-Items. Features können wie verderbliche Waren betrachtet werden: Je später sie geliefert werden, desto geringer ihr Nutzen. Um das zu quantifizieren, benötigt man eine klare Formel. Ein gängiger Ansatz ist, die Kosten pro Zeiteinheit zu berechnen, zum Beispiel pro Woche oder Sprint, und diese durch die Größe der Arbeit zu teilen. Dieser Ansatz ähnelt dem Konzept Weighted Shortest Job First (WSJF). In der Praxis ist jedoch nicht immer alles messbar. Dominique und Tim betonen, dass Schätzungen oft auf Annahmen basieren müssen. Dabei geht es nicht um absolute Genauigkeit, sondern um eine Diskussion, die ein gemeinsames Verständnis schafft. „Es ist besser, mit unscharfen Daten zu arbeiten, als gar keine Grundlage zu haben“, so Dominique. Wichtig sei es, Annahmen zu dokumentieren und regelmäßig zu überprüfen. Darübe rhinaus ist ein weiterer spannender Aspekt die enge Verbindung zwischen Cost of Delay und der Produktstrategie. Unternehmen müssen abwägen, ob sie lieber schnell liefern oder auf Perfektion setzen wollen. Diese Entscheidung hat nicht nur Einfluss auf die Priorisierung einzelner Aufgaben, sondern auch auf die langfristige Marktpositionierung. Die Folge schließt mit wertvollen Tipps für den Einstieg in das Thema Cost of Delay. Tim und Dominique raten dazu, sich zunächst auf einfache Annahmen zu stützen und diese regelmäßig zu überprüfen. Denn nur wer die Kosten von Verzögerungen versteht, kann nachhaltig erfolgreiche Produkte entwickeln. Passend zur aktuellen Folge empfehlen wir euch übrigens noch diese Folge, weil sie thematisch sehr passen und in der Folge referenziert werden: - Technische Schulden und wie wir als Product Owner damit umgehen (https://produktwerker.de/technische-schulden/) - Flow Metriken für Scrum Product Owner (https://produktwerker.de/flow-metriken/) - Product Principles (https://produktwerker.de/product-principles/) - Produktstrategie in die Praxis bringen (https://produktwerker.de/produktstrategie-in-die-praxis-bringen/)

Send us a textIn this episode of Definitely Maybe Agile, Peter Maddison and David Sharrock explore the nuances of product backlogs in agile environments. They discuss the tension between emergent backlogs and fixed feature sets, the importance of backlog management, and various prioritization techniques, including "buy a feature" and impact-effort matrices.This week's takeaways:Separate tactical (near-term) and strategic backlogs to reduce psychological pressure and maintain focus - avoid creating extensive long-term backlogs that will likely become irrelevant.Stakeholder prioritization must be balanced with technical constraints and team capabilities - product owners should communicate changes in delivery order transparently to maintain trust.Regular backlog refinement should include archiving rejected items instead of deleting them, helping teams avoid repeatedly addressing the same requests while keeping the active backlog manageable.Ready to scale your agile practices? Tune in to more episodes on your favorite platform.

Produktstrategie ist ein herausforderndes Thema – unterschiedlichste Strategieansätze, sperrige Begriffe, hohe Erwartungen und der Druck, „richtig“ zu entscheiden, machen es vielen schwer, sich darauf einzulassen. Doch genau hier setzt diese Folge der Produktwerker an. Zusammen mit dem Strategiexperten Markus Andrezak beleuchtet Oliver, wie Product Owner:innen sich effektiv mit Strategieansätzen auseinandersetzen können, ohne in lähmenden Perfektionismus zu verfallen. Was euch immer klar sein sollte: Strategie ist kein abgeschottetes Konzept für eine exklusive Gruppe in einem Unternehmen. Es geht vielmehr darum, klare, bewusste Entscheidungen zu treffen, die Orientierung geben und sich kontinuierlich anpassen lassen. Ansätze wie das Playing-to-Win-Framework von Roger Martin machen dies greifbar. Anstatt einen starren Plan zu schaffen, bietet das Framework die Möglichkeit, flexibel und iterativ zu arbeiten. Ein weiterer wichtiger Punkt ist die regelmäßige Beschäftigung mit Strategie. Markus betont, dass Strategie nicht in einmaligen Offsites entsteht, sondern in kleinen, stetigen Schritten, die Teil des Arbeitsalltags werden. Regelmäßige Reflexionen – zum Beispiel in Meetings oder Sprint Reviews – helfen, Klarheit zu schaffen und die Strategie an den aktuellen Kontext anzupassen. Diese Routine trainiert nicht nur die Fähigkeit, über Strategie zu sprechen, sondern verbessert auch die Kommunikation innerhalb des Teams. Doch es gibt nicht das eine richtige Framework. Vielmehr geht es darum, aus den vielen Strategieansätzen einen Ansatz zu wählen, der zu den eigenen Bedürfnissen und dem Team passt. Ein zentraler Tipp für Product Owner:innen ist, klein anzufangen und iterativ vorzugehen. Das Ziel ist, Strategieansätze so in den Arbeitsalltag zu integrieren, dass sie praktikabel bleiben und echten Mehrwert schaffen. Wer das schafft, wird feststellen, wie sehr eine klare Strategie die tägliche Arbeit erleichtert – sei es bei der Priorisierung des Backlogs oder der Zieldefinition für das Team. Diese früheren Folgen werden in dieser Episode referenziert: - Produktstrategie in die Praxis bringen - mit Markus Andrezak - The Product Field - Framework - The Decision Stack Und diese anderen älteren Folgen können wir in diesem Kontext empfehlen: - Eine Produktstrategie entwickeln - Von der Produktstrategie zum Product Backlog (mit Roman Pichler) - Eine Produktstrategie ohne Canvas erarbeiten (mit Tim Herbig) Frühere Folgen mit Markus Andrezak: - Warum scheint die Product Owner Rolle so schwer zu sein? (Folge 3 und immer noch eine der meistgehörten Folgen!) - Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? (neben Markus auch mit Sohrab Salimi - und durch die zwei Experten ausnahmsweise etwas länger als sonst) Wer weitere Fragen an Markus Andrezak hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil oder über seine Webseite (ueberproduct.de). Weitere Infos zum Lernen in der "Strategy Collective Cohorte" gibt es bei der überproduct Academy.

In dieser Folge dreht sich alles um ein Thema, das viele Product Owner in der Praxis betrifft: Mehrere Backlogs. Obwohl die Regel im agilen Kontext „Ein Produkt, ein Product Backlog“ lautet, zeigt die Realität oft andere Szenarien. Dominique und Tim erklären wie man als Product Owner damit umgehen kann, wenn man gezwungen ist, mehr als ein Backlog zu verwalten. Bei mehreren Backlogs gibt es einige Herausforderungen. Oft entstehen sie, wenn ein Team an mehreren Produkten oder Services arbeitet, was die Organisation von Prioritäten erschwert. Ein weiteres häufiges Szenario ist die Aufteilung von Aufgaben nach Prozessschritten, etwa ein separates UX-Backlog oder ein Bug-Backlog. Diese unterschiedlichen Quellen und Aufteilungen führen leicht zu einem Verlust der Übersicht. Was ist wirklich wichtig, und welches Backlog hat Vorrang? Product Owner stehen dann oft vor der Frage, wie sie die Transparenz wahren und gleichzeitig strategisch arbeiten können, ohne sich in operativen Details zu verlieren. Die Lösung liegt häufig in einer besseren Organisation und klaren Strukturen. Statt mehrere Backlogs isoliert zu pflegen, empfiehlt es sich, alle Aufgaben in einem System wie Jira zu bündeln und mit Labels oder Filtern zu arbeiten. Dies erleichtert die Priorisierung und schafft eine „Single Source of Truth“ für alle Beteiligten. Zudem kann es sinnvoll sein, Ideen oder potenzielle Features zunächst außerhalb des eigentlichen Product Backlogs zu sammeln. Diese sollten jedoch nicht als zusätzliche Backlogs betrachtet werden, sondern als unterstützende Tools im Discovery-Prozess. Sobald eine Idee reif genug ist, gehört sie ins Product Backlog, um die Arbeit des Teams zu strukturieren und zu priorisieren. Ein weiterer Ansatz ist die Visualisierung der Arbeitsprozesse. Indem die Reise von Ideen und Anforderungen durch den Produktentwicklungsprozess sichtbar gemacht wird, können Teams und Stakeholder besser verstehen, wo welche Prioritäten liegen und welche Schritte nötig sind, um Ziele zu erreichen. Gleichzeitig gilt: Mut zur Einfachheit. Nicht jede Idee oder jedes Feedback muss umgesetzt werden. Wer mutig genug ist, Überflüssiges zu eliminieren, schafft Raum für das Wesentliche. Am Ende gilt vor allem: Für Product Owner, die mit mehreren Produkten und Backlogs arbeiten, ist eine klare Priorisierung entscheidend. Wenn spontane Aufgaben auftreten, hilft eine vorab festgelegte Rangordnung, Konflikte zu vermeiden und die Effizienz zu steigern. Weitere Tipps bekommt ihr in Folgen zu ähnlichen Themen: - Product Backlog organisieren (https://produktwerker.de/product-backlog-organisieren/) - Features wegwerfen - was braucht es dafür außer Mut? (https://produktwerker.de/features-wegwerfen/) - Das Product Goal und seine Bedeutung für Product Owner (https://produktwerker.de/das-product-goal-und-seine-bedeutung-fuer-product-owner/) - LeSS aus Product Owner Sicht und aktuelle Skalierungstrends (https://produktwerker.de/less-als-po/) - Product Principles (https://produktwerker.de/product-principles/)

1. Acting as the team's manager 2. Stay outside of the team 3. Suffocate Developers with meticulously crafted Product Backlog items 4. Determine the technology to be used 5. Push the scope of the Sprint 6. Ignore the team's capacity 7. Lead the Daily Scrum 8. Enforce skipping parts of the DoD 9. Ignore the purpose of the Sprint Review How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

As a product manager, have you ever inherited a messy backlog? In this episode, Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel break down 6 useful tactics you can use to tackle this common challenge. Listen as we discuss the challenges of inheriting a product backlog and learn practical strategies for:Aligning with company objectivesEffective stakeholder communicationPrioritization techniquesLeveraging data for decision-makingStreamlining processes and workflowsIdentifying and preparing for skill gapsIf you manage a backlog, this episode provides valuable insights to help you succeed in your role!#ProductManagement #Agile #BacklogManagement #ProductStrategy #DataDriven= = = = = = = = = = = =Watch it on YouTube= = = = = = = = = = = =Subscribe to our YouTube Channel:https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1Apple Podcasts:https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Spotify:https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Amazon Music:https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Ever feel like your work has to be perfect before hitting 'publish'? Discover how embracing B- work can actually accelerate success.Blogpost with all the links mentioned: https://monthlymethod.com/b-work/00:00 - My story of working in a tech startup03:23 - Perfectionism and the B- work05:19 - Done first. Improved later.06:56 - The B- work can change the world.09:39 - Time constraints help.How to apply Agile to your life: http://monthlymethod.com/start-here/If you want to stay in touch:

Der Opportunity Solution Tree (OST) ist eine Methode, die dabei hilft ein Product Backlog zu befüllen und zu pflegen. Zusammen mit Juliana Brell schauen sich Ina und Dominik an, was genau der OST ist, wie er entsteht, wie er geflegt wird, und wie er letztendlich dabei hilft User Stories zu erzeugen.

In deze aflevering hoor je hoe je met User Story Mapping in één oefening het fundament kunt leggen voor je product backlog. Dave Boschma van Avisi deelt zijn inzichten en ervaringen over het belang van User Story Mapping en hoe je een succesvolle workshop opzet. Hij bespreekt de belangrijkste stappen, veelgemaakte fouten en hoe je klanten en gebruikers erbij betrekt. Daarnaast krijg je praktische tips om direct aan de slag te gaan, wat het een waardevolle oefening maakt voor zowel nieuwe als bestaande producten. In deze aflevering hebben we het over: User Story Mapping, product owner, requirements engineer, product backlog, user stories, mvp, roadmap, user story telling, facilitators, design sprint Over deze podcast: In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van Productowner.nl

Die ersten Wochen in einer neuen Rolle als Product Owner können überwältigend sein. Als neuer PO steht man vor vielen Herausforderungen, gleichzeitig bietet sich aber unserer Meinung nach auch eine einmalige Chance: den Rahmen für die Produktentwicklung so zu setzen, dass man langfristig Spaß an der Arbeit hat und effektiv agieren kann. In dieser Folge diskutieren Dominique und Oliver vier Schritte, die sich als Orientierungshilfe für die ersten Wochen eignen: 1. KONTEXT VERSTEHEN UND BEZIEHUNGEN AUFBAUEN Bevor man sich in operative Aufgaben stürzt, sollte der Fokus darauf liegen, den Kontext des Produkts und der Organisation zu erfassen. Es geht zu Beginn vor allem darum, relevante Stakeholder kennenzulernen, die Produktvision zu verstehen und die Erwartungen der Beteiligten zu klären. Diese Phase legt das Fundament für alle weiteren Schritte und hilft dabei, spätere Entscheidungen fundiert treffen zu können. 2. RAHMEN FÜR DIE ENTWICKLUNG FESTLEGEN Sobald der Kontext in dem man sich als Product Owner bewegt klarer ist, gilt es, den Rahmen für die Produktentwicklung zu definieren. Dabei spielen sowohl das Aufsetzen eines gut strukturierten Backlogs als auch die Festlegung von Arbeitsweisen im Team eine zentrale Rolle. In diesem Schritt geht es vorangig darum, ein gemeinsames Verständnis zu schaffen, wie gearbeitet und welche Prioritäten gesetzt werden sollen. 3. DELIVERY UND DISCOVERY VEREINEN Ein häufiger Stolperstein in der Produktentwicklung ist die Trennung von kontinuierlicher Lieferung (Product Delivery) und der Entdeckung neuer Optionen und Lösungen (Product Discovery). Beides sollte Hand in Hand gehen. Der Fokus liegt darauf, diese Denkweise im Team zu verankern und sicherzustellen, dass das Product Backlog sowohl kurzfristige Lieferziele als auch explorative Aufgaben berücksichtigt. 4. ZIELE DEFINIEREN UND LANGFRISTIG AUSRICHTEN Darüber hinaus macht es Sinn, konkrete Outcome-Ziele zu definieren. Dominique und Oliver machen in der Episode klar, dass es hier nicht nur um das Setzen von Sprintzielen, sondern vor allem um übergeordnete Ziele wie Produk Goal, Quartalsziele oder KPIs geht. Diese geben allen Beteiligten eine klare Richtung und ermöglichen es, den Fortschritt regelmäßig zu reflektieren und anzupassen. Wichtig ist für die beiden hierbei, solche Ziele nicht zu früh zu formulieren. EIN LANGFRISTIGER ANSATZ Die beschriebenen vier Schritte sind nicht als starre Abfolge zu verstehen, sondern sollten regelmäßig reflektiert und angepasst werden. Auch nach mehreren Monaten lohnt es sich, immer wieder einen Schritt zurückzugehen und zu prüfen, ob der Rahmen noch passt oder ob der Fokus neu justiert werden muss. Am Ende bleibt es entscheidend, dass man als PO nicht nur operativ gefordert ist, sondern sich auch strategische Freiräume schafft, um das Produkt langfristig erfolgreich zu machen. Oliver und Dominique möchten mit diesen Impulsen Product Ownern für die ersten Wochen eine Idee an die Hand geben, wie ihr sinnvoll startet und euren Weg in der Produktentwicklung erfolgreich gestalten könnt.

The 9 Zones of A Product Backlog Ideally, I have some work placed in all nine zones. This indicates that product development is progressing, while still being able to develop the product strategy and make it operational. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Is The Product Owner an Order Maker or Order Taker? In Scrum, the Product Owner includes the perspective of what is valuable (and what is not) regarding the product's ambitions. As the team spends time and money working on the product, the Product Owner ensures this investment returns value to the stakeholders. Close collaboration with the people who have a stake in the product and the developers is essential to decide what is valuable and what isn't. One product has one Product Owner and one Product Backlog with one Product Goal. To keep the speed at which decisions can be made high and adaptation can take place quickly, Product Owners need full mandate over the product. They have the ultimate say over what the ambitions for the product are, what goes on the Product Backlog and what doesn't, and how to spend the budget (or even set it). How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

One of the core Agile conceptsOne of the core Agile concepts is working in short sprints vs. setting long-term goals and plans. Let's look into what a sprint is, how long it should be, how to calculate sprint capacity, and choose a sprint focus. As always, we'll discuss how you can apply all of this to your own personal projects and goals. Timeline:00:00 - Innovation in the tech industry00:47 - What is a sprint?02:07 - What is a good sprint duration?04:36 - Sprint capacity09:27 - Adjusting the scope of your sprint10:15 - Calculating the sprint capacity is an investment in your future self14:17 - Sprint capacity for the first sprint15:49 - Sprint focus20:29 - Topic for the next video 21:31 - HomeworkHow to apply Agile to your life: http://monthlymethod.com/start-here/If you want to stay in touch:

Let's review the core components and rituals of a sprint cycle and how you can apply those to your personal goals and projects. Link to the video version of this episode.Timestamps:(00:00) - - Overview (00:20) - - Creating backlog (01:51) - - Calculating sprint capacity (02:18) - - Deciding on the number of goals for the sprint (02:57) - - Sprint planning and scrum board (03:54) - - Duration of a sprint (05:05) - - Daily standups (05:37) - - Sprint retrospective (05:57) - - Cool-off week (08:18) - - Repeat the cycle (09:15) - - Where to start (10:19) - - If you don't want to wait for the next video Useful links- Subscribe to my newsletter for more frequent deep-dives into Agile life- Recent newsletter entries- Start Here page to see the blogposts on the core principles of Agile and how those can be applied to personal productivity- Twitter for regular examples of my scrum board and how it looks throughout the sprint- YouTube to 'Back to Agile Basics' type of videos- Monthly Method School for step-by-step instructions on how to run your first Agile sprint ★ Support this podcast on Patreon ★

In this episode I talk about why long-term goals don't work and how we've been mislead all this time by the traditional goal setting advice. I also share my story of finding out about Agile and how it changed my approach to personal productivity. Link to the video version of this episode.Timestamps:(00:00) - Traditional productivity advice (00:32) - New Year's Resolutions (00:55) - My first job at a fast-growing startup (01:10) - Corporate world - how things are usually done (01:40) - The time the status quo got questioned (02:30) - Creation of Agile Framework for building software (03:03) - How Agile works (04:31) - My story of learning about Agile (06:29) - I stopped creating long-term plans 10 years ago Useful links- Subscribe to my newsletter for more frequent deep-dives into Agile life- Recent newsletter entries- Start Here page to see the blogposts on the core principles of Agile and how those can be applied to personal productivity- Twitter for regular examples of my scrum board and how it looks throughout the sprint- YouTube to 'Back to Agile Basics' type of videos- Monthly Method School for step-by-step instructions on how to run your first Agile sprint ★ Support this podcast on Patreon ★

Paul Jarvis: Key Indicators of Success for Agile Teams and Their Scrum Masters That You Can Reflect On Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Investigate Paul's perspective on what defines success for Scrum Masters, from the smooth running of refinement sessions to the collaborative maintenance of the Product Backlog. This episode provides practical tips for Scrum Masters to assess their impact, emphasizing the importance of team collaboration, effective backlog management, and the ease of sprint planning. Discover how to assess success in the Agile world through a blend of team dynamics, process efficiency, and shared responsibility. Featured Retrospective Format for the Week: The Sailboat Retrospective and Other Formats Paul emphasizes the critical role of retrospectives in enabling relentless improvement, highlighting formats like the Sailboat retrospective, Celebration Grid, and the high-performance tree to encourage experimentation and self-assessment within teams. These retrospective formats are not just reflective exercises but strategic tools that prompt teams to align their values with their Agile practices, ensuring continuous growth and alignment with business goals. [IMAGE HERE] Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Paul Jarvis Paul is a seasoned Enterprise Lean Agile Coach, Trainer, RTE, and Scrum Master with a decade of experience in the FinTech sector, focusing on banking, payments, and e-commerce. Recently, he completed a 3.5-year tenure at a key player in investment banking. You can link with Paul Jarvis on LinkedIn and connect with Paul Jarvis on Twitter.

Nisha, Dan, and Prateek discuss the best strategy for managing a product backlog.

Multi-Team Product Backlog Refinement - Blog Post Review https://medium.com/orgtopologies/creating-cross-team-collaboration-with-multi-team-product-backlog-refinement-36e84aa87abb This article focuses on refining the Product Backlog with multiple teams at the same time: multi-team Product Backlog Refinement (aka mt-PBR). The goal of mt-PBR is to maximize information sharing and collaboration during Product Backlog Refinement. We bring all development teams together in one refinement session instead of having teams conducting separate refinements. NOTE: THIS ARTICLE ADDRESSES THE SYMPTOMS AND NOT THE ACTUAL PROBLEM. Listen for more details. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Struggling with product backlog management in Scrum? Dive into our in-depth discussion as we debunk common myths and reveal how to effectively manage dependencies in your product backlog. Perfect for product owners, scrum masters, and agile enthusiasts! ⚙️ Key Highlights:

Are Items in the Sprint Backlog ALWAYS Smaller Than Items in the Product Backlog? Maybe... Maybe not... This question from the PSM 1 Exam facilitated by Scrum.Org certainly generated some interesting discussion in one of my Advanced Workshops! We concluded that it is all a matter of applying best techniques to how we prioritize! How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

In this recorded session of the Ask a Professional Scrum Trainer series, PSTs Todd Miller and Ryan Ripley answered your burning questions on the topic of Product Backlog Management. They answered questions like:- What would your advice be for a new Scrum Master for understanding backlog management?-What tips can you share on how to refine a Large PBI that is too large to fit within a Sprint?- What would be your advice if management doesn't understand advantages of a single product backlog in setting when multiple teams are working together?- How do you prioritize and order the items in your Product Backlog to ensure maximum value for the product?- In your personal view: What is the optimal format for a Product Backlog refinement?And many more!!!

In this episode of the Scrum.org Community podcast, PSTs Ryan Ripley and Todd Miller join host Dave West to introduce the new Professional Scrum Product Management Skills training course. They talk about the importance of having good Product Backlog Management skills in order to succeed as well as the importance of transparency, stakeholder engagement and more!

Let's Master Product Backlog Items! Reach out directly to me if you need help!   Text me 757-759-5282

10 Signs Your ScrumMaster Does NOT Understand Scrum Definition of Done? Yeah, we have one ... somewhere ... Let me find it. That's the Standard Process. You Can't Change It Just Because It's Stupid. We Wouldn't Need Feedback if you Just Learn to Write Better User Stories! Releasable Product Increment? Once a Quarter - otherwise, it's Too Much Overhead. You Want Time for Learning? Just Look at All That Unfinished Work in the Product Backlog! Focus on the Sprint Goal Now - We'll Talk About Impediments in the Retro! Facilitation? Servant Leadership? No, They Need Someone Who Gives Them Clear Direction! Transparency and Openness? Nah - Nothing Beats a Great Hidden Agenda! Team Dynamics? We Had a Team Building Workshop at the Kick-off, So We're Good. Customer Focus? Maybe Later - For Now, Let's Get Scrum Straight! https://failfastmoveon.blogspot.com/2023/08/10-signs-your-scrum-master-doesnt.html How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Is There Ever a Good Time For Multiple Product Owners? According to the scrum guide, there should be one product owner who is in charge of the product vision and decides what to do, to create a better product (Not how to do it!) The Scrum Guide states: “The Product Owner is one person, not a committee.” Yet, in some environments companies build products that are so complex and big that they need multiple teams to get the job done. For these situations the Scrum Guide states: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” Contradictory to these suggestions, I observe that several companies feel the urgency to have multiple product owners for these situations. (They often argue that they “inspected and adapted” and in their case it is a necessary step to make Scrum work.) Let me share my thoughts on that. How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Here are eight critical side effects of this Product Backlog anti-pattern: Encourages Waste: An oversized Product Backlog fosters waste by investing time in items that may never be developed due to the continuous discovery of more valuable tasks. It's a clear violation of Agile Manifesto principles; particularly, simplicity—the art of maximizing the work not done—is essential. Sunk Cost Fallacy Risk: A large Product Backlog can lead to the sunk cost fallacy. Teams may continue to refine and prioritize items because they've already invested time into them rather than because they add significant value. This behavior contradicts the Agile Manifesto's principle of continuous improvement and adaptation. Leads to Analysis Paralysis: A huge Product Backlog can cause what's known as analysis paralysis, where the sheer volume of items becomes overwhelming, leading to indecision and delay. The team might spend excessive time evaluating, prioritizing, and re-prioritizing items, which detracts from their capacity to focus on actual product development. This excess of choices often slows down decision-making processes, making it difficult for the team to determine where to start or what to focus on next. Ultimately, this slows down the entire project, diverting energy away from creating value for the customer and towards managing the Product Backlog itself. Damages Stakeholder Engagement: A bloated Product Backlog presents a significant challenge regarding effective communication. The vast number of items can make it difficult for stakeholders to comprehend the plan, the progress, and the order of priority, leading to potential misalignment of expectations. Stakeholders may struggle to find their specific interests within the large list, confusing them and potentially causing a feeling of detachment. Crowding Out Effect: A comprehensive, oversized Product Backlog may inadvertently discourage stakeholders and team members from contributing their ideas and insights. The backlog's perceived completeness might give the impression that there's no room or need for additional input, potentially missing valuable ideas and insights. Inhibits Innovation: A huge Product Backlog can unintentionally stifle the creative energy within the Scrum Team. The lengthy list of tasks can create a culture of ‘checking off the boxes' where the team focuses more on completing the tasks rather than exploring and innovating. The team may feel constrained, perceiving that there's no room for new ideas, which can limit their creative problem-solving skills and deter them from finding innovative solutions. This mindset contradicts the Scrum value of ‘openness' and the Agile principle of harnessing change for the customer's competitive advantage. False Sense of Security: An exhaustive Product Backlog may provide a false sense of security, an illusion of control. It might seem like the Scrum team identified all the necessary work, reducing the perceived need for discovery and learning. This misalignment with the Scrum Guide, which advocates for iterative learning and discovery, can be harmful. Encourages Early Optimization: A bulging Product Backlog can lead to premature optimization, as the team may feel compelled to design systems or workflows that anticipate the completion of future backlog items, resulting in unnecessary complexity, contributing to waste if these tasks later change or get deprioritized. This approach conflicts with the Agile principle of simplicity—the art of maximizing the amount of work not done—and the Scrum value of focus, as it encourages effort toward uncertain future needs rather than the most valuable present ones. How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Andy asks whether all planned work by developers for a product must come from the product backlog. The answer is yes, assuming all developers work on the same product. However, problems arise when teams work on multiple things simultaneously. The product backlog items populate a Sprint backlog, which is then executed, leading to an increment. ⏩ Join Ryan and Todd for a Scrum.org course: https://buytickets.at/agileforhumansllc Todd and Ryan also co-authored a book - Fixing Your Scrum: Practical Solutions to Common Scrum Problems.

The video concerns right-sizing work in Scrum without historical data or cycle time. Todd and Ryan suggest that, in the absence of data, one should aim to complete product backlog items within half the sprint or less and focus on having small, well-refined stories that are tightly defined and understood. Ryan also notes that data can be unreliable if the team composition, product backlog, or project focus are unstable and suggests that good product backlog refinement and a clear sprint goal are essential for success in such situations. ⏩ Join Ryan and Todd for a Scrum.org course:  https://buytickets.at/agileforhumansllc Todd and Ryan also co-authored a book - Fixing Your Scrum: Practical Solutions to Common Scrum Problems.

Daniel Westermayr: Moving Beyond Roadmaps, and Using Data to Drive Decision Making for Agile Product Development Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Daniel emphasizes the importance of collecting data from day one in product development. He discusses how data can help assess the capability of the system in place and create forecasts to assess delivery dates. He mentions the NoEstimates movement and suggests counting the product backlog items that can be finalized in one sprint as a useful metric. Daniel also provides tips for helping teams accept the data, and continuously updating forecasts. He emphasizes the need to work in hypotheses rather than requirements, as it allows for acceptance that they may be wrong. Finally, he notes that data gives us information on how to act and change over time.   [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Daniel Westermayr Daniel is a Kanban Trainer with a knack for all things Lean and Theory of Constraints. He wants to help teams achieve and measure their continuous improvements. You can link with Daniel Westermayr on LinkedIn. 

Daniel Westermayr: The problem with cluttered backlogs and how to declutter them, coaching Product Owners Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Daniel Westermayr discusses his belief in the importance of the Scrum Master role in helping companies achieve their product goals. He shares his experience of encountering a cluttered backlog with items that were years old and how he cleaned it up, only to face complaints from someone in support. Daniel emphasizes the need for Scrum Masters to clarify why a large backlog is a problem, and why the company wants to keep all items. He also advises that Scrum Masters should understand what they stand for and constantly question why certain practices are being implemented. Finally, he suggests that, in order to avoid fears of losing important information, the older requirements can be stored in a safe location. Daniel also mentions an article on how to declutter product backlogs.   [IMAGE HERE] Recovering from failure, or difficult moments is a critical skill for Scrum Masters. Not only because of us, but also because the teams, and stakeholders we work with will also face these moments! We need inspiring stories to help them, and ourselves! The Bungsu Story, is an inspiring story by Marcus Hammarberg which shows how a Coach can help organizations recover even from the most disastrous situations! Learn how Marcus helped The Bungsu, a hospital in Indonesia, recover from near-bankruptcy, twice! Using Lean and Agile methods to rebuild an organization and a team! An inspiring story you need to know about! Buy the book on Amazon: The Bungsu Story - How Lean and Kanban Saved a Small Hospital in Indonesia. Twice. and Can Help You Reshape Work in Your Company.   About Daniel Westermayr Daniel is a Kanban Trainer with a knack for all things Lean and Theory of Constraints. He wants to help teams achieve and measure their continuous improvements. You can link with Daniel Westermayr on LinkedIn. 

60 Second Sprints on The 5 Scrum Events... Ready? GO! The first event is the Sprint. The Sprint is a time-boxed period where the team works to deliver a potentially releasable product increment. A Sprint usually lasts between one and four weeks. During the Sprint, the team plans, designs, develops, and tests the product increment. The Sprint is a crucial event because it provides a fixed time frame for the team to work within and allows them to focus on delivering a specific set of features. The second event is Sprint Planning. Sprint Planning is a time-boxed meeting where the team plans the work they will do during the upcoming Sprint. During this meeting, the team decides what items from the Product Backlog they will work on and how they will achieve their Sprint Goal. The Sprint Goal is a statement that describes what the team will accomplish during the Sprint. Sprint Planning helps the team understand what they need to do and how they will do it. The third event is the Daily Scrum. The Daily Scrum is a daily meeting where the team comes together to plan their work for the day. During this meeting, each team member answers three questions: What did I do yesterday? What will I do today? Are there any impediments in my way? The Daily Scrum is a quick meeting that helps the team stay focused and aligned on their work. The fourth event is the Sprint Review. The Sprint Review is a time-boxed meeting where the team demonstrates the product increment they have built during the Sprint. The team presents the product increment to stakeholders and receives feedback. The feedback is used to help the team improve the product increment and plan for the next Sprint. The Sprint Review is a crucial event because it provides an opportunity for the team to receive feedback and make changes to the product. The fifth and final event is the Sprint Retrospective. The Sprint Retrospective is a time-boxed meeting where the team reflects on the Sprint and identifies what went well and what could be improved. During this meeting, the team discusses their processes and identifies areas where they can make changes to improve their performance. The Sprint Retrospective is an important event because it helps the team continuously improve their processes and work together more effectively.

This week, Dan Neumann is joined by his colleague and friend, Adam Ulery, to talk about product backlogs.   In this episode, Dan and Adam explore the recent patterns showing interesting ways of using Agile terms, as it is an example nowadays that people call product backlogs the source of requirements for the Team, they discuss today the challenges that may arise as a result of this misinterpretation.   Key Takeaways What are product backlogs? And why they are not just the source of requirements. A product backlog is a list of all the things that will be needed for product development. If you consider product backlogs the source of requirements, then the only action that can be taken is to deliver them, not leaving any room for creativity or flexibility. No new alternatives seem to be welcomed if “the requirements” are already set. The product backlog often grows when items are added (this is one main distinction from a list of requirements). Where's the commitment point? Adam advises differing that commitment point as far into the future as possible so the Team can make the best decision that they can. Don't forget the learning component. We are building to learn, always trying to learn and to use that knowledge to inform what we do next. We always update our plans based on what we are learning. Do Teams have to have a hierarchical structure with epic and features? Adam explains how this became a trend over time. There is a need to organize the work to show to the client, but when encountering unexpected work that needs to be done, it does not need to appear in the user story format since it is simply not valuable.   Mentioned in this Episode: The Art of Prayer, Kenneth E. Hagin   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

This is the third series of Agile Framework Fight night. This fight night was hosted in Seattle by Beyond Agile. Like the first Agile Framework Fight Night, we brought together another winning panel of experts to represent the frameworks of DA, Fast Agile, LeSS, and SaFE. Agile Framework Fight Night, the SECOND SERIES happened at Beyond Agile, transmitted from Seattle. You can find Beyond Agile at Meetup.com here: https://www.meetup.com/BeyondAgile/ The expert panelists are: Ricardo “Dad of Doom” Garcia from Team DA This “Dad of Doom” has over 30 years of industry experience and has implemented and managed numerous software projects using Agile Practices for Fortune 500 companies. His work has been featured in white papers, cover stories in magazines, and is a frequent speaker at conferences and Agile expert panels. He is the organizer behind Seattle Disciplined Agile Meetup: https://www.meetup.com/Seattle-Disciplined-Agile-Meetup/ Ron Quartel AKA "Crocodile Ron-dee" Software Crafter, Disruptor, Pioneer and Intrapreneuer. On a mission to unleash the human spirit in the workplace. Founder of FAST Agile. https://www.fastagile.io Viktor "the Simplifier" Grgic Viktor is an Agile Coach, software developer and Certified LeSS trainer with 17 years of experience in delivering enterprise systems and Agile adoptions. He worked first 15 years in The Netherlands, and since 2013 in Hong Kong. https://less.works/profiles/viktor-grgic Barry Smith, the Nexus Knight Is a member of Unify's Lean-Agile practice, and committed to helping product teams to enjoy a better way of working and delivering exceptional value to their customers. His over 25+ years of working in technology has shown him that innovation can be fostered anywhere, from startups to Fortune 500 firms. Lancer “Unkind” Kind, moderating “Unkind” lives in Kirkland, and loves nothing more than writing micro tested software. For the last five years he has delivered consulting services in China, India, as well as the USA. He's a publishing author of science fiction and Agile Noir, a project management business novel. He's podcasting at Agile Thoughts, 敏捷理念 (the Chinese edition of Agile Thoughts), and SciFi Thoughts. His Agile at scale business novel is “continuously delivered” via Lean Pub at: https://leanpub.com/AgileGrande Here is a link to this Beyond Agile event in Meetup which contains comments about the fight night: https://www.meetup.com/beyondagile/events/286465281/ You can listen to the first and second Bouts of Agile Framework Fight Night series here: https://agilenoir.biz/en/agilethoughts/agile-framework-fight-night/ Chat record from Bout 3 of Agile Framework Fight Night Jon Jorgensen to Everyone (10:04 PM) I know Niels Pflaeging. Would you like me to ask him if he'd like to speak to this group? Aki Namioka to Everyone (10:05 PM) Where is Niels Pflaeging located? Jon Jorgensen to Everyone (10:06 PM) Germany Ricardo to Everyone (10:08 PM) For Jobs at Costco pls send me an email at ricardo.garcia@costco.com shama to Everyone (10:08 PM) Ron Lichty to Everyone (10:10 PM) Enterprise Agile Global Community: Dennis Stevens: Agile for Execs: https://us02web.zoom.us/j/89071064881?pwd=a1NoY2ptN3BudGd1OGNINXNtQ0ZYQT09 Josh Novajosky to Everyone (10:11 PM) Amazing shirt Ron Barry L Smith to Everyone (10:18 PM) “LeSS”, of course, refers to “Lightweight Similarity to Scrum" - really, they copied all their good ideas from Nexus. Ron Lichty to Everyone (10:24 PM) I thought I heard Paige Watson describe the FAST meeting as five PdMs bringing in the five priorities for the cycle? Is a “nexus” essentially what others are calling a "tribe”? Barry L Smith to Everyone (10:27 PM) Yes, similar to tribe or ART (Agile Release Train) - the group of teams that are collaborating in developing & delivering a Product Backlog. Jon Jorgensen to Everyone (10:29 PM) Seems like HUGE enterprises would have HUGE concerns (problems) to resolve for the people of the world and inside the organization. Silpa to Everyone (10:31 PM) Our scrum team is of 16 members. We formed mini scrum teams of 4 in each team with 1 PO, 1 SM, making sure we have a process expert supporting each mini scrum team. Jon Jorgensen to Everyone (10:31 PM) The crafting of experiments to see if hardware/software or other kinds of “works” is what runs through an organization. Which of the Frameworks are predicated on the assumption that software products are the resolution of these concerns? Barry L Smith to Everyone (10:32 PM) Jon, are you essentially asking, “Is experimentation a core element of your framework”? Jon Jorgensen to Everyone (10:32 PM) yes Me to Aki Namioka (Direct Message) (10:33 PM) What is our "finish" time? One hour or? Jon Jorgensen to Everyone (10:33 PM) And “What kind of professionals are involved in the experiment?” Barry L Smith to Everyone (10:34 PM)

0:25 Bonus Episode Intro 1:10 Chad and Jeff Intros on Scrum Master Toolbox Podcast 2:37 From Frantic and Stressful to Strategic and Focused Backlogs 4:19 Task-based backlogs... 5:53 Focused and strategic backlog 9:40 Moving from tasks to impacts  and outcomes (product goals) 10:37 Decomposition or recomposition? 12:45 Scrum teams are expensive 14:34 Why do we do product backlog refinement? 15:30 REFINEMENT TIP: Talk time 16:03 REFINEMENT TIP: Questions and summaries 16:40 REFINEMENT TIP: Diverge/merge cycles 17:30 Practical facilitation for refinement session 19:56 Tools for strategic product ownership 24:21 Strategy, focus, tradeoffs 28:30 Solution vs problem statements 30:47 Track dependencies 33:00 Flat product backlog 33:54 Impact and outcome statements 39:05 The Agile Wire 39:39 Agile Songs 40:50 The Lean Startup 41:50 Product Owner Summit (https://productownersummit.org) Check out the Scrum Master Toolbox podcast at https://scrum-master-toolbox.org Connect with us at the following places: Wisconsin Agility Training: https://wisconsinagility.com/training Advising: https://wisconsinagility.com/advising Merch: https://wisconsinagility.com/merch Jeff Bubolz Jeff Bubolz LinkedIn: https://www.linkedin.com/in/jeffbubolz/ Jeff Bubolz Twitter: https://twitter.com/JeffBubolz  Chad Beier Chad Beier LinkedIn: https://www.linkedin.com/in/chadbeier/ Agile Songs YouTube: https://www.youtube.com/@agilesongs Agile Songs Shorts: https://www.youtube.com/@agilesongs/shorts Agile Songs Twitter: https://twitter.com/AgileSongs The Agile Wire Web: https://theagilewire.com Spotify: https://open.spotify.com/show/0YKEHJtcJXZ55ohsUOvklI Apple Podcasts: https://podcasts.apple.com/us/podcast/the-agile-wire/id1455057621  Agile Wire Clips: https://www.youtube.com/playlist?list=PLLl0ryedF7y7HWTsbur4ysdpUcY7tniSG Agile Wire Twitter: https://twitter.com/AgileWire  Make sure you subscribe to the channel! #Scrum #Agile #ProfessionalScrum #Kanban #BusinessAgility

BONUS: Mastering the Product Backlog, lessons for Product Owners with Jeff Bubolz and Chad Beier Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   About Jeff Bubolz and Chad Beier Jeff is a Professional Scrum Trainer (PST) with Scrum.org, organizational agility advisor and speaker. He has been a Product Owner, Scrum Master and Development Team member and has worked with companies ranging from enterprise to small start-ups.   Jeff is the co-host of The Agile Wire podcast where he speaks with industry leaders around the world. He speaks at conferences across the United States and is active in the Wisconsin agile community. You can link with Jeff Bubolz on LinkedIn and connect with Jeff Bubolz on Twitter.    Chad is an organizational agility advisor, external change agent, and Professional Scrum Trainer (PST) with Scrum.org. He works with all levels of the organization to optimize your business to respond to change. Chad is the co-host of The Agile Wire podcast where he speaks with industry leaders around the world. He speaks at conferences across the United States and is active in the Wisconsin agile community. lYou can link with Chad Beier on LinkedIn and connect with Chad Beier on Twitter.

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.On this episode, we take a look at 13 Backlog Anti-patterns!0:00 Topic Intro0:28 1. Prioritization by Proxy4:36 Tangent on "By Proxy"5:49 2. The Oversized Product Backlog11:16 3. Outdated Issues13:58 4. Everything is Detailed and Estimated16:42 5. INVEST?20:14 6. Missing Acceptance Criteria22:02 7. 100% In Advance26:35 8. No More Than a Title30:41 9. Storage for Ideas34:28 10. Part-Time PO35:48 11. Copy & Paste PO37:17 12. Dominant PO (Spoiler Alert, We Skip It)38:43 13. The "I Know It All" PO41:52 Go-Back: 12. Dominant PO45:29 Wrap-Up----------------------Watch it on YouTubeANDSubscribe to the Arguing Agile Podcast on YouTubeOr listen on: Apple Podcasts:https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Google Podcasts:https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3Byb3V0LmNvbS8xNzgxMzE5LnJzcwSpotify:https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Amazon Music:https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-PodcastStitcher:https://www.stitcher.com/show/agile-podcast-2----------------------AA102 - Backlog Antipatterns #agile #productmanagement #podcast

In this episode, Eric Landes addresses a question he received while training: “How many times should I refine a Product Backlog Item before it's ready for a Sprint?” If you are interested in attending Scrum training, check out our public Scrum training courses. Key Takeaways: How many times should a team refine a PBI before it is ready for the sprint?  The scrum guide talks about refining as an activity and ongoing.  So, the answer is that a team should refine backlog items enough so that they understand the item.  It is ready when the team says it is, and the PBI can be completed within a sprint. Here are some activities a scrum team might undertake to refine their backlog item to ready.  Your team may have better ways for you. Remember the ongoing activity, but these are some ways to get started.    First, the Product Owner refines the item when first getting the PBI. Whether the PO entered the item or someone else did, some initial details can be entered.  The Product Owner talks to people to help clarify what this is solving.  Sometimes this looks like a Product Owner having a feature that is broad in scope.  She then decomposes the feature into multiple stories that she thinks solves the problem.    Second, the Product Owner runs the new PBI by the team in a refinement meeting. Giving the rest of the team some information about this new PBI, and getting feedback on their understanding of what is needed.  If the team is satisfied with the answers, they might estimate the PBI during this refinement session.  But if more clarification is needed, the Product Owner might elect to get more information. Third, if the Product Owner needs more clarification, they get it, maybe doing research, talking to customers, or whatever is needed to clarify the PBI.  After enough gathering enough information -   Fourth - The Product Owner brings refined PBI to the refinement meeting and the team asks any more questions.  Hopefully, the team is confident the PBI can be completed within a sprint, and they estimate. Now the PBI is ready for the sprint.

In this episode, Eric Landes addresses a question he received while training: “Should we have more than one ‘Definition of Done?'” If you are interested in attending Scrum training, check out our public Scrum training courses.  Key Takeaways: This week, let's talk about the Definition of Done. In one of our classes, we had a question about the Definition of Done. Specifically, how many Definitions of Done can a Scrum Team have? So, I went to the Scrum Guide, and here is what that says: "The moment a Product Backlog item meets the Definition of Done, an Increment is born." The guide does not say it meets the sprints Definition of Done or the potentially shippable definition of done. Instead, it states, "the Definition of Done," implying, in my mind, that there is one Definition of Done. In class, we discussed whether there should be a definition of done for releases, for instance. When some organizations release the software, users need to be trained. Marketing materials might need updating, etc. And I understand that these things need to happen. Having one DoD would reduce friction for releasing. No waiting for another team to complete work. The Scrum team controls when they can release. High-maturity teams and organizations are designed this way. But not all organizations are in a place where we can have the Scrum team do everything necessary for release. So the team may have to grow into it. That is ok. Remember where you are headed and make improvements every sprint to put everything necessary for done into your definition. Related to this Episode: A complete list of the current Scrum Training by AgileThought. Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

Learn about the product backlog and the items that make up the backlog in this new episode Interested in Agile coaching? Sign up for my Mentorship and coaching program scheduled to kick off 1st of March If you love my podcast and YouTube videos then you will love this program so much more because this program will take you to the next level in this program you learn…. How to be an exceptional scrum master How to influence your team and make them effective How to get your scrum master job How to build the right mindset and confidence How to interpret the scrum master role and deliver on the job So if you are an aspiring scrum master who desire to get into tech as a scrum master or are currently fullfilling the scrum master role and need to horn your skills to become exceptionally great in your role as Agile practitioners then this is for you. Click here to sign up https://www.scrummasteryplaybook.com/... Are you new to agile and wondering how to facilitate the scrum events? Your worries are over. This is the perfect workshop for you in this workshop- you will learn how to effectively facilitate all the scrum events. We simulated it all Backlog refinement Sprint planning Daily scrum Review Retrospective we had a real project, real team members, Scrum master and product owners. you will experience the Scrum events in Action click link to access workshop today https://www.scrummasteryplaybook.com/...

Responsibilities vs Accountabilities - A Better Understanding of Agile Roles Product Owner: Accountabilities Product Vision: Craft a Product Vision that points the team in a meaningful direction. Product Strategy: Define a strategy enabling the team to decide what to do and what not to do. Goals: Set meaningful goals that enable teams to focus and intensively collaborate towards a unique direction. Value Maximization: Prioritize meaningful problems that maximize the outcomes for users and businesses. Communication: Ensure stakeholders are well-informed about results, decisions, progress, etc. In summary, they should never say, “I was unaware of that.” Responsibilities Stakeholder Management: Engage with stakeholders to partner up and create value for products. This includes organizing meetings, workshops, communication, etc. Backlog Management: Curate, sort, and clean up the Product Backlog to ensure it has the most relevant items to create value. Roadmap: Craft product roadmaps to provide perspective and set expectations on where the product is heading. Monitor results: Constantly evaluate KPIs to understand how the product creates value for end-users. Product Discovery: Ensure continuous learning to enable innovation and solve problems users care about. ScrumMaster: Accountabilities Scrum Understanding: Ensure business stakeholders understand how to play the Scrum game. Atmosphere: Develop a collaborative atmosphere with a balance between learning and delivering. Framework: Ensure that all Scrum events occur and that all artifacts are created as defined in the Scrum Guide. Teams' Effectiveness: Enable the team to grow and become as effective as possible. Enable Self-management: Unleashes the team's potential by helping them become self-managing teams. Responsibilities Ensure the Sprint Retrospective takes place: The Scrum Master may facilitate the Sprint Retrospective, but the responsibility is ensuring that it happens. Another team member can run the show. Ensure Retrospectives End Up with Actions: After each Sprint, Scrum teams discuss how to get better as a team. Scrum Masters ensure the result of the session has clear agreed actions. Coach stakeholders: Invest whatever is necessary to coach key business people to enable teams to thrive with Scrum. Scrum Events: Ensure the team respects the Scrum Events frequency and timeboxes them. Development Team: Accountabilities Quality: Ensure the code meets the agreed quality standards. Scalability: Creates solutions that scale to the required business needs. Efficiency: Guarantee solutions are efficient from the users' perspective. Maintainability: Develop an application that can be maintainable by other professionals. Responsibilities Solution: Implement solutions that solve the agreed problems. Test: Perform required tests to meet the quality expectations. Delivery: Define a delivery process and execute it accordingly. Estimate: Only those who work on the solution can estimate it.

In this episode, Eric Landes addresses a question about how the Definition of Done impacts Release Planning. If you are interested in attending Scrum training, check out our public Scrum training courses. Does the Definition of Done help the PO in Release planning? In a recent class, the idea of how the Definition of Done (DoD) affects a release plan and the Product Owner came up!  So, I wanted to walk through what the Scrum Guide says, and impart some practical advice about planning with the DoD.  The scrum guide states that "The moment a Product Backlog item meets the Definition of Done, an Increment is born".  Couple this with the Increment guidance, "an increment must be usable", this helps the Product Owner in forecasting when the increment gets in customers' hands.  The Product Owner uses the team's throughput, or whatever complimentary metric they prefer in their forecasting.  Then during Sprint reviews, the Product Owner shows stakeholders forecasts of when features and functionality can be delivered to customers.  The Product Owner adjusts forecasts as more learning occurs through each Sprint. The Definition of Done impacts the Product Owner's forecasts when it does not include quality steps to get the increment to that usable state.   Product Owners want actual feedback from customers using the software in the wild, to help guide their goals.  The transparency of the Definition of Done can be used by the Product Owner to help move toward a usable Increment. For instance, if the team needs a compliance review before something can go to production, the Product Owner should ask how the team can include this in the DoD.  The Developers might suggest collaborating with the compliance group on automated solutions.  This might add some items to the Backlog to get that automation included in the team's delivery automation.  Now that this is in the Definition of Done the Scrum Team is in control of getting the Increment in front of the customer.   This is one example of how the Product Owner can use the transparency of the Definition of Done to improve the value they deliver. Want to Learn More or Get in Touch? I'd love to hear what you think. If you have a question or a comment, please email us at podcast@agilethought.com. For more information on AgileThought's available courses, go to agilethought.com/services/training-certifications.  This information is also available on the page of this podcast.  Thanks for listening!

How DEEP is Your Product Backlog? Join V. Lee Henson as we review and article by Teodora Todrova where she discusses the acronym DEEP and why it is so critical for teams to understand and monitor their Product Backlog... D = Detailed Appropriately E = Estimated E = Emergent P = Prioritzed

Help! People Doubt the Order of the Product Backlog! Let's explore the options this situation presents. This and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley.See omnystudio.com/listener for privacy information.