Podcasts about user stories

A frustrated CEO, a legacy system no one liked, and a looming contract deadline — this episode unpacks the story of how one team broke out of vendor-driven inertia and took back control of their tech strategy. What started as confusion and friction turned into clarity and confidence, all through the power of intentional facilitation and a tightly structured two-day workshop. You'll hear how a group of cross-functional stakeholders aligned on priorities, identified risky assumptions, and rapidly shaped a new path forward — including a validated RFP and scoring rubric — in just 16 hours. This episode is packed with practical tips for anyone facing a big, high-stakes decision with too many options and too little time. Inside the episode... A CEO's challenge with legacy tech and vendor pressure How a two-day workshop turned chaos into clarity The role of facilitation in accelerating strategic alignment Stack ranking, 2x2 matrices, and other prioritization techniques Why solo work before group discussion makes a huge difference Designing better user stories from the ground up Using ChatGPT to draft faster, better RFPs and rubrics How to spot and de-risk your most dangerous assumptions Tactical facilitation tips for running your own workshop The impact of intentional structure, breaks, and focus Mentioned in this episode ChatGPT RFP (Request for Proposal) templates and scoring rubrics Integral's Plus/Delta/Learn framework Facilitation techniques like 2x2 matrices, stack ranking, dot voting Data integration planning Unlock the full potential of your product team with Integral's player coaches, experts in lean, human-centered design. Visit integral.io/convergence for a free Product Success Lab workshop to gain clarity and confidence in tackling any product design or engineering challenge. Subscribe to the Convergence podcast wherever you get podcasts including video episodes to get updated on the other crucial conversations that we'll post on YouTube at youtube.com/@convergencefmpodcast Learn something? Give us a 5 star review and like the podcast on YouTube. It's how we grow.   Follow the Pod Linkedin: https://www.linkedin.com/company/convergence-podcast/ X: https://twitter.com/podconvergence Instagram: @podconvergence

Yuval Yeret, founder of Yeret Agility and OG Agile expert, joined me on Ditching Hourly to discuss the current state of Agile as a platform, how it has evolved over the years, and what practitioners should consider when pivoting their careers as the platform matures.About YuvalYuval Yeret is a Product/Scaling/Agility Coach focused on helping product/tech leaders scale their organizations without slowing down, improving outcomes by leveraging flow, agility, and product orientation. (while avoiding the dogma and process BS of Agile Theater). Yuval is a globally recognized expert on scaling w/ agility, a SAFe Fellow, a Professional Scrum Trainer, and a co-author of the Kanban Guide for Scrum Teams. These days Yuval is focused on helping organizations evolve from Feature Factories to Empowered Product Organizations, as well as helping deeper tech organizations develop a pragmatic agility strategy. Yuval shares his insights on scaling w/ agility at https://yuvalyeret.com/scaling-with-agility-newsletter/Chapters(00:00) - Introduction and Guest Welcome (00:17) - Yuval's Background and Journey into Agile (01:35) - Early Days of Agile (03:56) - Transition to Consulting and Coaching (07:21) - Agile's Evolution and Current State (09:46) - Challenges and Criticisms of Agile (17:30) - Future of Agile and Role Adaptation (22:18) - Advice for Agile Practitioners (30:22) - Reflecting on Agile Leadership (31:24) - Anecdote: Transition from FileMaker to Web Development (34:57) - The Future of Agile and Product Operating Models (39:20) - Adapting Skills for New Opportunities (41:48) - Navigating Organizational Change (44:47) - Strategies for Career Pivoting (48:01) - The Role of Scrum Masters in Modern Organizations (52:00) - Consulting and Value Proposition (57:55) - Closing Thoughts and Resources Notable Quotes"What happened over the years is... agile has become mainstream for most of corporate America, technology organizations and product companies. And this created the reality where the people that are, the organizations that are currently adopting agile are the late adopters.""[Late adopters] are slapping names like Scrum Master and Sprint and User Story and Daily Scrum... on the way that they've been doing things already. And it's like lipstick on a pig. It's not really creating any impact other than a bad name for Agile and a bad name for people in these roles.""The biggest issue with Agile... is the over-reliance on specific roles in organizations.""We will have a significantly smaller number of people that dedicate their career to something like agile, whatever it's called. You will need to specialize. You will need to start to think like consultants need to start to think and build your content solar system."Yuval's Links and Other ResourcesYuval's article on "The Future of Agile Roles and Agility"Yuval's private podcast on navigating the landscape of Agile theater, feature factories, and product operating models"Crossing the Chasm" by Geoffrey Moore (book on technology adoption)Netflix culture book (featuring the "Netflix question")The career mini-course that Jonathan mentioned: Unblock Your Career by Shachar Meir ----Do you have questions about how to improve your business? Things like:Value pricing your work instead of billing for your time?Positioning yourself as the go-to person in your space?Productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal?Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes to get ready for work in the morning.Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call, you don't feel like it was worth it, just say the word, and I'll refund your purchase in full.To book your one-on-one coaching call, go to: https://jonathanstark.com/callI hope to see you there!

Découvrez un métier aux multiples facettes, où agilité, innovation et soft skills sont les clés de la réussite. Rôle central dans les entreprises numériques, le Product Owner jongle entre vision stratégique, priorisation des fonctionnalités et communication avec des équipes variées. Pourquoi poser 5 fois « pourquoi » ? Comment rédiger une User Story percutante ? Geoffrey partage son expérience, ses astuces et des conseils concrets pour ceux qui souhaitent se lancer dans cette voie. Un hors série riche en enseignements pour mieux comprendre les rouages de l'agilité et du management produit !

Découvrez un métier aux multiples facettes, où agilité, innovation et soft skills sont les clés de la réussite. Rôle central dans les entreprises numériques, le Product Owner jongle entre vision stratégique, priorisation des fonctionnalités et communication avec des équipes variées. Pourquoi poser 5 fois « pourquoi » ? Comment rédiger une User Story percutante ? Geoffrey partage son expérience, ses astuces et des conseils concrets pour ceux qui souhaitent se lancer dans cette voie. Un hors série riche en enseignements pour mieux comprendre les rouages de l'agilité et du management produit !

Anuj Ojha: Helping PO's Move Beyond User Story Templates to True Customer Understanding Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Vision Setter Who Empowers Teams In this segment, Anuj describes an exemplary Product Owner who mastered the art of inclusive product development. This PO excelled at bringing everyone together to discuss the product and potential solutions, while maintaining a clear focus on the vision and problem space. Rather than dictating solutions, they created an environment where team members could freely explore solutions while the PO remained available for questions and guidance. Their success came from building strong relationships with stakeholders and customers, and effectively using the Eisenhower matrix to prioritize work. The Bad Product Owner: The Requirements Translator Anuj discusses common anti-patterns he's observed in Product Owners, particularly those who may have previously been project managers. A crucial issue arises when POs create user stories without first understanding the customer and their journey with the product. Some POs become mere translators, rigidly adhering to story templates instead of truly understanding customer needs. The key to improvement lies in helping POs learn to engage directly with customers, focus on problem exploration rather than immediate solutions, and collaborate with the whole team in solution discussions. Self-reflection Question: How can you help your Product Owner move from being a requirements translator to becoming a true value maximizer? [The Scrum Master Toolbox Podcast Recommends]

Translating User Stories Into Value Stories Can Drive Action I've been seeing an increasing number of designers who don't realize that design communication is a two-way street. There's been an increasing focus on soft skills, like design communication, to navigate this turbulent job market. However, this doesn't just mean teaching your team about the UX point of view. It also means knowing enough about the business's priorities to translate user findings and design recommendations into terms they understand. When I say that, people often think this means learning about KPIs, metrics, and related subjects. While learning those terms is helpful, that's not the only way to translate designs for the business. 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/

Substack Week: AI in Product Management, Enhancing Product Development Through Artificial Intelligence with Toni Dos Santos In this Substack Week episode, we explore how artificial intelligence is transforming product management with Toni Dos Santos, co-author of The Product Courier newsletter. From automating routine tasks to enhancing strategic decision-making, Toni shares practical insights on leveraging AI to build better products faster and more efficiently. From Music to Banking to AI Product Management "I wanted to work in that area to find ways to put innovation to service to the consumers, and making it as invisible as possible." Toni's journey into AI and product management began in an unexpected place - the music industry. After working as a music producer, his interest in innovation led him to banking, where he discovered the untapped potential of data analytics. His experience working with machine learning and deep learning in banking laid the foundation for his current work with generative AI in product management. The launch of ChatGPT in 2022 sparked his deep dive into applying AI to product management challenges. Revolutionizing User Story Creation with AI "User stories are a big pain for many product managers, particularly junior ones... The idea is that you provide the AI with a PRD or description of the product, and it's going to write user stories based on best practices." Toni explains how AI can transform the process of writing user stories by automating the initial drafting while preserving the essential collaborative aspects. He emphasizes that while AI can handle the mechanics of writing, the real value comes from using it as a springboard for deeper discussions with the team. The technology can suggest edge cases, highlight potential gaps, and provide a structured foundation for further refinement. AI as a Tool for Understanding User Needs "Use all the transcripts, the feedback from user interviews that I have, feed it to AI and retrieve from it the key pain points, the major patterns that it identifies." Rather than replacing human insight, AI serves as a powerful tool for analyzing user feedback and identifying patterns. Toni shares practical examples of using AI to: Process and analyze app store reviews at scale Identify clusters of users with similar pain points Extract key themes from user interviews Validate qualitative findings with quantitative data Strategic Role of AI in Leadership "For product leaders, they should be the ones thinking how AI will affect their work because to define a strategy, to define a roadmap, AI can summarize tons of data, tons of information that you cannot do yourself." Toni challenges the notion that AI primarily impacts lower-level tasks. He argues that AI's ability to process vast amounts of information makes it particularly valuable for leadership roles. Leaders can use AI to: Prepare more effective meetings with relevant agendas Create alignment across different departments Practice important presentations and interviews Generate and evaluate strategic options Best Practices for Getting Started with AI "The best resource is to go into it... get ChatGPT, Gemini, whatever, and just dive into it and try and get learning and start practicing right away." For product managers looking to incorporate AI into their workflow, Toni emphasizes the importance of hands-on experience. He recommends: Starting with practical experimentation rather than just theoretical learning Understanding AI's limitations (20% error rate) and always double-checking outputs Treating AI interactions as conversations rather than one-off prompts Focusing on areas where AI can augment rather than replace human judgment Resources For Further Study BOOK: Bret King, Bank 3.0: Why Banking Is No Longer Somewhere You Go But Something You Do Toni's Product Courier Newsletter The AI focused episode with Marshall Goldsmith AI Course by IBM: Armin Ries, free AI course by IBM [The Scrum Master Toolbox Podcast Recommends]

Als Product Owner ist es essenziell, sich kontinuierlich weiterzuentwickeln und die richtigen Werkzeuge für die tägliche Arbeit zu nutzen. In der neuesten Episode der Produktwerker geht es genau darum: Welche Methoden für Product Owner sind wirklich relevant? Eine der wichtigsten Grundlagen ist die Produktvision. Hier hilft das Product Vision Canvas bzw. das Product Vision Board (von Roman Pichler), um ein gemeinsames Verständnis im Team und mit Stakeholdern zu schaffen. Ob mit dem Framework von Roman Pichler oder dem Positioning Statement von Geoffrey Moore – entscheidend ist, dass die Produktvision klar und lebendig bleibt. Eng verknüpft mit der Produktvision ist das Thema Roadmapping. Klassische, feature-getriebene Roadmaps sind längst überholt. Stattdessen setzen erfahrene Product Owner auf Outcome-orientierte Roadmaps, etwa in Form der Now-Next-Later-Roadmap. Dabei geht es nicht darum, starre Zeitpläne einzuhalten, sondern den Fokus auf die gewünschten Wirkungen zu legen. Für eine sinnvolle Planung ist außerdem Story Mapping unverzichtbar. Diese Methode hilft, eine holistische Sicht auf das Produkt zu behalten, Features sinnvoll zu priorisieren und das Team in die richtige Richtung zu steuern. Jeff Patton hat mit dem User Story Mapping eine Praxis entwickelt, die das Verständnis für Wirkungsschnitte und Priorisierung stärkt. Ein weiteres wertvolles Tool im Werkzeugkasten eines Product Owners ist der Opportunity Solution Tree (OST), bekannt aus Teresa Torres' Buch Continuous Discovery Habits. Der OST ermöglicht es, Business-Ziele mit Kundenbedürfnissen zu verknüpfen und den besten Weg zur Lösung abzuleiten. Etwas älter, aber genauso wirksam ist das Impact Mapping von Gojko Adzic – ein strukturierter Ansatz, um zu visualisieren, welche Akteure ihr Verhalten ändern müssen, damit das Produkt erfolgreich wird. In der täglichen Arbeit von Product Ownern spielen Annahmen eine große Rolle. Doch oft sind diese weder hinterfragt noch belegt. Hier kommt das Assumption Mapping ins Spiel. Mit dieser Methode von David J. Bland lassen sich Annahmen systematisch priorisieren und durch gezielte Experimente validieren. Auch das Arbeiten mit User-Feedback gehört zu den essenziellen Methoden für Product Owner. Hier hilft der Interview-Snapshot aus Teresa Torres' Discovery-Ansatz, um strukturierte Erkenntnisse aus Nutzerinterviews zu ziehen. In Kombination mit dem Value Proposition Canvas von Alexander Osterwalder lassen sich die relevanten Pain Points und Gains der Nutzer noch klarer herausarbeiten. Natürlich darf auch das Thema User Stories nicht fehlen. Diese Technik ermöglicht eine nutzerzentrierte Formulierung von Anforderungen. Doch User Stories sind nur so gut wie ihre Akzeptanzkriterien und die Fähigkeit, sie sinnvoll zu schneiden. Deshalb ist es entscheidend, nicht nur das Schreiben, sondern auch das Splitting von User Stories zu beherrschen. Ein weiterer Bereich, der oft unterschätzt wird, ist das Stakeholder-Management. Ohne eine gezielte Strategie kann die Vielzahl an Stakeholdern schnell zur Herausforderung werden. Das Power-Interest-Grid hilft dabei, die richtigen Prioritäten zu setzen und Stakeholder effektiv einzubinden. Daneben sehen wir noch eine elfte Methode, quasi als "Bonus-Thema", das in den letzten Jahren immer wichtiger wird: AI-Prompting. Die Fähigkeit, mit Tools wie ChatGPT oder Perplexity effizient zu arbeiten, kann für Product Owner einen enormen Vorteil bringen – sei es für die Generierung von Ideen, die Analyse von Feedback oder die Strukturierung von Informationen. AI wird zunehmend zum Wingman für Product Owner und sollte daher als fester Bestandteil des Methodensets verstanden werden. Diese zehn Methoden für Product Owner sind nicht nur theoretische Konzepte, sondern praxisbewährte Werkzeuge, die den Alltag eines POs erleichtern und das Produktmanagement auf ein neues Level heben. Welche dieser Methoden setzt du bereits ein? Und welche fehlt deiner Meinung nach in dieser Liste?

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.

Hur man skriver bra user stories som verkligen gör skillnad för agila team. Oavsett om du är produktägare, utvecklare eller del av ett scrumteam, får du med dig konkreta tips och strategier för att lyfta dina user stories till nästa nivå. Lyssna nu och få verktygen för att skriva bättre user stories! Dela med ditt team och låt oss veta vad du tycker — skicka in din feedback eller frågor via sociala medier. Tillsammans bygger vi bättre produkter!

Mapeamento de Histórias do Usuário: Um Guia Completo O que é Mapeamento de Histórias do Usuário? O mapeamento de histórias do usuário é uma técnica ágil que visualiza e prioriza o trabalho necessário para construir um produto ou funcionalidade. Ao invés de apenas listar as histórias, essa técnica considera a jornada completa do usuário, desde o início até o fim. Por que usar o Mapeamento de Histórias? Melhora a comunicação: Facilita a compreensão entre todos os membros da equipe, incluindo stakeholders e usuários. Prioriza o trabalho: Ajuda a equipe a definir quais funcionalidades são mais importantes para os usuários. Reduz riscos: Minimiza a chance de desenvolver funcionalidades que não agregam valor ao usuário. Aumenta a flexibilidade: Permite adaptar o roadmap do produto de acordo com as necessidades dos usuários e mudanças no mercado. Alinha a equipe: Garante que todos estejam trabalhando em direção aos mesmos objetivos. Como criar um Mapeamento de Histórias? Identifique os papéis dos usuários: Quem são os usuários do seu produto e quais são suas motivações? Defina os objetivos dos usuários: Quais são os principais objetivos que cada usuário quer alcançar? Mapeamento da jornada do usuário: Crie um fluxo que mostre os passos que um usuário normalmente segue para alcançar seus objetivos. Adicione as histórias do usuário: Coloque cada história no mapa, alinhando-a com o passo correspondente da jornada do usuário. Priorize e agrupe as histórias: Organize as histórias em releases com base na prioridade e dependências. Revise e atualize regularmente: Revise o mapa constantemente para garantir que ele reflita as mudanças no projeto. Componentes do Mapeamento de Histórias: Papéis dos usuários: Diferentes tipos de usuários que interagem com o produto. Objetivos dos usuários: Metas que cada usuário quer alcançar. Jornada do usuário: Sequência de passos que um usuário segue para alcançar seus objetivos. Histórias do usuário: Descrições concisas de funcionalidades do ponto de vista do usuário. Releases: Grupos de histórias que serão implementadas em um determinado período. Exemplo: Imagine que você está desenvolvendo um aplicativo de e-commerce. Seus papéis de usuário podem incluir: Cliente: Quer navegar pelos produtos, encontrar o que precisa e realizar uma compra. Convidado: Quer navegar pelos produtos e conhecer mais sobre a empresa. Administrador: Quer gerenciar produtos, pedidos e contas de clientes. A jornada do usuário para um cliente pode ser: Navegar pelos produtos Pesquisar por produtos específicos Ver detalhes do produto Adicionar produtos ao carrinho Finalizar a compra Informar os dados de entrega e pagamento Realizar o pedido Acompanhar o status do pedido Ferramentas para Mapeamento de Histórias: Quadro branco: Ideal para brainstorming e visualização colaborativa. Ferramentas digitais: Jira, Trello, Miro, entre outras. Benefícios do Mapeamento de Histórias: Visão holística: Permite visualizar a experiência do usuário como um todo. Melhor tomada de decisões: Ajuda a equipe a tomar decisões mais informadas sobre o desenvolvimento do produto. Aumento da satisfação do cliente: Garante que o produto atenda às necessidades dos usuários. Conclusão: O mapeamento de histórias do usuário é uma ferramenta poderosa para garantir que seu produto seja bem-sucedido. Ao visualizar a jornada do usuário e priorizar as funcionalidades, você pode criar um produto que realmente atenda às necessidades dos seus clientes.

Today, on Framework Friday episode one, How to Craft Impactful User Stories for Improved Outcomes, we're diving into a powerful tool for defining "what done looks like": user stories.People:Users, customers, and ourselvesProcess:Crafting user storiesUsing the MoSCoW prioritization methodProgress:Defining "what done looks like." more effectivelyGodspeed y'all,Kevin

Does Every User Story Need to Be Small? Small user stories are essential to success with agile. When it's time to bring stories into an iteration, I always want them to be small.But larger stories have their place as well–especially for something you're not going to work on imminently.Suppose you have just begun work on a new product that will include a set of reports. Because this is a new product, there is nothing to be gained by writing a bunch of small user stories around each one of those reports at this point, especially since you don't yet even know all of the reports that will be needed.At this stage of the project, having one big reporting story rather than a bunch of little ones keeps the size of the backlog more manageable. You'll have one entry in your tool instead of 15 or 20. That's much easier to manage.Further, if you do write all the small user stories, one per report, it gives the impression that you've thought of everything. Early in a project, that's probably not true. New reports will be identified and some that are asked for initially may not be necessary.Don't fall into the trap of thinking every story needs to be small from the beginning. They don't. Instead, plan for stories to shrink in size and grow in detail as they move closer to being brought into a sprint. For most teams, this will happen during the product backlog refinement meeting one or two sprints before the iteration planning where they'll be considered.Letting timing dictate story size will help you succeed with user stories and with agile. 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/

User stories zijn vaak niet de oplossing, maar het probleem. Dat stelt Maarten Dalmijn. Waarom denkt hij dat? En welke alternatieven zijn. Ruud en Maarten bespreken hoe user stories vaak verkeerd worden gebruikt, wanneer ze wel en niet geschikt zijn, en welke andere formats je kunt overwegen. Denk aan Job Stories, GPS-formats en Maartens eigen Improvement Story-format. Dit is een aflevering vol inzichten voor Product Owners die verder willen kijken dan de standaard user story. In deze aflevering hebben we het over: user stories, alternatieven, job stories, GPS-formaten, verbetering, product owners, effectiviteit, agile werken, en storytelling. 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

Send us a textDon't be a project management grinch this holiday season! In this special episode of Project Management Masterclass, host Brittany Wilkins Project Management Professional(PMP) puts a festive spin on the classic 12 Days of Christmas bringing you 12 Days of Project Management. Are you looking to achieve project success? Well tune into the show as Brittany highlights essential elements for project success. From establishing a clear project vision, defining critical milestones, to leveraging Gantt charts and agile methodologies, this cheerful guide will help you reflect, celebrate, and refine your practices as the year comes to a close. Exciting news! Our Project Management Masterclass course is launching soon. If you're ready to elevate your project management skills and boost your Project EQ, join our waitlist today to be the first to know when our course goes live. Don't miss out!Project Management Masterclass SurveyBoost your business to new heights. Partner with us to amplify your brand and achieve unparalleled success. Reach out through our survey for advertising opportunities.Advertising InquiriesWelcome to Project Management Masterclass hosted by Brittany Wilkins. Whether you're a seasoned project manager looking to sharpen your skills or a newcomer eager to learn the ropes, this podcast is your ultimate guide to mastering the art and science of project management. In each episode, we dive deep into the world of project management, bringing you insights, practical tips, and real-life success stories. Get ready to elevate your project management game. Thank you for tuning in to Project Management Masterclass! If you're ready to elevate your project management skills, subscribe for more expert insights. Don't forget to share & review. Until next time, happy managing! Support the show

Alles was ich tue, sollte idealerweise in die Software einzahlen und Dokumentation tut das eigentlich nicht.  In dieser Folge setzen wir uns mit den Herausforderungen und Fallstricken auseinander, die zu Beginn eines Projekts oft auftreten. Probleme von übermäßigen Dokumentationen und User Stories, die zwar gut gemeint, aber oft praxisfern sind. Wie eine starre Fixierung auf umfangreiche Dokumente die Flexibilität und Kreativität im Entwicklungsprozess hemmen kann und warum ein schlanker, fokussierter Ansatz oft zu besseren Ergebnissen führt. Wir besprechen, wie man effektiv zwischen dokumentierten Erwartungen und der realen Umsetzung navigieren kann, um Softwareentwicklung nicht nur effizienter, sondern auch zielgerichteter zu gestalten.  Das ist Besser mit Design, ein Wahnsinn Design PodcastVielen Dank fürs Zuhören

In dieser Podcast-Episode spreche ich mit Alexander Hauser, Business Analyst und Testmanager. Alexander teilt seine Expertise im Bereich der Beratung von Versicherungsunternehmen, insbesondere im Kontext der Implementierung von Standardsoftware. Einführung & Rollenklärung: Alexander erklärt die Rollen von Business Analyst (im deutschsprachigen Raum oft Requirements Engineer genannt) und Testmanager. Der Business Analyst begleitet das Projekt von der Idee bis zur Abnahme, während der Testmanager die Abnahme koordiniert und einen Fokus auf gute Anforderungen und Qualität legt. Diese Rollen harmonisieren gut, da ein Testmanager immer auf gute Anforderungen angewiesen ist. Der Fokus liegt aktuell auf der Implementierung von Standardsoftware (z.B. SAP, ServiceNow), die zwar standardisierte Prozesse bietet, aber an die unternehmensspezifischen Prozesse angepasst werden muss. Die Tests konzentrieren sich daher primär auf die Funktionalität der Modifikationen, nicht auf die gesamte Software. Modifikationen sind beispielsweise das Hinzufügen neuer Felder oder die Konfiguration von bestehenden. Das aktuelle Projekt: Alexander beschreibt ein laufendes Projekt zur Implementierung eines Tools zur digitalen Abbildung von Prozessen. Ziel ist die Effizienzsteigerung durch Digitalisierung und Harmonisierung von verschiedenen Tools innerhalb des mittelständischen Unternehmens (ca. 500 Mitarbeiter). Das Tool bietet vorgefertigte Module für Standardprozesse (z.B. ITSM, Vendor Risk Management) basierend auf ITIL (IT Infrastructure Library), einer Sammlung von Best Practices. Alexander ist in diesem Projekt als Testmanager tätig. Die Business Analyse wurde von einem anderen Dienstleister durchgeführt und in User Stories mit Akzeptanzkriterien im Gherkin-Format (Given-When-Then) verpackt. Dieses Format ermöglicht sowohl manuelle als auch automatisierte Tests. Das Projekt läuft seit Dezember 2021 und erhält laufend neue Anforderungen, wodurch ein festes Projekt-Ende schwer zu definieren ist. Dies ist ein typisches Problem bei Softwareprojekten, bei denen Anpassungen und Erweiterungen stetig hinzukommen. Alexanders Rolle als Testmanager: Seine Aufgabe besteht darin, den Testprozess zu managen, die Testbarkeit von Anforderungen sicherzustellen und den Fachbereich bei der Erstellung und Durchführung von Testfällen zu unterstützen. Er arbeitet mit Jira und Xray. Der Fachbereich erstellt Testfälle basierend auf den User Stories und Akzeptanzkriterien im Gherkin-Format. Diese Testfälle sind detaillierter als die Gherkin-Szenarien selbst und beinhalten konkrete Handlungsanweisungen (z.B. Klickanweisungen). Der Testprozess umfasst die Schulung des Fachbereichs, die Erstellung von Testfällen (2-4 Wochen), die Testausführung (2-4 Wochen) und abschließende Smoke Tests nach der Produktivsetzung. Die Dokumentation der Tests ist wichtig, um die getesteten Punkte nachvollziehbar zu machen. Herausforderungen & Erfolgsfaktoren: Eine Herausforderung ist die Motivation des Fachbereichs, der neben seinen regulären Aufgaben auch die Testtätigkeiten durchführen muss. Alexander betont die Wichtigkeit der frühzeitigen Einbindung und Begleitung der Mitarbeiter. Ein weiterer wichtiger Punkt ist die Qualität der Anforderungen. Inkonsistente Formulierungen und fehlende Details erschweren den Testprozess. Alexander sieht hier Potenzial in der Nutzung von ChatGPT zur Verbesserung der Qualität der Anforderungen. Die Frage, ob interne oder externe Tester eingesetzt werden sollen, ist abhängig von der Qualität der Anforderungen. Gut spezifizierte Anforderungen ermöglichen den Einsatz externer Tester. Alexander betont die Wichtigkeit von klaren und einheitlichen Anforderungen, um den Testprozess effizienter zu gestalten. Seine wichtigste Lernerfahrung ist, dass "Quick and Dirty" in manchen Fällen effektiver ist als eine übermäßige Detaillierung, wenn die Ressourcen begrenzt sind. Oftmals ist ein gemeinsames Klären offener Fragen mit Entwicklern und Fachbereich effektiver als perfekte Dokumentation. Die Effizienz des Testprozesses hängt stark von der Qualität der Anforderungen ab. Eine klare und einheitliche Formulierung der Anforderungen, z.B. mit Unterstützung von Tools wie ChatGPT, ist der Schlüssel zu einem erfolgreichen Projekt. Flexibilität und pragmatische Ansätze, die die begrenzten Ressourcen berücksichtigen, sind ebenfalls entscheidend. Interessierte an Business Analyse und Testmanagement im Versicherungsbereich können sich unter https://pielaco.com melden. Links in dieser Ausgabe Zur Homepage von Jonas Piela Zum LinkedIn-Profil von Jonas Piela Zum LinkedIn-Profil von Alexander Hauser

Quality and Agile thrive together by putting your customer at the centre of what you do.Join PMI Senior Consultant Anthony Richardson as he reveals how Agile tools like Empathy Maps, User Stories, and Retrospectives enhance both flexibility and customer satisfaction, debunking the myth that Agile improvement sacrifices quality for speed.With insights into the crucial role of the Product Owner and the power of Continuous Improvement, this episode will inspire you to adopt strategies that elevate your business practices, keeping Quality front and centre.More from PMI: Dive into our Knowledge Hub for more tools, videos, and infographics Join us for a PMI LIVE Webinar Follow us on LinkedIn Take your improvement career to the next level with PMI's Lean Six Sigma Certifications - now available in two new and accessible formats, built around you. Explore On Demand >> Explore Distance Learning >>

Karla Merza: How Open Feedback Can Transform a Product Owner's Approach, And Help Agile Teams Succeed The Great Product Owner: The PO As A Facilitator For The Team Karla describes a Product Owner who was open to feedback and continuously sought collaboration with the Scrum Master and the team. This PO's willingness to engage in discussions and act on feedback fostered a productive and collaborative environment. They consistently asked how they could better support the team, demonstrating empathy and a strong commitment to continuous improvement. The Bad Product Owner: When The PO Protects The Team Too Much! In contrast, Karla shares a story of a Product Owner who unintentionally held back the team by poorly writing epics and user stories. This PO tried to shield the developers from unnecessary involvement but ended up creating more confusion. Fortunately, they were open to feedback, and with coaching, they learned the importance of involving the team in discussions to avoid miscommunication. [The Scrum Master Toolbox Podcast Recommends]

The #1 Most Common Mistake With User Stories Output is a fixation we can't seem to shake in the product space. We continue to think we know the right product to build before we build it. This often shows up in the way we treat user stories as requirements. Even though many product teams and managers think user stories are requirements, they aren't.  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/

BONUS: Mastering Remote Work in Agile Teams With Antony Marcano NOTE: We want to thank the folks at Tuple.app for being so generous with their stories, and supporting the podcast. Visit tuple.app/scrum and share them if you find the app useful! Remember, sharing is caring!   In this BONUS episode, Antony, co-founder of RiverGlide and Head of Engineering at Ford Digital, joins us to share his experiences and insights from 30 years in software development, including 25 years in Agile practices. As a technical practitioner, leader, and consultant, Antony reflects on navigating remote work, overcoming challenges, and setting up successful remote software teams, while exploring future trends in the industry. The Shift to Fully Remote Work Antony reflects on his first fully remote software project, which took place during the pandemic when everyone was forced to work from home. While his team had been working together for 12 months, they struggled with traditional video conferencing tools that lacked the ability to support pair programming or mob programming effectively. This is when Antony and his team discovered Tuple, a tool that allows for seamless control sharing and a co-located pairing experience. "Switching to Tuple was a game-changer for us in making remote pairing feel as interactive as in-person collaboration." Overcoming Challenges in Remote Collaboration The biggest challenge Antony identifies in remote work is the loss of serendipitous moments—those random watercooler conversations that often lead to innovation. To address this, Antony encourages teams to create opportunities for these moments by structuring time for informal interactions and fostering a safe and open communication culture. "You can't recreate the watercooler, but you can create opportunities for innovation by encouraging open-door policies and setting up shared virtual spaces." Building Effective Remote Teams For Antony, real collaboration is critical to the success of remote teams. He grew up on XP (Extreme Programming) and believes in the power of pairing and mob programming. Antony emphasizes the importance of maintaining good practices from in-person work, such as prioritizing mental well-being, while adapting to the unique needs of remote teams. "Collaboration is not just about tools—it's about mental well-being, trust, and giving the team what they need to succeed." Keeping Teams on Track with Clear Goals Antony shares his approach to ensuring that teams remain aligned with clear goals and progress tracking. His teams focus on delivering small, incremental slices of work and using techniques like limiting Work In Progress (WIP). Rather than viewing user stories as a list of tasks, Antony encourages teams to focus on the user benefit and desired outcomes. "It's about the ‘why,' not just the ‘what.' User stories should focus on the goal, not just be a list of tasks." The Future of Remote Work in Software Development Looking ahead, Antony predicts that tools will continue to evolve, with AI playing a more significant role in software development. He discusses the possibility of having AI participants in pairing sessions and shares his concerns about the convergence of tools that may lose focus over time. Antony encourages developers to experiment with new technologies and remain open to change. "AI is the next frontier in software development, and we need to embrace how it can enhance our remote work experiences." Recommended Resources for Mastering Remote Work Antony notes that while many resources on remote work are often too generic, there are valuable tools and practices software teams can adopt. He recommends regularly rotating hosts during remote pairing sessions and setting aside time for retrospectives and discussions about the bigger 'why' behind the work. "When pairing, rotate roles, reflect regularly, and always focus on the bigger ‘why' to keep your team aligned and motivated." About Antony Marcano Antony is the co-founder of RiverGlide and Head of Engineering at Ford Digital. With 30 years of software development experience, including 25 years in Agile practices, he is a respected leader, coach, and consultant. Antony has contributed to books and journals and is a keynote speaker at global conferences and universities such as Oxford and McGill. He is also the co-creator of 'PairWith.Us,' and remains a hands-on technical practitioner, specializing in Agile development and leading teams to excel in agility. You can link with Antony on LinkedIn visit RiverGlide.com, or check out RiverGlide TV on YouTube.

In this episode of the Building Better Developers podcast, the hosts delve into the critical role of effective user stories in software development. The discussion highlights how these stories serve as a powerful tool for conveying system requirements and improving both development and testing processes. What Are Effective User Stories? The podcast starts by addressing a common confusion: while many developers are familiar with the term “user story,” defining what constitutes an effective user story can be challenging. Effective user stories are concise narratives describing how a feature or function should behave from a user's perspective. They are designed to simplify the communication of system requirements, making it easier for development teams to understand and implement them compared to traditional flowcharts. An effective user story is not about getting the “correct” format but about clarity and usability. Unlike flowcharts that detail processes through steps and decisions, these stories provide a comprehensive narrative that covers the journey from start to finish, including both the ideal path and potential exceptions. Key Components of Effective User Stories To create effective user stories, several key elements must be included: • Title: A clear and descriptive title helps readers quickly identify the story's purpose. For example, the “User Login Process” concisely overviews the story's focus. • Actors: It is crucial to identify the user or system interacting with the feature. This could be a human user or an automated process. Understanding the story's actor helps define the context and requirements. • Steps: Outline the flow from the starting point to the end goal, detailing the sequence of actions. For instance, a user login story includes entering credentials and receiving access. • Assumptions and Conditions: Specify any assumptions or prerequisites. For example, before a user can log in, the assumption might be that they have already registered and have valid credentials. These components ensure that user stories provide a clear and actionable framework for development and testing. Common Pitfalls with User Stories One common mistake is the belief that user stories always require a physical user. However, even backend systems or automated processes can benefit from this approach. The “actor” in these cases could be a system or service rather than a person. Another issue is the tendency to overcomplicate stories. It's more productive to start with more straightforward user stories and refine them over time rather than trying to cover every possible scenario from the beginning. This approach ensures that essential functionalities are addressed first, while additional details can be added later. Examples of User Stories in Action To illustrate, the podcast provides examples of user stories for a login feature: Story 1: A valid user logs in with correct credentials and gains access. Story 2: An unregistered user attempts to log in and is denied access. Story 3: A registered user enters the wrong password and receives an error message. These examples demonstrate how user stories can cover different scenarios and ensure comprehensive feature testing. Testing with User Stories From a testing perspective, user stories are invaluable. They facilitate black-box testing, focusing on inputs and outputs without delving into the system's internal workings. This method helps verify that the system behaves as expected across various scenarios. Additionally, these stories help identify potential issues or edge cases that might be overlooked during development. By considering different user paths and outcomes, teams can ensure that all possible scenarios are tested thoroughly. Refining User Stories The podcast also emphasizes the importance of refining user stories. Avoid the “choose your own adventure” problem, where a single story covers too many paths. Instead, break complex stories into smaller, manageable ones. This ensures that each scenario is addressed individually and clearly. Final Thoughts The podcast's discussion underscores the value of mastering user stories in software development. By focusing on clarity, simplicity, and comprehensive coverage, these narratives help teams build better software and conduct thorough testing. Whether you're a developer or a tester, understanding and implementing effective user stories is essential for achieving project success and ensuring all requirements are met. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Updating Developer Tools: Keeping Your Tools Sharp and Efficient Building Your Personal Code Repository Your Code Repository and Ownership of Source – Consulting Tips Using a Document Repository To Become a Better Developer The Developer Journey Videos – With Bonus Content

Does Every User Story Have To Be Small? Small user stories are essential to success with agile. When it's time to bring stories into an iteration, I always want them to be small.But larger stories have their place as well–especially for something you're not going to work on imminently.Suppose you have just begun work on a new product that will include a set of reports. Because this is a new product, there is nothing to be gained by writing a bunch of small user stories around each one of those reports at this point, especially since you don't yet even know all of the reports that will be needed.At this stage of the project, having one big reporting story rather than a bunch of little ones keeps the size of the backlog more manageable. You'll have one entry in your tool instead of 15 or 20. That's much easier to manage.Further, if you do write all the small user stories, one per report, it gives the impression that you've thought of everything. Early in a project, that's probably not true. New reports will be identified and some that are asked for initially may not be necessary.Don't fall into the trap of thinking every story needs to be small from the beginning. They don't. Instead, plan for stories to shrink in size and grow in detail as they move closer to being brought into a sprint. For most teams, this will happen during the product backlog refinement meeting one or two sprints before the iteration planning where they'll be considered.Letting timing dictate story size will help you succeed with user stories and with agile, 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/

It's another episode of our segment User Stories, where we (hopefully) help some folks on Reddit. This week we're looking at how to do customer interviews in a way that doesn't bias the interviewee but still provides helpful feedback, how to deal with a VP of Sales who goes running to the CEO to disagree with you about your roadmap, how transparent your start-up leadership should be on key business stats, and how to cope with the minutiae of daily start-up life as a Product Manager. Join the discussion on Reddit: https://www.reddit.com/r/AcceptanceCriteria/ And on the Discord: https://discord.gg/2Tyj8H9MFF The post E038: Is there a right way to interview customers, how to deal with disagreeable stakeholders, and more first appeared on Acceptance Criteria.

It's another episode of our segment User Stories, where we (hopefully) help some folks on Reddit. This week we're looking at whether Product folks should care how Engineering breaks out the items on their backlogs, how panicking in an emergency can lead to worse outcomes, whether anyone ever gets "good" at making roadmaps, and the struggles of an IT director with overbearing colleagues. Join the discussion on Reddit: https://www.reddit.com/r/AcceptanceCriteria/ And on the Discord: https://discord.gg/2Tyj8H9MFF The post E037: How not to panic in a crisis, the varieties of roadmaps, and other Reddit questions first appeared on Acceptance Criteria.

In this episode of the developer podcast, the hosts explore user stories, a crucial tool in gathering effective software requirements. Using a creative analogy comparing user stories to movie ratings, the episode explains how to create detailed and valuable user stories that go beyond the basics. What Are User Stories? User stories are the foundation of understanding how users interact with a system to achieve their goals. At their simplest, these stories capture these interactions in a narrative form, providing insight into the user's experience and needs. For example, consider an office manager using a back-office system: their stories might include actions like entering customer information, processing payments, or looking up employee records. Each of these actions represents a distinct user story, offering a snapshot of the user's journey within the system. The “Happy Path”: Your G-Rated User Story The podcast introduces a unique analogy to explain the concept of user stories: movie ratings. The “happy path” in a user story is akin to a G-rated movie. This scenario represents the ideal situation where everything works perfectly—data is correct, the system functions as expected, and the user easily achieves their goal. The happy path is the most straightforward user story, focusing on the best-case scenario where nothing goes wrong. Expanding the Story: From PG to R-Rated Scenarios But just like in movies, real-world systems rarely stick to the happy path. The analogy progresses to PG-rated scenarios, where minor issues start to appear. These might include small errors like a typo in a phone number or a data entry mistake. In these cases, stories must account for how the system will handle such deviations. Will it alert the user, automatically correct the error, or flag the issue for review? Addressing these scenarios ensures the system is robust and user-friendly. As we move into PG-13 and R-rated scenarios, the complexity increases. Now, user stories must consider more serious problems—such as incorrect data formats, missing information, or system errors. For example, what happens if a user enters an invalid zip code or tries to complete a transaction without sufficient funds? These stories require the system to have validation checks, error handling, and fail-safes to prevent or mitigate these issues. The Extreme Cases: Rated X User Stories The analogy reaches its peak with “Rated X” scenarios—extreme cases where the user might try to break or exploit the system. These could involve malicious activities like SQL injection or simply entering nonsensical data to see how the system reacts. While these scenarios might seem far-fetched, they are critical when developing stories. Addressing these edge cases ensures the system is secure, resilient, and able to withstand unexpected challenges. Deepening User Stories: Peeling Back the Layers To create truly effective stories, it's essential to go beyond surface-level narratives. This means asking “what if” questions and exploring different possibilities that could arise. The host likens this process to peeling an onion, revealing deeper layers of complexity within the user's experience. By considering a wide range of scenarios—from the happy path to the edge cases—developers can create comprehensive and detailed stories that lead to more valuable requirements. The Art of Listening: Capturing the Full Story A critical point emphasized in the episode is the importance of actively listening to the user when gathering stories. Developers often make the mistake of jumping to technical solutions without fully understanding the user's narrative. It's vital to remember that a user story is not about the technology—it's about the user's journey. Developers need to focus on understanding the story itself, ensuring they capture the full picture before diving into the technical implementation. Evolving User Stories: Building on the Narrative User stories are not static—they evolve over time as the user's needs change. The initial story might be simple, like needing a basic payroll system. However, as the user's needs expand, new stories emerge, requiring additional features and functionalities. These new stories can be seen as sequels in a movie series, building on the original narrative to create a more complex and feature-rich system. Recognizing this evolution helps developers design systems that are flexible and capable of adapting to changing requirements. Crafting Comprehensive User Stories This episode of the developer podcast provides a fresh perspective on user stories, using a movie analogy to illustrate the different levels of complexity in requirements gathering. By understanding user stories as evolving narratives and focusing on the user's journey, developers can craft software that meets and exceeds user expectations, leading to more successful and satisfying outcomes. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources How to write effective user stories in agile development? The Importance of Properly Defining Requirements Changing Requirements – Welcome Them For Competitive Advantage Creating Your Product Requirements Creating Use Cases and Gathering Requirements The Developer Journey Videos – With Bonus Content

It's another episode of our segment User Stories, where we (hopefully) help some folks on Reddit. This week, we look at whether you need to love the product you work on, whether there's a magic skill to keeping your energy up in meetings, and how to measure success for your software teams. Join the discussion on Reddit: https://www.reddit.com/r/AcceptanceCriteria/ And on the Discord: https://discord.gg/2Tyj8H9MFF The post E035: Do you have to love the products you work on? And more Reddit questions first appeared on Acceptance Criteria.

Why you shouldn't use AI to write your tests, and the crazy deals new AI companies are getting themselves into to access hardware.

It's the another batch of User Stories, where we help some Redditors try and solve their problems. From a truly toxic environment where a Product Manager has been pitted against their Engineering Manager by bad leadership, to dealing with engineers being pulled off your team because they are the Subject Matter Experts and need to help other teams, we mostly try and tell people how to avoid getting caught in the same hopeless situation as these two question askers. And then we discuss what it would take for someone to break into the worlds of Product Management and Enterprise Architecture, from certification options to finding other roles that are often feeders into those career tracks. Join the discussion on Reddit: https://www.reddit.com/r/AcceptanceCriteria/ And on the Discord: https://discord.gg/2Tyj8H9MFF The post E028: A toxic Product/Engineering relationship, plus how to break into Product or Enterprise Architecture first appeared on Acceptance Criteria.

It's another episode of User Stories and Market Factors as we try to help some Redditors with their questions and look at recent news. Whether it's what to do when you get vague incomplete user stories from a business analyst, prioritizing bugs and tech debt with or with out a product manager's help, or figuring out how to map the architecture of your company's software platforms, we've got some (hopefully) helpful advice. And then we look at some recent changes at Twitter (now X), including a disastrous Find/Replace update and a change to how new users can't really do much without paying Elon first. And then a look at Post.News shutting down and what that says about the current state of the social network landscape, as well as following up on the latest with Apple's antitrust suits in the EU and US. Join the discussion on Reddit: https://www.reddit.com/r/AcceptanceCriteria/ And on the Discord: https://discord.gg/2Tyj8H9MFF The post E026: Can PMs help prioritize tech debt, how to map architectures, and why are Twitter and Facebook still on top? first appeared on Acceptance Criteria.

Writing Effective User Stories - User stories are often written poorly, leading to challenges in estimation and development. - They should be small, easy to understand, and consumable by developers. - Agile coaches can help teams write better user stories by providing tools and guidance. Using User Stories Effectively - User stories should provide value to users. - Improper use of user stories can lead to confusion and ineffective implementation. - Organizations should consider the limitations of their systems when using user stories. Writing User Stories - Writing better user stories is not the main goal. - Spending more time writing user stories means less time for collaboration and understanding. - Educating teams on writing effective user stories can be beneficial. Writing smaller user stories for faster delivery - Writing smaller user stories can lead to faster delivery and increased velocity. - It's important to understand the reasons behind requests for smaller stories and to provide assistance in writing better user stories. - Focusing on smaller stories can help avoid piling up work and toiling unnecessarily. Focusing on Collaboration over Documentation - Shifting focus from documentation to collaboration and working software. - Writing better user stories emphasizes collaboration rather than documentation. - Encouraging a mindset change to improve user story practices in organizations. Influence of User Feedback on System Improvement - Users' time investment in writing should be valuable. - Feedback can drive system changes.

Does your team struggle with large, complex user stories that don't fit in a sprint?

In this episode of #AgileWay podcast I have a conversation with Fred Williams about putting people into User Stories so we can have an empathy and same understanding of the user needs and dreams so that we can create a better product that focus on people.   #agile #userstory #backlog #users #empathy #people 

Are User Stories The Same as Requirements? - Mike Cohn Are user stories the same as requirements? Not quite, but they're close. Rather than thinking of a user story as a requirement, I find it more useful to think of each story as a pointer to a requirement. Most commonly, every story is a placeholder for a future conversation between the team and its stakeholders. During that conversation, stakeholders will convey the details about what is needed. If more detail is needed than can be conveyed in a conversation, the story may point to a flow diagram, a sketch of the user interface, sample data, instructions on how to perform a calculation, or so on. A user story itself is too vague to be considered a requirement. You're better off thinking of a story as a pointer to a requirement. 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/

It's another dual-topic episode where we answer questions, give advice, and look at some recent news stories. We start with some questions debating User Stories vs Wireframes, how to break an Epic into User Stories, and whether you can be a Product Manager and be liked. And then we dig into the latest ways AI is enabling humans to do terrible things, including a start-up that wants to scan your junk for STIs in a medically inaccurate way, an eastern European candidate who possibly lost his election thanks to an AI Deep Fake, and the US House of Representatives blocking access to Microsoft's Copilot AI before it could accidentally leak government secrets. Also, Zuckerburg tried to hack your phone to snoop on Snapchat. Join the discussion on Reddit: https://www.reddit.com/r/AcceptanceCriteria/ And on the Discord: https://discord.gg/2Tyj8H9MFF The post E021: Crafting better User Stories, battling AI deep fakes, and more… first appeared on Acceptance Criteria.

Tom Baldwin: From Centralized to Collaborative, Cultivating Independent Agile Teams 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. As Tom steps into a team entangled with centralized communication and decision-making issues, he shares his strategic approach to fostering team independence and effective communication, especially during a managerial hiatus. Key strategies include direct dialogue among team members, engaging leadership in problem-solving discussions, and advocating for managerial coaching, drawing upon a real-life transformation where team autonomy and progress shine despite initial resistance. Featured Book of the Week: The Scrum Field Guide by Mitch Lacey Tom sheds light on the pivotal role The Scrum Field Guide by Mitch Lacey played in his Scrum Master journey, emphasizing its approachability and practical insights into role expectations, task decomposition, and work management. With anecdotes and tips like fitting work to time and embracing various work breakdown strategies. In this episode, we also refer to the episode with Anton Skornikov on slicing User Stories. [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Tom Baldwin Tom is a Lean-Agile Coach & Scrum Master, who is trying to solve the problem that it has been more than 20 years since the Agile Manifesto, but Business Agility is still not the norm. Tom is currently writing “Production line for the mind: The Practicing Principle”, with the idea of making agility simple to understand & to implement – and not just for software. You can link with Tom Baldwin on LinkedIn.

It's our User Stories segment where we take some questions from Reddit and try to help a few people out. We also look at some Market Factors, with the Department of Justice's anti-trust suit against Apple's monopoly power with the iPhone and a look at the state of Gmail as it turns 20. Join the discussion on Reddit: https://www.reddit.com/r/AcceptanceCriteria/ And on the Discord: https://discord.gg/2Tyj8H9MFF The post E020: Bad stand-ups, PI Planning, Gmail turns 20, and DOJ vs Apple first appeared on Acceptance Criteria.

Kate and Ryan discuss using Gherkin to help clarify Acceptance Criteria in User Stories

Are User Stories & Story Points Required? No... - Mike Cohn I'm often asked if user stories are part of Scrum.No, they're not. You can have a phenomenally successful team and never work with user stories at all.At its core Scrum is a very small set of rules. The Scrum rules are defined in the Scrum Guide, and they're things like keeping sprints short, no longer than a month.Outside this core of rules are the generally accepted Scrum practices. These are good ideas every Scrum Master should be aware of, but that a team doesn't necessarily need to do. User stories fit here.A great Scrum Master should know what user stories are. They may think stories are awful and not recommend using them for a team, but they should at least know what they are.What about Story Points?Story points are another generally accepted Scrum practice that isn't officially part of Scrum.Story points are a useful way for team members to agree on an estimate. Points get around a common problem: A senior team member thinks something will take one day, a junior team member thinks two days, and they're both right depending on who does the task.I think story points are great because they help you avoid pointless debates, they save time, and they increase the chances that your estimates will be accurate. They are my recommended unit for estimating product backlog items.But not every team needs to estimate! And you certainly don't have to use story points if you do estimate–you can use person days or some other unit if you prefer.I do, however, think that you should give story points and user stories a try. For the majority of teams, they are both great practices that will help you succeed with agile, 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/

Maryse Meinen: Value Over Velocity, A Product Owner's Journey to Value-Driven Development, NoEstimates Unplugged Week This is one of a series of episodes where Product Owners explain how they used, and benefited from #NoEstimates in their work with teams.  To know more about #NoEstimates, sign-up to get the first 3 chapters of the book here. Introduction to #NoEstimates Maryse Meinen shares her journey into agile and lean methodologies, highlighting a pivotal moment at her first international conference where she attended a workshop on #NoEstimates led by Seb Rose. The workshop's quiz on estimating the distance from Earth to the moon led her to an epiphany about the common tendency to provide estimates even when uncertain, driven by peer pressure—an insight that spurred her to experiment with the #NoEstimates approach.   A Real-World Example of Success Maryse describes her experience with a new team tasked with developing an infrastructure solution without relying on traditional estimates. By focusing on conversations, card confirmations (the 3 C's of User Stories), and refining story points to either 1 or 0 based on whether a story was refined, the team managed to prioritize work more effectively. The practice of making items as small as possible and focusing on delivering value in various forms proved to be beneficial. Challenges in Implementation The biggest challenge in implementing #NoEstimates was not from management or stakeholders, but rather from inexperienced scrum masters resistant to deviating from traditional estimation techniques. Maryse found success by allowing the team space to operate independently and focusing on outcomes rather than estimates. Impact on Planning and Prioritization Shifting the focus from estimates to value delivered led to a significant change in how Maryse's team approached planning and prioritization. By setting sprint goals around solving real problems for real people, the team moved away from a task-centric to a value-centric approach. One of the core tenants of the #NoEstimates approach. Measuring Progress Without Estimates Maryse's team measured progress by the problems they solve, framing sprint goals around these problems and communicating achievements in terms of value delivered to stakeholders, rather than in traditional estimation-driven progress metrics, like tasks completed - which would not necessarily deliver any value to end-users and customers. Advice and Resources for #NoEstimates Maryse encourages teams to start experimenting with #NoEstimates and emphasizes the importance of continuous learning and adaptation. She recommends engaging with the #NoEstimates community on Twitter and exploring resources by Allan Kelly and Seb Rose, as well as the NoEstimates book.   About Maryse Meinen Maryse is an Product Owner dedicated to fostering experimentation, agility, and empathy within organizations. She builds and facilitates great teams, coaches leaders, and believes in simplicity and human-centric methodologies. With expertise in Lean/agile development and a passion for teaching, she shapes adaptive and learning-focused cultures. You can link with Maryse Meinen on LinkedIn.

Have you ever returned to an old User Story and wondered, “what was I thinking?” On today’s episode, Mike Cohn, walks us through how and why he recently revisited and updated 200 Real Life User Story Examples from his past projects and updated a resource for you! Listen in as Mike and Brian share what worked and what didn’t work from the past, in an effort to make their user story writing skills stronger. Overview What makes a user or job story great? In this episode of the Agile Mentors Podcast, Brian Milner and Mike Cohn of Mountain Goat Software, share Mike’s recent updates and edit to 200 Real Life User Story Examples. Listen as they revisit 200 older user stories, breaking down their analysis through the lens of more experience and an evolving technological landscape. Plus, in true iterative fashion, Mike shares how he is still working to write better user stories after years of perfecting and teaching the art of story writing. Tune in to learn what makes a great clear user story, and what makes a story that stinks. Listen Now to Discover: [00:57] - Brian is joined today by Mike Cohn who will be revisiting user stories. [02:58] - Mike talks about how he came back to these 200 user stories and decided that some of them sucked and needed updating. [04:42] - When writing user stories, Mike talks about prioritizing meaningful conversations over perfect user stories. [06:35] - Brian underscores the importance of efficient communication with developers through unconventional yet practical user stories. [07:22] - Brian points to previous podcast episodes with Mike that delve into the basics of writing user stories, in episode, #10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn and #39 The Art of Writing User Stories with Mike Cohn [08:22] - Mike walks through a story written for the development of the Scrum Alliance website, noting it is framed well within the site's premise. [09:10] - Brian raises considerations about inserting information mid-story. [09:57] - Mike finds the story intriguing but suggests simplifying it by moving details into acceptance criteria, a notion that didn’t exist at the time, for clarity. [12:03] - Mike advocates for concise user stories, suggesting omitting unnecessary details and using acceptance criteria for specifics. [13:52] - In a job story example, Mike and Brian point out common mistakes from an era without distinct fields. [16:34] - Brian understands the attempt to prompt discussion in the job story but finds it normal overall. [17:32] - Mike critiques a job story for site admins approving job postings, suggesting modernizing language for notification methods and flexibility. [19:34] - Reflecting on a story about user authentication, Mike acknowledges a bias toward email-centric perspectives, and questions if this story goes too far separating the what and the how. [21:22] - Mike highlights story #42, recognizing a potential mistake in specifying UI details in a story about navigating job listings. [23:24] - If you’re struggling to get your team or organization on the same Agile page from team members to senior executives. Mountain Goat Software can help you Build a Common Understanding of Agile on your team! [24:17] - If you’re a visual learner or you’d like to follow along, you can find the pdf of all the user and job stories discussed in this episode, plus many more, right here. [25:12] - Mike defends a story about viewing detailed course pages, acknowledging UI implications but justifying the necessity of the detail. [27:13] - Mike critiques a user story about creating user accounts, cautioning against a potentially misleading "so that" clause with a specific example. [29:18] - Reflecting on the evolution of user stories, Mike emphasizes a shift from stating "I can" or "I want to" to a more neutral "I." [30:40] - Critiquing a user story about browser compatibility, Mike suggests that it's a nonfunctional requirement and better suited as part of the definition of done. [33:18] - Brian presents a user story for Mountain Goat Software’s Planning Poker tool about database indexes, expressing reservations about the commonality of developer-focused stories. [34:00] - Mike reflects on the “as a developer” story and expresses uncertainty about its inclusion, considering it potentially problematic. [36:22] - Mike critiques a story about database analysis, acknowledging its verbosity but justifying the detail as necessary for clarifying the researcher's role and objectives. [38:03] - Brian appreciates the brevity of the "I want" part of a user story and finds the "so that" clause acceptable as it provides examples and context for developers. [38:39] - Considering a story about storing results, Mike deems it not bad but potentially too long. [40:00] - Mike highlights that the best way to get better at writing stories is to write a bunch of them, acknowledging that his early stories taught him valuable lessons. [41:03] - Brian thanks listeners and invites them to share and subscribe to the Agile Mentors Podcast on Apple Podcasts. [41:29] - Do you have feedback or a great idea for an episode of the show? Great! Just send us an email. References and resources mentioned in the show: Free download: 200 User Story Examples #10 Why User Stories are the Best Way to Capture Requirements with Mike Cohn #39 The Art of Writing User Stories with Mike Cohn User Stories Applied: For Agile Software Development by Mike Cohn Job Stories Offer a Viable Alternative to User Stories by Mike Cohn Mountain Goat Software’s Planning Poker Better User Stories Course Build a Common Understanding of Agile Subscribe to the Agile Mentors Podcast on Apple Podcasts Mountain Goat Software Certified Scrum and Agile Training Schedule Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn, CEO of Mountain Goat Software, is a passionate advocate for agile methodologies. Co-founder of Agile Alliance and Scrum Alliance, he thrives on helping companies succeed with Agile and witnessing its transformative impact on individuals' careers. Mike resides in Northern Idaho with his family, two Havanese dogs, and an impressive hot sauce collection.

Johannes Andersen: Collaboration Over Isolated Performance, Lessons Learned as a Scrum Product Owner 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, Johannes shares a personal story of his struggles as a Product Owner (PO). In his early career, Johannes believed he needed to have all the answers and provide detailed requirements alone; but he quickly found that it was not so easy to define all the features by himself. This experience taught him the importance of involving the entire team in writing user stories, highlighting that collaboration, not individual effort, leads to success. Johannes emphasizes focusing on outcomes, encouraging POs to ask goal-oriented questions and to view technical solutions through the lens of their importance. He recommends resources like Mike Burrows' list of questions to foster effective communication and collaboration.   [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 Johannes Andersen Johannes comes from a finance and fintech background, and is now an enterprise agility maestro at a leading telco in Copenhagen! He focuses on optimizing the flow from strategy to execution, championing portfolio management with a keen eye on doing the right things, even if imperfectly. Johannes is an international speaker on product development topics. You can link with Johannes Andersen on LinkedIn.

There's no doubt the transition to Apple products has revolutionized professional and personal productivity. In this episode, we hear from several industry experts here at SHI who share their experiences transitioning to Apple from other platforms, the influence of Apple technology on job performance and professional image, and the challenges and benefits of using Apple products in various work settings. The diverse experiences of our guests reflect the versatility, adaptability and power of the Apple ecosystem. Plus, we explore the latest developments, including the introduction of Apple's Vision Pro device.Join as we discuss:The impact of using Apple products on personal and professional productivityThe evolution of Apple technology in the professional worldPersonalization and flexibility with Apple products for work, travel and collaboration

Nesse episódio do podcast, Fernando Okuma, Gilberto Nunes e Pedro Arlego falam sobre o User Story Mapping, explicando seu uso e importância em um projeto.

In this seventh installment of the ORCA Series, Sophia brings some holiday cheer while covering CTA Requirements. Revisiting the Santa Delivery App from ORCA Series #6, Relationship Requirements, she explores the four ways you can upgrade your basic user stories, plus how to use AI to help you fill in the gaps you might have missed. LINKS: Listen to the rest of the ORCA Series episodes. Give yourself the gift of OOUX with the Self-Paced OOUX Masterclass. Continue the conversation on The OOUX Forum! --- Support this podcast: https://podcasters.spotify.com/pod/show/ooux/support

On today's episode, Elixir Wizards Owen Bickford and Dan Ivovich compare notes on building web applications with Elixir and the Phoenix Framework versus Ruby on Rails. They discuss the history of both frameworks, key differences in architecture and approach, and deciding which programming language to use when starting a project. Both Phoenix and Rails are robust frameworks that enable developers to build high-quality web apps—Phoenix leverages functional programming in Elixir and Erlang's networking for real-time communication. Rails follows object-oriented principles and has a vast ecosystem of plug-ins. For data-heavy CRUD apps, Phoenix's immutable data pipelines provide some advantages. Developers can build great web apps with either Phoenix or Rails. Phoenix may have a slight edge for new projects based on its functional approach, built-in real-time features like LiveView, and ability to scale efficiently. But, choosing the right tech stack depends heavily on the app's specific requirements and the team's existing skills. Topics discussed in this episode: History and evolution of Phoenix Framework and Ruby on Rails Default project structure and code organization preferences in each framework Comparing object-oriented vs functional programming paradigms CRUD app development and interaction with databases Live reloading capabilities in Phoenix LiveView vs Rails Turbolinks Leveraging WebSockets for real-time UI updates Testing frameworks like RSpec, Cucumber, Wallaby, and Capybara Dependency management and size of standard libraries Scalability and distribution across nodes Readability and approachability of object-oriented code Immutability and data pipelines in functional programming Types, specs, and static analysis with Dialyzer Monkey patching in Ruby vs extensible core language in Elixir Factors to consider when choosing between frameworks Experience training new developers on Phoenix and Rails Community influences on coding styles Real-world project examples and refactoring approaches Deployment and dev ops differences Popularity and adoption curves of both frameworks Ongoing research into improving Phoenix and Rails Links Mentioned in this Episode: SmartLogic.io (https://smartlogic.io/) Dan's LinkedIn (https://www.linkedin.com/in/divovich/) Owen's LinkedIn (https://www.linkedin.com/in/owen-bickford-8b6b1523a/) Ruby https://www.ruby-lang.org/en/ Rails https://rubyonrails.org/ Sams Teach Yourself Ruby in 21 Days (https://www.overdrive.com/media/56304/sams-teach-yourself-ruby-in-21-days) Learn Ruby in 7 Days (https://www.thriftbooks.com/w/learn-ruby-in-7-days---color-print---ruby-tutorial-for-guaranteed-quick-learning-ruby-guide-with-many-practical-examples-this-ruby-programming-book--to-build-real-life-software-projects/18539364/#edition=19727339&idiq=25678249) Build Your Own Ruby on Rails Web Applications (https://www.thriftbooks.com/w/build-your-own-ruby-on-rails-web-applications_patrick-lenz/725256/item/2315989/?utm_source=google&utm_medium=cpc&utm_campaign=low_vol_backlist_standard_shopping_customer_acquisition&utm_adgroup=&utm_term=&utm_content=593118743925&gad_source=1&gclid=CjwKCAiA1MCrBhAoEiwAC2d64aQyFawuU3znN0VFgGyjR0I-0vrXlseIvht0QPOqx4DjKjdpgjCMZhoC6PcQAvD_BwE#idiq=2315989&edition=3380836) Django https://github.com/django Sidekiq https://github.com/sidekiq Kafka https://kafka.apache.org/ Phoenix Framework https://www.phoenixframework.org/ Phoenix LiveView https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html#content Flask https://flask.palletsprojects.com/en/3.0.x/ WebSockets API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API WebSocket connection for Phoenix https://github.com/phoenixframework/websock Morph Dom https://github.com/patrick-steele-idem/morphdom Turbolinks https://github.com/turbolinks Ecto https://github.com/elixir-ecto Capybara Testing Framework https://teamcapybara.github.io/capybara/ Wallaby Testing Framework https://wallabyjs.com/ Cucumber Testing Framework https://cucumber.io/ RSpec https://rspec.info/

BONUS: The Art Of Crafting User Stories with Christopher Lee In this episode, we talk with Christopher Lee about his latest book, "The Art Of Crafting User Stories." Christopher shares the fascinating origin story of his book and how principles of product management were applied to its creation.  Product Development Insights Christopher draws intriguing parallels between software development and book creation, highlighting two key concepts that apply to both realms. He introduces the concept of "debugging for books" and shares essential tips, like the importance of having multiple content reviewers and utilizing the technique of "Rubber Duck Debugging" for authors. The examples he uses also clarify how his approach to Product Management can help you with software products. Learning To Empathize With The User We discuss how understanding the user perspective is a critical skill for Product Owners and teams, and enables them to write better User Stories. Christopher emphasizes the development of perspective-taking and compassion for others, starting with self-reflection. He introduces tools like "The Feeling's Wheel" and explores the concept of uncovering the needs behind user needs, known as "Jobs to be Done." In this segment, we also refer to User Story Mapping, Google Design Sprints, and the book Radical Candor. Crafting User Stories: Avoiding Ambiguity Christopher shares some of the most effective tools to help teams truly empathize with their software users, fostering a deeper understanding that can greatly inform the user story process. Delving into the actual act of writing user stories, Christopher provides invaluable advice on avoiding ambiguity. He advocates for collaborative efforts with engineering and design teams, using user stories as a foundation. Additionally, he introduces the "Given - When - Then" format for clarity and efficiency. Navigating User Story Estimation, Other Planning Challenges  Christopher addresses common challenges in user story estimation and emphasizes the importance of adaptability in Agile and User Stories. He offers strategies to prevent downstream consequences and encourages direct engineer-user interaction for swift feedback. Prioritization is a critical aspect of planning that Christopher dives into, providing a toolkit of models and methods. He emphasizes the importance of aligning product development with organizational mission and North Star metrics, ultimately honing in on the right end-users. Expert Interviews, Bringing Different Perspectives On User Stories Christopher introduces a unique element in his book—expert interviews. These interviews offer diverse perspectives on Agile, user stories, and collaborative work, enriching the reader's experience and understanding. Parting Words of Wisdom In a final piece of advice, Christopher underscores that crafting user stories is a team effort, emphasizing that no one person can do it alone. About Christopher Lee Christopher Lee is a seasoned Product Management Coach, known for his expertise as a product manager and technology consultant. His insights into the industry are encapsulated in his book, 'The Art of Crafting User Stories', and advanced product management methodologies he created when at Ernst & Young. You can link with Christopher Lee on LinkedIn and connect with Christopher Lee through the Product Coach Labs.

Let's Master Acceptance Criteria for Agile User Stories! Reach out directly to me if you need help!   Text me 757-759-5282

Let's Talk About User Stories - Mike Cohn Tip # 1: Start with some definitionsA user story describes something a user wants. The story usually follows this template: “As a [type of user], I [want or need or am required to do this thing] so that [I can accomplish this goal].”An epic is a big user story. That's it. Nothing more, nothing less.A theme is a collection of related user stories. Some people have introduced the term feature to mean a user story that is big enough to be released or perhaps big enough that users will notice and be happier.All of these definitions are only useful if they simplify discussion about the product you are developing. Tip #2: Add the Right Detail at the Right TimeLike Goldilocks and the bears, we don't want items in the product backlog with too little or too much detail—we want detail that is just right.If a product owner writes a user story that includes too little detail, the developers won't know enough during sprint planning to understand what to build. When excessive detail is included, the time and money spent adding that unnecessary detail is wasted.It's unlikely a team's product backlog will be detailed perfectly right off the bat. This means the team will likely have to iterate toward the right amount of detail.I find it much easier for team members to strike the right balance when they start with too little detail. So start by filling in the user story template with the bare minimum amount of product features and detail, and go from there.Tip #3: Learn the SPIDR Method for Splitting StoriesOne of the most common struggles faced by agile teams is the need to split user stories. I'm betting you've struggled with this, because I certainly did at first. That's why I came up with an easy-to-remember acronym to detail the five different factors that might help you split a story. Spike, Path, Interfaces, Data, and Rules.I hope these tips help you and your team succeed with agile 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 Marketing Over Coffee: Learn About The 5P Framework, User Stories, Competitive Analysis, and More! Direct Link to File Brought to you by our sponsors: LinkedIn and Bloomreach What is the 5P Framework? How to do Requirements Management Adding in User Stories 8:00 LinkedIn – We’ve got a special offer for Marketing Over Coffee Listeners, you can redeem a […] The post Katie Robbert on Marketing Strategy appeared first on Marketing Over Coffee Marketing Podcast.