Podcasts about user story mapping

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?

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.

Iscriviti alla community dei Tech Leader italiani

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

Topics DiscussedCharacteristics of Well-Maintained Software: Tekin emphasizes the importance of software that is easy to change and tailored to the team's needs.Balancing Complexity and Team Size: Tekin discusses how his small team manages complexity and features to maintain sustainable work practices without overburdening the developers.GovUK Project Insights: Tekin shares his experiences working on the GovUK project, highlighting the challenges and breakthroughs in rationalizing the UK's government digital real estate.Version Control Best Practices: Tekin and Robby delve into the importance of well-written Git commit messages and how they preserve institutional knowledge.Connecting with End Users: Tekin advocates for developers to get closer to end users to better understand their needs and deliver more effective solutions.Key TakeawaysMaintaining software sustainability is crucial, especially for small teams.Intentional decisions about growth and complexity can prevent burnout and maintain productivity.Direct interaction with end users can significantly improve software quality and usability.Effective version control practices help preserve valuable institutional knowledge.Organizations should balance parallel work to avoid overburdening development teams.Resources MentionedGovUK GitHub RepositoryProgramming as Theory Building by Peter Nauer User Story Mapping by Jeff PattonA Branch in Time (a story about revision histories)Tekin on Ruby.socialJoin Together CooperativeBook Recommendation: Palestine +100: Stories from a Century After the NakbaDon't miss this insightful conversation with Tekin Süleyman as he shares his journey and best practices for maintaining sustainable software within small teams.Thanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

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.

"Jako użytkownik chcę przeszukać bazę książek, aby znaleźć kilka książek" - takiego rodzaju User Story są niestety dość typowe i w zasadzie niewiele dobrego wnoszą do projektu. A trudności, jakie często pojawiały się przy formułowaniu wartościowych User Story, skutkowały się pojawianiem różnych technik wspomagających ich rozpoznanie. Kuźnią wielu pomysłów były prace zespołów stosujących Extreme Programming w projektach Chrysler C3 i Connextra... Kompleksowe podejście zarówno do identyfikacji User Stories jak i ich dalszego wykorzystania z projekcie zaproponował w końcu w 2014 roku Jeff Patton, proponując warsztatową technikę User Story Mapping.W tym odcinku Better Software Design dodajemy więc User Story Mapping do naszego analitycznego toolboksa. A moim gościem w tej rozmowie jest Michał Bartyzel, który bardzo mocno wykorzystuje tę technikę w swojej codziennej pracy z zespołami. W tym odcinku rozmawiamy z Michałem między innymi o:bezużyteczności wielu historyjek typu "Jako klient chcę się zalogować, aby zrobić zakup w sklepie",odkrywaniu właściwych aktorów, ich celi biznesowych i funkcjonalności, które służą ich osiągnięciu,sposobach budowania mapy historyjek, zgodnie z założeniami User Story Mappingu,wykorzystaniu USM w projekcie,różnicach i podobieństwam pomiędzy EventStormingiem i User Story Mappingiem,sposobach prowadzenia warsztatu analitycznego.Materiały dodatkowe:It's All in How You Slice, artykuł Jeffa Pattona opisujący pierwotne założenia techniki, rozwiniętej następnie do User Story MappinguThe New User Story Backlog is a Map, drugi po artykule istotny wpis Pattona na temat problemów z historyjkamiUser Story Mapping: Discover the Whole Story, Build the Right Product, książka Jeffa z 2012 roku, przedstawiająca technikę User Story MappinguStory Map Concepts oraz Agile Story Essentials, krótkie i rzeczowe podsumowania pokazujące zasadę działania USMPolecam także zajrzeć na stronę Michała, a w szczególności na prowadzonego przez niego bloga.Zapraszam!

La Product Transformation secondo WeRoad. Simone Basso, CTPO @WeRoad, racconta passo dopo passo come passare dalla strategia all'execution.In questo podcast trovi l'audio del meetup di Firenze che si è svolto il 16 novembre scorso nella sede di Nana Bianca. Il protagonista è Simone Basso, CPTO in WeRoad. Al centro dell'intervento di Simone c'è il passaggio dalla strategia all'execution. E se ascolterai il podcast ti accorgerai che lui propone una guida step by step, talmente curata nel dettaglio che è come se avesse sintetizzato in soli 20 minuti tutti i contenuti che solitamente noi come Product Heroes trattiamo nei nostri master. Simone ha parlato di The rule of 3, Strategia, Struttura del Team, Roadmap, Esecuzione e di tanto altro. In virtù del suo ruolo, Simone Basso gestisce il team di digital product, composto da oltre 30 esperti di ingegneria, prodotto e UX distribuiti nei vari mercati di WeRoad, ed è di fatto il responsabile della definizione della visione del prodotto e del miglioramento delle operazioni tecniche. Nel corso della sua carriera ha lavorato sia all'Estero che in Italia e ha guidato i team di Just Eat, GetYourGuide e Indie Campers.---Product Heroes è il punto di riferimento per il Product Management in Italia.ℹ Chi siamo: https://bit.ly/3D8wSz7

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.

Welcome to "ALI Shorts," where we delve into the Agile landscape, navigating its complexities to unearth valuable insights. In this episode, we're setting our sights on user-story mapping, a potent tool for Agile teams.Traditional product development often feels like a dense forest of business documents, lacking a clear route. But fear not, user-story mapping is the Agile team's GPS through this wilderness. It offers a lightweight alternative to chart a digital product's interactions, akin to a GPS guiding through uncharted terrain.User-story mapping, also known as story maps, operates as our GPS in the Agile wilderness. This lean UX-mapping method employs sticky notes and sketches to plot the course users take within a digital product.Much like a GPS segments a journey, a user-story map segments a product's journey into activities, steps, and details. These represent high-level tasks, subtasks, and the nitty-gritty interactions, respectively.In the Agile world, user stories are our navigation waypoints. They describe features or tasks from the user's perspective, aiding efficient navigation. User-story mapping transforms these waypoints into a navigational route, allowing teams to discuss and elaborate on them, eventually adding them to the product backlog.Creating a user-story map is akin to planning a group road trip, a collaborative effort essential to ensure a smooth journey. It's about establishing context and constructing the map using physical or digital tools, assigning distinct colors for visual clarity.User-story mapping vs. customer-journey mapping offers distinct perspectives, focusing on the product and user, respectively. While they complement each other, they serve different navigational purposes, enabling Agile teams to choose the right tool for their specific journey.With user-story maps as our reliable GPS, we can embark on our Agile journey with confidence. They improve collaboration, aid backlog creation, guide minimum-viable-product slicing, and identify risky assumptions. User-story maps are the trusted GPS in the Agile wilderness, encouraging user-centered discussions and efficient prioritization.Thank you for joining us on this journey through the Agile landscape, exploring the power of user-story mapping. Just like a well-calibrated GPS, user-story mapping guides Agile teams through product development, ensuring a smooth and efficient journey. Until next time, keep mapping those stories and navigating towards success in the Agile wilderness. Stay Agile, stay innovative! Find us here: www.agileleanireland.org

Join Murray Robinson and Shane Gibson as they chat with Jeff Patton about product thinking and user story mapping. Jeff emphasises that product thinking focuses on outcomes, not output. He explains that product market fit requires a deep understanding of customers and users problems and a balance of customer desirability, business value and technical feasibility. We discuss how to build a user story map and develop a release plan that reduces your risk and delivers as much value as possible within the time and budget available. Jeff discusses the limitations of requirements and the value of prototyping. He suggests that IT teams should focus on delivering user outcomes rather than delivering requirements. Tune in for insights on how to use user story mapping to deliver great products. Listen to the podcast on your favourite podcast app: | Spotify | Apple Podcasts | Google Podcasts | iHeart Radio | PlayerFM | Amazon Music | Listen Notes | TuneIn | Audible | Podchaser |  Connect with Jeff on LinkedIn or at https://jpattonassociates.com/  Contact Murray via email or Shane on LinkedIn shagility. You can read the podcast transcript at: https://agiledata.io/podcast/no-nonsense-agile-podcast/product-thinking-and-user-story-mapping-with-jeff-patton/#read   The No Nonsense Agile Podcast is sponsored by: Simply Magical Data

Creating and developing a product can be a daunting task for most business owners. A minimum viable product (MVP) allows customers to provide feedback for future development. Thus, developers can avoid lengthy and unnecessary work. However, how can we go beyond turning this idea into a reality and make it a running and successful venture? Join us in this episode as I sit down with Allie Reitz, the Founder and CEO of MEEP, to explore the essential steps in building a minimum viable product (MVP). We delve into the world of automation and discuss the significance of creating a functional and captivating website that fosters efficient connections with people. Tune in to this episode and learn actionable strategies from the expert! --- Listen to the podcast here: Building a Minimum Viable Product and Efficient Website Development with Allie Reitz Welcome to Action's Antidotes, your antidote to the mindset that keeps you settling for less. I'm going to talk to you today about a common situation, maybe you're in it, maybe you've been in it, maybe you know someone in it. You found your idea after all this digging in, that idea that's at that perfect intersection of what the world needs, what you're good at, and the idea that's going to bring your life to where you want to bring it, but the question is how do you actually make that idea become a reality? That's a whole ‘nother daunting task after all this personal reflection that can sometimes actually deter people from really doing anything because it is long, it is drawn out to go from, okay, I have this idea, to, now I'm doing it, now people are buying it, or now people are engaging with that. And that's where my guest today, Allie Reitz, and her organization, Meep, come into play. --- Allie, welcome to the program.    How it's going?   It's going pretty well today. How's it going for you?   So good. I was outside most of the morning so I'm feeling very good now looking at my computer.   Well, that's amazing because one of the things that inspires a lot of people to pursue any of these paths is the ability to live the life they want and you decided this morning, “I wanna be outside because,” to give a little detail about the Colorado weather today, it was a very sunny morning, and the afternoon is probably going to have a high chance of rain in most places so that's a great way to orient your day.    Yes, I'm very glad I did it.   So at Meep, you specialize in having someone go from, you talk about from zero to traction, from zero to where you're actually getting there. How does that process really work? When someone comes in, I assume most people that come in are, as I've described, people that already have that idea, they've already searched and they figured out what they want to physically do but now, of course, how to get it from, “It's this thing in my head, I think, oh, it'd be really cool to do this for these people,” to where you're actually getting these people to engage with you. Totally. Like you said, it's a long process, right? And what's in your head is probably not what you're going to start with because what's in your head is probably the big, fancy, shiny, awesome version that's going to be version 10 or 20 down the line. It's going to be —- one way that I like to describe it or analogy that I like to use is from Jeff Patton in his book called User Story Mapping. He describes it really simply, which I love. It's like if you're wanting to solve the problem for people, that is, getting them from point A to point B, and your idea of the solution is a car, you're not going to start with a wheel because that doesn't necessarily solve that problem for them right out of the gate and your first objective is to kind of validate that assumption that you can solve that problem for them. So his analogy is, you start with a skateboard. It still gets people from point A to point B. It's a lot more janky than a car, much,

Jeff Patton helps companies adopt a way of working that's focused on building great products, not just building stuff faster. Jeff blends a mixture of Agile thinking, Lean and Lean Startup Thinking, and UX Design and Design Thinking to end up with a holistic product-centric way of working. Jeff is author of the bestselling O'Reilly book User Story Mapping which describes a simple holistic approach to using stories in Agile development without losing sight of the big picture. In this episode of the Product Science Podcast, we cover common challenges to product discovery, what tools and techniques Jeff teaches, which ones he's changed over the years, and why. Read the show notes to learn more: URL: www.h2rproductscience.com/post/the-jeff-patton-hypothesis-successful-teams-focus-on-the-who-before-the-what

Frederik Vannieuwenhuyse: Tackling Corporate Politics for Agile Success, The Scrum Master's Perspective 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, Frederik discussed his experience with corporate politics in an agile software development project. Initially a Product Owner, he became a Scrum Master while a colleague took over as the single Product Owner. Facing a team of 20 people, Frederik encountered challenges with the client's perception of the team as a "feature factory" and their desire for a perfect end product delivered all at once.  He emphasized the importance of incremental thinking and work, offering tips such as being proactive, using User Story Mapping, prioritizing work through slicing, and collaborating with stakeholders. Frederik stressed the need for a strong relationship with management and higher-level stakeholders and highlighted the value of retrospectives in fostering understanding and promoting agile principles. Overall, the episode highlighted the challenges of corporate politics and provided practical strategies for successful agile software development projects. [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 Frederik Vannieuwenhuyse Frederik is a Certified Team and Enterprise Coach at the Scrum Alliance. He works and lives in Belgium. He is part of the company iLean. Frederik has worked as Scrum Master, Product Owner, and Agile Coach. He works with teams and leadership to improve collaboration, flow, and learning. Frederik co-organizes the XP Days Benelux conference - this year, in 2023, the conference has existed for 20 years. He is also a regular speaker at local and international conferences. You can link with Frederik Vannieuwenhuyse on LinkedIn.

Teams in skalierten Umfeldern Heute haben wir ein Thema und wechseln mittendrin noch Richtung uneinig. Wir sind uns heute richtig uneinig. Eigentlich haben wir drei Podcasts in einem aufgenommen. Diese Folge auf YouTube: https://youtu.be/QSzXdukiFVs Agile Master Training: https://znip.academy/agile Das Thema Schon über Skalierung unterhalten und daraus ist irgendwie die Frage entstanden, wie geht's denn eigentlich den Teams in skalierten Umfeldern? Und schlecht. Schlecht, warum geht's denen schlecht, es geht den Team immer schlecht. Was? Nein, mein mein Team ist immer wunderbar, also ich weiß nicht, was du mit deinen Teams machst. In Transformation geht's den Teams immer schlecht. Nein, was genau meinst du? Ich habe mir dann ich weiß nicht mehr ganz, wie diese Frage entstanden ist und ich habe mir dabei eben so gedacht mit na ja Es ist schon eine Sache. Ich habe dieses Scrum oder kann man auf Teamlevel, ich habe meine Rituale eingeschwungen und so weiter und das geht alles. Und jetzt sind da plötzlich noch andere Teams, weil ich einen skalierten Umfeld bin, Dadurch kommt ein bisschen mehr Komplexität dazu und mit der darf ich ja auch irgendwie umgehen. Mhm. Okay, also für mich wäre, Abhängigkeiten so der allererste Punkt oder der allererste Unterschied, der mir auffallen würde, wäre ich bin abhängiger oder weniger also ich bin als Team nicht so frei mir meinen Rhythmus zu wählen. Mhm. Ich bin als Team nicht so frei meinen Backlog zu verhandeln. Mhm. Ich bin als Team nicht so mein Produkt zu gestalten. Also es ist eine ganze Menge weniger Selbstorganisation. Da hast du, glaube ich, schon einen interessanten Punkt genannt, der so eine Rahmenbedingung ist für das, was wir heute betrachten. Wahrscheinlich, dass die Teams am gleichen Produkt arbeiten. [2:21] Im skalierten Umfeld genau. Ich war gerade so was sagen wie auch sonst kenne ich sehr wenig Teams, die tatsächlich so selbst organisierte Reife haben, dass sie sich ihr Produkt auch selbst überlegen können. Ja. Aber zumindest ein paar Eigenschaften davon in skalierten Umfeldern ist das glaube ich alles sehr viel vorgegebener. Welche Eigenschaft ist haben soll, einfach weil das auf einem anderen Level mhm, vorstrukturiert und koordiniert wird. Mhm. Also ne, wenn wir über Flight Level reden, die Strategie und die Koordinative, die ist schon gelaufen. Ja. Bin nur noch die umsetzende Gewalt. Das ist direkt auch schon ein guter Punkt, der mir in allen skalierten Frameworks auffällt. Eine Art koordinative Ebene gibt. Also die scheint wichtig zu sein auch zum Einrichten, damit das alles zusammenspielt. Mhm. Auf dieser Ebene sollten wir uns natürlich auf eine Art wie auch immer gearteten, gleichen Takt einigen, dann vielleicht auch unsere Ziele miteinander abstimmen. Und. Könnte zum Beispiel über einen User Story Mapping passieren oder vielleicht sogar, wenn ich Sprints habe, dass ich als Product-Onerin habe ich dann ein bisschen mehr Aufgabe, mich da zu koordinieren, dass ich dann vielleicht schon die nächsten Sprints grob mit ihren Zielen vielleicht sogar vorplane. Product Ownerin Aber jetzt war ja deine Frage für diesen Podca wie fühlen sich die Teams? Ja, die Product Onnerin gehört zum Team. Und wie fühlt die sich jetzt? Die. Überfahren glaube ich von der Abstimmung, die plötzlich herrscht. Ich meine, das ist ein Overhead für die Product, Weiß ich gar nicht, denn als von einem nicht skalierten Team habe ich auch Abstimmungsbedarf. Mhm. Nur nicht mit anderen Teams oder anderen Productornern oder irgendeiner strategischen Initiative, sondern ich muss mich abstimmen mit, Kunden mhm. Marktrecherchen, User-Experience, Tests, was auch immer alles dazugehört. Und ich glaube, ich, mich so abstimmen und zusätzlich noch mit den anderen Teams, die am gleichen Produkt arbeiten. Ja, viele richten dann so eine Art Chief Product Ownerinnen ein, die das mehr in Richtung, und Stakeholder sich macht und gleichzeitig habe ich das für meinen wahrscheinlich Modul, auch noch. Nee. Nicht? Nee,

Associate Director of Product Management, Annalect, USA, Ashish Tripathi Podcast | User Story Mapping | University of Houston Alumni | Ex- Home Depot Employee --- Send in a voice message: https://podcasters.spotify.com/pod/show/architjainakj/message

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. Caterina was working with a team who was really burdened by technical debt. The team talked about technical debt all the time. However, when the Product Owner started to be part of the conversation, the team realized that many of the things they worried about were not really that relevant for the customer. In this episode, we explore how some teams focus on certain aspects so much (like technical debt), that they end up forgetting other, eventually more important, aspects of their work. Featured Book for the Week: User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton In this episode, we explore the book User Story Mapping by Jeff Patton, who has been a guest on the podcast. Caterina shares the key lessons from the book, and describes how she uses this book almost every day because of the powerful, yet simple methods that it shares. In this segment, we also talk about Distinction by Pierre Bourdieu, a book that helped Caterina understand the importance and impact of people's backgrounds can have on how they relate to each other and communicate. How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta!   About Caterina Reinker Caterina is a social anthropologist and passionate Scrum Master. She regards organizations like villages - or cities - with their own language, institutions, and explicit and many implicit rules. Caterina works and lives in Germany and helps groups of people, big and small, in their agile journey. You can link with Caterina Reinker on LinkedIn.

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. The Great Product Owner: Connecting Stakeholders with the development team as a way to amplify and speed up feedback! This PO was not only able to “own” the relationship with the stakeholders, but they were also able to involve the stakeholders with the development team. This PO strived to create a direct and productive connection between team and stakeholders.  The Bad Product Owner: Helping PO's learn to work with and manage stakeholders and their input This PO came to Ziryan and asked him to facilitate a User Story Mapping session with stakeholders. This was when Ziryan noticed that the team PO was not yet ready to take responsibility for one of their most important tasks: working with, and helping stakeholders make decisions. This helped Ziryan realize that the work with PO's is a critical aspect of the Scrum Master's work, and he decided to help this PO learn about User Story Mapping, by helping her with the facilitation, but clearly separating that facilitation from the management of stakeholders. Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. Abou Ziryan Salayi Ziryan is a Scrum Master, Professional Scrum Trainer, and organization coach with a passion for getting the most out of people and teams. His aim is to enable employees to be fully empowered and support self-organization in all areas within agile organizations You can link with Ziryan Salayi on LinkedIn and connect with Ziryan Salayi on Twitter.

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. The Great Product Owner: Present and thorough, two great PO qualities This Product Owner had the customer and end users in mind, and was very thorough in their preparation of the stories. The PO was present at all times and helped the team during refinement. This helped the team understand the scope, and break down enough the stories and epics they had to work on.  The Bad Product Owner: How to help a PO bring the right amount of work to a team When Product Owners force teams to take on more work, that's never a good sign. And this PO was no exception to that rule. Additionally, the PO seemed unaware of how much they had already asked the team to take on, leading the team to burn out, and to have quality problems. Pratik understood that this anti-pattern had to stop, and he explains how he helped the PO and the stakeholders to find a new way of working with the team. In this segment, we also refer to User Story Mapping, a technique all Scrum Masters should bring to their work! Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Pratik Dahule Pratik is an Agile Project Manager and Agile enthusiast working in the USA. He leads teams and creates a culture of lifelong learning, constant collaboration and continuous improvement. Pratik has 12 years of experience and is passionate about helping teams in their agile transformation. Outside of work, he has a blogging site ClassactLifestyle.com where he shares insights on books and exotic places to travel. You can link with Pratik Dahule on LinkedIn.

We all know what a product is. We buy and use them all the time. But, what does it mean where you work? Why is there so much resistance to creating great products where you work? Jeff's talk focuses on how to recognize the mindset that gets in the way of effective product design and development. He shares how to know when you, your leadership and the processes you use have slipped into anti-product mode, and gives you tips to fight it.This episode is a re-broadcast of a talk from Jeff Patton, author of the bestselling book User Story Mapping. Jeff uses drawings throughout the talk, so if you'd like to see the sketches he mentions, you can find the video replay of the event here.You can find more information about this podcast at sep.com/podcast and subscribe wherever you get your podcasts. Thanks for listening!

How to apply continuous discovery techniques to a nascent, early stage product that doesn't yet have product-market fit.-----You can also read this episode here.Sign up here to get upcoming audio essays emailed to youFollow the MTTM journey on Twitter or LinkedIn!If you haven't already would you do me a favor and take ~40 seconds to rate/review the show on Apple Podcasts ? It really helps. (Scroll to bottom of page for rate/review links.)Links & resources mentionedSend episode feedback on Twitter @askotzko , or via emailRelated episodes#44 Teresa Torres: Habits for clear thinking and better product bets#31 Marty Cagan: Empowering product teams to do the best work of their livesPeople & orgsTeresa TorresAsh MauryaJeff PattonMarty CaganBooksContinuous Discovery Habits, by Teresa TorresINSPIRED, by Marty CaganOther resources mentionedAndrew's original Twitter threadOpportunity Solution Trees - Teresa TorresJeff Patton - Story MappingLean(er) Canvas - Ash MauryaJobs to Be Done (JTBD)Images mentioned   

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. The Great Product Owner: Developing great networks with stakeholders Great Product Owners know their product backlog back and forth, and develop great networks within the organization that help solve the critical problems, and answer questions for themselves and the teams they work with. This particular PO also made a point of being available for the team when the teams needed them, and met regularly with stakeholders 1-on-1.  In this segment, we talk about User Story Mapping, and Impact Mapping.  The Bad Product Owner: The many anti-patterns that develop when people are forced to take on the PO role This Product Owner did not want to take on that role, they were forced to take it, and acted mostly like a Backlog secretary. By stepping back due to other responsibilities, this PO left the team to their own devices, and was mostly absent when the team needed them.  And this was just the start, listen in to learn about the many anti-patterns that develop when people are forced to take on the PO role.  Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Samet Ulutas Samet has been working as an Agile Coach for more than 3 years and coached 35+ different teams until now. Samet has plenty of experience dealing with difficulties of an Agile Transformation, including being to witness the Agile Transformation of the largest private bank in Turkey from the beginning. Samet is also the co-owner of "Be Agile Stay Agile" YouTube channel.  You can link with Samet Ulutas on LinkedIn and connect with Samet Ulutas on Twitter.

Jeff Patton is a best-selling author, speaker, and consultant for tech companies. Jeff's best-selling book "User Story Mapping" applies the same practice screenplay writers use to think through a great movie script, to the work that tech people do and think through users' experiences with their products. Jeff is a unique visual thinker and communicator. As an art school dropout who went into tech, Jeff applies his drawing skills to speaking and teaching handwriting figures and roles as he speaks. Jeff's mission is to make tech products suck less for people that use them and to make creating them more joyful and rewarding for the people that do. https://www.linkedin.com/in/productdesigncoach/  It's Men's Month on Survive to Thrive! Don't forget to like, subscribe, and share! Movember Mo: https://www.movember.com    

This week, Dan Neumann is joined by two AgileThought colleagues, Alba Uribe and Michael Guiler, to explore the concept of User Story Mapping.   In this episode, Dan, Alba, and Michael are diving deep into different approaches to starting backlog; they describe the benefits of story mapping and explain why it is a great tool to achieve a shared understanding throughout the whole team. Listen to this episode to achieve a comprehensive understanding of Story Mapping with various examples that will help you put this concept into practice.   Key Takeaways ● Why is Story Mapping a great way to create a product backlog? ○ All the team can see the overall vision and what is in the mind of the product owner. ○ It is a way to identify the release strategy. ○ Story Mapping can be a helpful tool when change needs to be embraced. ● Mechanics about how to create a User Story Map. ○ Who? Story Mapping starts with the user. ○ What are the goals to achieve? A journey map for the team including all pain points. ○ How? Identify how to address those pain points. ○ Organizing left to right and top to bottom. ● Examples of Story Mapping and Minimum Viable Product (MVP). ○ Alba shares how she uses Story Mapping in her work as an artist. ● Story Mapping can go wrong. ○ Not knowing how to identify your MVP. ○ Having difficulty identifying opportunities for learning. ○ The what and the why need to be addressed for Story Mapping, not just the how. ○ Having someone with experience in Story Mapping is hugely important for the process to develop the best way possible. ○ There need to be conversations about how Story Mapping will be done.   Mentioned in this Episode: User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton and Peter Economy Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, by Lyssa Adkins Medical Medium: Cleanse to Heal, by Anthony Williams Lean Enterprise: How High Performance Organizations Innovate at Scale, by Jez Humble, Joanne Molesky, and Barry O'Reilly   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!

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. Gonçalo was working with two teams that were busy migrating to a new system. However, in one of these teams there was a disruptive team member. The management tried to put this team member aside by pushing him into test management. But this only made the situation worse. Listen in to learn what Gonçalo tried to help this team member, and what he learned from this story that he carries with him ever since. Featured Book of the Week: Difficult Conversations: How to Discuss What Matters Most by Stone et al. While reading Difficult Conversations: How to Discuss What Matters Most by Stone et al., Gonçalo realized that it's possible and there's a method to having conversations on very difficult topics, yet be constructive. This book shares some critical tools that all Scrum Masters should be aware of.  In this segment, we also refer to the book User Story Mapping by Jeff Patton, and to the Oikosofy's User Story Mapping facilitator's guide, available for free.  How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta! About Gonçalo Valverde Gonçalo is an Agile Coach from Portugal working with teams and organizations in their continuous improvement journey. As a keen amateur photographer, he learned that less is more and how constraints help one focus on the outcomes. He's also a co-organizer of Agile Coach Camp Portugal.  You can link with Gonçalo Valverde on LinkedIn and connect with Gonçalo Valverde on Twitter.

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. The attitude that the PO exhibits will fundamentally affect their effectiveness in the role, and in this episode, we explore 2 contrasting attitudes in the PO role. The Great Product Owner: The great Collaborator A great Product Owner is able to collaborate with the teams and the stakeholders, through their listening skills and ability to communicate ideas and why they matter for the product and the customer. Another great asset for a Product Owner is to be able to understand and evaluate technical debt together with the team. Finally, we talk about how great teams have the PO inside, and as a key part of the team. The Bad Product Owner: The bossy PO In this segment, we talk about how PO's sometimes take a “bossy” perspective and are not able to understand their role. They might think they are “the boss”, and can just give orders to the team. In this segment, we also discuss the concept of the “product team”, as opposed to having the product focus only in the PO role. We refer to the book User Story Mapping by Jeff Patton. Are you having trouble helping the team work well with their Product Owner? We've put together a course to help you work on the collaboration team-product owner. You can find it at bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO's collaborate. About Med Marouane Ajraoui Med Marouane Ajraoui enjoys practising AIKIDO while helping individuals, teams, and organisations embrace the agile mindset. He is from Morocco but has lived in several countries, and he enjoys being a "citizen of the world”. He is the founder of Agile Africa, an NGO for disseminating Agile culture in Africa. He is also the CEO and founder of JediSquad, an international firm that supports developing Eco Agile businesses and meaningful digital products. You can link with Med Marouane Ajraoui on LinkedIn.

There's nothing more useless to a Product team than a big backlog.  Bringing backlogs to life - making them usable, relevant, and getting value from them - is something that transforms ordinary teams into extraordinary ones.  To guide us on how to do that, we asked Jeff Patton - creator of User Story Mapping - to join us on the podcast.Featured Links: Follow Jeff on LinkedIn and Twitter | Jeff's upcoming Training Sessions | Buy Jeff's book 'User Story Mapping' | Alistair Cockburn's book 'Writing Effective Use Cases'Give UserLeap a try for free by visiting UserLeap.com to build better products.

Freunde der Qualität, wir begrüßen Euch zu unserer 23. Podcast-Ausgabe! Diesmal unterhalten sich Eva, Manuel und Christian über die Frage, wie „klassisches“ User Story Mapping nach Jeff Patton funktioniert und wie man diesen hilfreichen Ansatz auf das agile Lernen und Lehren übertragen kann. Viel Spaß dabei! Zur Hörerbefragung: https://qualityminds.de/magazin/podcast/article/qualityheroes-podcast-hoererbefragung-10-minuten/ Sprecher: Eva-Dirr Bubik: https://www.linkedin.com/in/eva-dirr-bubik-5ab587144/ Manuel Illi: https://www.linkedin.com/in/manuel-illi-609b3615b/ Christian Brandes: https://www.linkedin.com/in/dr-christian-brandes-423440144/ Ressourcen: DAS Buch zum Thema: Jeff Patton, „User Story Mapping“, O'Reilly Verlag Story Maps und mehr: https://t2informatik.de/blog/prozesse-methoden/boost-your-backlog-teil-1/ Beispiel für eine Lehr-Story-Map: https://qualityminds.de/app/uploads/2021/06/Lehrstory-Map-Illustration.jpg Blog-Beitrag zum Lehrstory-Mapping: https://qualityminds.de/magazin/blog/article/qualitylearning-als-wegbegleiter-auf-dem-weg-zum-agilen-lehr-lernsetting/ Informationen zum StoryMapping-Workshop: https://qualityminds.de/qualitylearning-workshops/ Podcast-Folge zu agilem RE: https://qualityminds.de/magazin/podcast/article/qualityheroes-podcast-folge-9-agiles-requirements-engineering-wie-geht-das/ Podcast-Folge zu agilem Lernen & Lehrstories: https://qualityminds.de/magazin/podcast/article/qualityheroes-podcast-folge-19-zwischenfrage-akzeptanzkriterien-als-konkrete-beispiele-wie-geht-das-genau/ Über QualityMinds: www.qualityminds.de https://twitter.com/QualityMindsDE Feedback, Fragen und Themenwünsche an: eva.dirr-bubik@qualityminds.de manuel.illi@qualityminds.de christian.brandes@qualityminds.de Allgemeines & Themenwünsche zum Podcast: podcast@qualityminds.de

Episode Summary: In this episode, Raymond and I explore: If it's possible for organisations to be 100% agile, Why a human-centred approach to product design is key How one can get started with their agile journey... and much more.   Guest Bio: Raymond Chike has over 15 years diversified experience in the Financial, Retail, Utilities, Energy, Consulting and Charity sectors. Proven record as a problem solver and aggressive commitment to continuous learning. Bringing together Human, Digital and Physical Interactions while enjoy working with businesses create innovative solutions, products and services. By recognising customer needs, validating new product and service concepts, assisting teams in developing mvp, and assisting organisations in transitioning to adopting new ways of working in a holistic human-centric way.   Raymond's Social Media: LinkedIn: https://www.linkedin.com/in/chykeray/   Design Thinking Squad Meetup https://www.meetup.com/Design-Thinking-Squad-Gloucestershire/   URLs and Resources Mentioned Books/ Articles: User Story Mapping by Jeff Patton The Startup Way by Eric Reis Lean Startup by Eric Reis Lean UX: Designing Great Products with Agile Teams by Jeff Gothelf and Josh Seiden Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seiden Impact Mapping by Gojko Adzic Raymond's LinkedIn post on relationship between Design Thinking, Lean and Agile: https://www.linkedin.com/feed/update/activity:6505691705440894976/   Interview Transcript  Ula: 00:26 Hey everyone! How are you doing today? Can you believe it? We're nearly at the end of Season 1 of the Agile Innovation Leaders podcast and this is our 9th episode. A massive thank you and shout out to all of you who have taken the time to listen, support, to write, to encourage… I am very, very grateful. It never ceases to amaze me that you guys are listening from all over the world; from places and countries like New Zealand, Australia, Singapore, India, Nigeria, Kenya, Ghana, France, South Africa, Canada, USA, Brazil, Switzerland, Norway… of course United Kingdom where we live and many other places where I've not mentioned. I do appreciate the engagement – thank you so much. Keep it coming and keep getting in touch. Now, in the course of launching the podcast, I've also had a number of you get in touch with me to say, ‘Hey, we really are interested in this ‘Agile' thing. How can we learn more about it? How do we get started?' And for some of you, you've had some sort of Agile initiatives going on in your organization and you don't know how you can make this better, make it work because it's not working as well as it should. Well, if you fall into any of these categories, today's episode is for you. I'm pleased to introduce my guest. He is nobody else other than Raymond Chike. A seasoned Agile Innovation professional with over 15 years of diversified experience in multiple sectors – Financial, Retail, Utilities, Energy, Consulting and Charity. And he is a big proponent of design thinking and basically blending agile, lean start up thinking, UX design and design thinking to provide a rounded and human-centered way of working. You just have to listen to this episode! So without further ado, my conversation with Raymond. Enjoy! Ula: 03:04 Raymond, thanks for making the time for this conversation. It's great to have you on the show. Raymond: 03:09 You're welcome. I'm excited as well Ula: 03:11 Great. Now let's kick off. We want to know who Raymond is as an individual. Can you tell us a bit about yourself, and how your life experience has led you to choosing a career as an agile professional? Raymond: 03:25 My story is one of those I'm passionate about telling people. So, I'm a native of Nigeria, back in Africa. And I think the whole journey started off as me looking at the whole world in perspective. And I thought to myself, I want to see how things get done in the Western world – United Kingdom and America and all that. That led me to journey into the UK. So, on coming here, I found my first contract was more of an IT security administrators service contract or something like that. And along the line, I started noticing that I was good at connecting the business and the technology. Little did I know that that was what business analysis was. Then, business analysis became popular, but already I'd found out I was naturally a Business Analyst. But then I thought, ‘Okay, let's go on that journey.' And while in the journey of a Business Analyst, I started realizing that things took too long to happen. So, people are building (a) project and before the project finishes, in two years, the world has moved on. And I said, what is the best way of doing things quicker. I mean, that was where agile started coming up in my mentality. Then I thought, ‘Alright, I think I've got an agile mindset as well.' So, I think I'll take a perspective from a natural point. So, professionally, that's how I found my way/ journey into the Agile world. I live in the UK, permanently now for 14 years, 15 years or so. I've got (a) family, as well. So, my primary location is around Southwest of Cheltenham, but most of my consultancy has been around London, and I travel around anyway. I think. Yeah, that's me in a nutshell, and that's my passion. And, then yeah. Ula: 05:11 That's quite an interesting story. It's funny, because we all start off one way, but the thing about us as humans is that there are things about yourself, you know, your natural inclinations or giftings, or things you're really good at, you wouldn't know until you actually get started. So, it's interesting you recognised the knack (i.e. abilities) and probably people around you also recognise the knack whilst working as an IT Security Specialist, that you also had the ability to connect business with technology. Just out of curiosity, what was your educational background? Raymond: 05:46 Yeah, I graduated with a first degree in Electrical/ Electronics Engineering. Ula: 05:50 Oh, okay. Raymond: 05:51 And… yeah, that is me really. I haven't furthered anyway in terms of educational academia. I've surrounded myself with lots of training and certifications… I've gone, I mean… I don't know if I have enough time to start to name them. But, that's my educational background anyway. Ula: 06:11 I mean, education is not necessarily having more degrees or as many degrees as a thermometer. I'm also Nigerian and I also got my first degree - funnily also in Electronic Engineering. Raymond: 06: 21 Really? Ula: 06:22 Yeah, yeah. Raymond: 06:23 What a coincidence! Ula: 06:26 From your profile, I can see that you are quite big on marrying agile thinking with lean, UX design and design thinking. I'm a big fan of that, because it's really about focusing on what value you're bringing to the customer, whether it's internal or external, and ruthlessly eliminating anything that the customer does not value and is not willing to pay for. So, what are your thoughts on marrying design thinking with lean methodologies? Raymond: 06:56 My thoughts are certain in the sense that it must be married. Looking at the world we live in now, (we're) in an adaptive world. I think the most important service to me is customer service. At the heart of every product, at the heart of everything we do, if we can't link it to customer service, then we just building what we think we like, yeah? And before you can build something for a customer, I always look at it in this perspective, you have to design that thing, you have to then build it, and you have to engage with the people to use the product. And that's the heart of Human Centered Design, or rather you can call it Customer Centric way of doing something. So, that is me thinking about how you bring together the human perspective, and link it with the digital and the physical interaction. Now, this is where you need to combine a whole lot of techniques and thinking and I always say it this way, ‘Agile is not a way of working, agile is a way of thinking than the way working.' Because your behavior modification cannot change if your mind is not transformed. So, at the center and the heart of agile, is the thinking. The same applies to design; at the center and heart of design is thinking - Design Thinking, Agile Thinking. So, call it this way: Design Thinking, Lean Thinking, and Agile Thinking. And to marry them is - Design Thinking makes you get to the heart of the customer. Like, ‘What is the problem you're about to solve? What is the pain point? Empathy. What is this? Why are we doing this thing? What is the problem? The pain point; you empathise with the customer. Now, at that point of empathy - this is where you begin to think about Lean. Where Lean thinks, ‘All right, I think I've empathised (with) this problem and I understand this thing – I feel I understand it.' Then, what's the barest minimum I can test to see it's working? This is where Lean Thinking comes in, right? So, then when you use the Lean Thinking and it works or you get good feedback (you say), ‘Okay, okay. I think we now see a way this is gonna work.'  ‘Okay, let's produce it in some sort of scale now and still get feedback and learn.' This is where you now bring in the principles on Agile, like the Scrum, and the Kanban, or the Extreme Programming, or SAFe (Scaled Agile Framework). Then you now want to say, ‘Okay, this thing is getting bigger now; we're about to blow up now', so you want to scale. You scale the product, you engage with the people, then you might… So this is the journey of a product from its inception of human-centric pain point up to the development, and this is how I marry Design Thinking, Lean Thinking and Agile Thinking. Ula: 09:41 Wow, (I've) never really heard it put this way. But it does make sense and I do agree. So, would you say that Design Thinking is the same thing as User Experience design? Raymond: 09:51 It's an interesting conversation but it's not the same. But what I usually say - Design Thinking is a big umbrella. Like, you'd say, Agile thinking. So if you… Like, what you've asked me now is like, ‘Is Agile thinking the same as Scrum Master?' It's like, ‘Oh no, Scrum Master sits under Agile.' That's the same question. Design Thinking involves a lot of skills. Ula: 10:16 Yes Raymond: 10:17 Now, it depends on the way you want to go with it. If you want to do a short design… bear in mind it's a (way of) thinking. Ula: 10:23 Yeah Raymond: 10:23 If you now want to bring it to reality, in terms of skill you might want to map it to, say, a researcher can be involved. A researcher... Now does that mean you cannot be a researcher? You can be (one) but in a professional office, maybe there's a (dedicated) researcher. Okay, UX design - alright, what makes you think you're not a UX designer? Okay, I want to develop an app. I can just sketch something on paper with a wireframe and I've got some understanding of UX concepts. Now, that's my minimum viable (product). Maybe I need a professional UX designer to a prototype for me. Okay, then you need a UX (designer) it might be - depends on the product. If my product is around…  (say,) building a bottle, I don't need a UX designer for a bottle. I might just go get a fabricator to make a bottle, you see what I mean? So regardless of the product, the principles stand. But when you talk about the product you want to do maybe a web design, then the skill set comes into play. That is why the UX design now is a skill. Yeah, that's a connection. So, it's like Agile - is Agile the same as… product owner? No, within agile umbrella, we might need a product owner, we will need a scrum master. Okay, maybe we don't need an engineer really. Okay, okay. While you're developing an agile product, what if the product is a pharmaceutical product? Do you need a developer? No, you need the scientist. So, you see the point. So, the takeaway, because when we talk about Lean agile, people just focus straight ‘Oh! (We're building a) website, app?' Ula: 11:49 Software development… Raymond: 11:50 But… it's not about websites. It's not about apps, not about it. What if it is a pharmaceutical company developing a prosthetic leg or pharmaceutical company developing a fake eyeball, what do you say then, you know? So, I try to get people away from products first, think about the human-centric way of connecting digital and physical interaction, then I think everything will fit into place. Ula: 12:15 It's interesting how you've highlighted the fact that there are general principles underpinning Agile thinking or Design thinking and the principles are separate from the products. Now the products could vary, the principles remain pretty much the same. But now depends on the context - which you can now adapt it (the principles) to the context of the product or service probably that you're providing to the end user or the customer. Am I right? Raymond: 12:44 That's right, well-articulated. Ula: 12:47 Okay, well, thanks. That's interesting. You said that there is this misconception that agile is about the things people do. Now, based on what you're saying that agile is first a mindset so and the International Consortium for Agile, or the ICAgile organization, they said on their website, it's about first being agile, before you do agile. Raymond: 13:11 That's right. Ula: 13:12 So, what would you say are the steps then, towards being agile and when would you know that you are truly agile from a ‘being' standpoint? Raymond: 13:24 Okay, I think the best way to say (it is) this way: there is nobody that's 100% agile. Ula: 13:30 Hmm! Interesting. Yeah. Raymond: 15:31 Definitely, nobody, nobody. Because why I say that is, if you are 100% agile, it's like… if you say yes, I am 100% agile, it does not marry up with the name agile itself, because agile itself means changing. So, you say you're 100% changing. So, I am 100% changing, so you're still changing. So, what agile, what I try to say about agile is (it's) about how we're learning that's Agile. So, (it) automatically tells you, you are constantly learning. So, have you learnt? No, you are constantly learning. So, the thing at the core of Agile is a mindset, your mind has to be ready. That's the height of it is your mindset knows that things must change. The principles and the values lie within and the practices follow and the tools and processes that help it. So, but you need to get at the heart of it that it… So basically, the world, is ruled by companies who learn faster. That's it. So, how are you learning faster? That's why agile comes in. So, are you… if Facebook comes tomorrow and said, ‘We are now agile; we are the best agile (practitioners)', that's wrong, because they're still going to have challenges that come up tomorrow that they'd have to think and say, ‘Guys, what's the next solution here?' Ula: 14:46 True Raymond: 14:46 This is where I feel agile is just, agile in itself is even a part of a product. As I've just explained Lean, design thinking, lean and agile… all that stuff. So, it's a complete mindset shift. But we there yet? We're not always going to be there in terms of 100%. But we are on a journey. Ula: 15:06 Yeah Raymond: 15:06 So, we're on a journey… we're not definitely going to be ‘there'. So, to answer your question, I don't think anybody's 100% agile. But I guess the thing is, to what degree of Agile are you? To what degree of learning or what degree of flexibility? What degree do you apply the principles better? I think that's the key message. And I mean, the only way to answer that is more of your outcomes, really? So, when you check into your outcomes, you know if you are really, truly agile and how responsive you are to the market and how adaptive you are. Ula: 15:41 Well put. So you said, yes, no one is 100% agile. You're constantly learning and that's probably why agile and lean - they're complimentary because lean is also about continuous improvements and focusing on improving processes to achieve certain goals. What would you say about the frameworks then? Is it possible to purely apply one framework in an organization's operating context, to the exclusion of others? Raymond: 16:13 Great question. I think you will do yourself a favor to mix them up. I always tell people this … if you study Scrum, the next thing… they (people in organisations) call me and say, ‘I'm doing Scrum', (and the person) goes on saying ‘I'm writing user stories.' And I say, ‘Okay, but I'm sorry, user story is Extreme Programming. So, you're already mixing it up, right? Then you get people who are doing Scrum. Then they go, ‘Oh, our Jira board is a Scrumban board.' So, what's that about? Ula: 16:41 It's a Kanban board… yeah… Raymond: 16:42 So, what I tell people is this: I'm not dogmatic about any (framework). If you bring any framework tomorrow and call it… ‘Jump' … whatever you want to call it. My question to you (would be), ‘Is it solving human problems? Are we inspecting and adapting faster? Is it prioritizing collaboration over ‘blah'…? Is it prioritizing responding to change over following a plan? Is it tied to the principle?' (If the answer is) ‘Yes', that's it! I don't want to know what else you call the name. I mean, I was in a conference the other day and I said to someone, ‘Look, let's be honest.' (If) she goes to Facebook now, (and) I go to Netflix (and) ask them what (agile framework/ methodology) they're following, they probably would not tell you anything. Probably tell you, ‘I don't know what's Scrum - we just inspect and adapt quickly. We just learn fast. We have a system that helps us learn fast.' That's it. No one is gonna tell you, ‘Do three weeks sprint, do four weeks sprint… do one thing or the other…' It depends on the product. Depends on the product. Some people do one-week sprint. Some companies do one-week sprint, two weeks sprint, three weeks sprint. Some pharmaceutical companies do one-week experimentation. I've seen companies do design sprint zero, then go on and do one-week sprint. The thing is, where are you learning fast? How are you learning fast? And agile is just (a means to) the end game; it's the building of the product. Remember, I said design thinking? Where is the place (for empathy in Agile)? …No agile principle talks about empathy. Nothing like that. Ula: 18:05 No Raymond: 18:06 They (some agile frameworks) just tell you, ‘Sprint planning - boom, boom, boom, go!' But, how do I know the product to build? I mean, this was what inspired me to (write) my last post where I said… I did post something on LinkedIn the other day. (That's one of) the key things that I was trying to say to the team. I read that from a book called The Startup Way by Eric Ries. This is the same guy who … Eric Ries is The Lean Startup guy. So, here is Toyota (for example). Toyota known for all the things they do around production and lean and all that stuff. But yet someone in Toyota could say he thinks there's a missing part. And that is because they are good at creating things. But they don't have a system that tells them on (how to) discover what to produce. Scrum does not help you discover what to produce, you know… Kanban does not help you discover what to produce. They just help you produce but they don't help you discover. So, this is why I say, I'm not precious about any framework, as long as that framework can help me easily inspect and adapt. That is my key (requirement)… and it's transparent. That's my own, I don't really cherish… I'm not gonna say I'm a SAFe man (or it) must be SAFe. (Nor would I say) it must be Scrum, or it must be Kanban. But then, does it mean I haven't gone on training for all of them? I have – I'm not hung up on frameworks. (I've gone on training for every one of them) because I want to know what I'm talking about. I want to learn because I'm also an aggressive learner. So, I want to know what you're talking about. But then I always ask myself the question, what is the “why” you're doing this? Why are you doing it? If it connects with (the agile) principles – yes. If it doesn't… hmmm… I'll pick and choose what I want from it and throw the rest away. As simple as that. That's my view on all frameworks, really. Ula: 19:48 Makes perfect sense, actually. Raymond: 19:51 You don't want to be hung up around frameworks really. Going into this conversation the other day, someone talked about (the) product owner (role) and I said, ‘Listen, I've done a Product Owner course for Scrum. And that is not up to 2% of what it takes to be a Product Manager.' It's not! If you think you've done a Scrum course, on product ownership, and you think you are now a product owner? I'm sorry, it's not (the case). Because the Product Management (responsibility) is a big piece - from design, to engagement, to development. So, there you have several of those sideline courses, you have to go to; to understand the market, to understand the proposition, to understand business model presentation, Lean Canvas…, then, you know what I mean? Where goes all the certifications and frameworks again? It's all about just learning. Just see it all as learning; adding that to your toolbox. You know, focus on the human-centric problem you want to solve. Ula: 20:44 I quite resonate with what you said. As in likening these frameworks, the concepts - to look at them as tools in a toolbox. You pick the one that most appropriately suits the work and the organization you are in - in my opinion. I'd like to know what you think about this. But I also think it is possible that a team, an organization you know, or even within a project, it could evolve in such a way that the tools that you're using… or the practices and the tools and processes that you're using to try to accomplish an outcome might need to change midway. So, it doesn't necessarily mean that what you start with is what you end with at the end of the project. What do you think about that? Raymond: 21:30 Yes, I mean, it is. I've worked with several big companies trying to do agile or are doing agile. I've seen it. I've got the scars on my back. I know what I'm am saying. It's very painful when you see people who want to fix it (an ill-fitting framework) into their hole. I say to them, ‘You have to be pragmatic.' Like this consultant… I don't remember his name again. But he said, ‘Agile has a way of making people drop their smart brains at home and come to work.'  If you come to work, (that) you do agile doesn't mean you're not smart - you're smart. Just know that you're smart. Look around the process, see how it's going to work well for you. If it's not working, find another way it's going to work. Remember, the principles still apply. Keep the principles at your forefront. We're talking real stuff here, yeah? So how do we make Kanban work for us? How do we make Scrum work for us? Okay, yes. Okay. How do we draw funds, investment? Because we need seed funding to do this experiment and prove to our manager it works. Okay, you want to start up something now? You're starting small? You're (i.e. Ula is, for example) not going out now opening an office and buying a podcast device of 10 grand or 20 grands? You're being lean here; trying to make sure you're experimenting here, right? Ula: 22:39 Exactly, you have to know if someone wants… Raymond: 22:41 You (Ula) are applying the same principles. You've got the mindset; you've got the mindset. That why you're doing what you're doing right now. And it's the same principle applied at a scale. Ula: 22:49 Thanks! You mentioned something that you've had scars on your back as a contractor working with teams and organizations. Is there any one you wish to share? Raymond: 22:58 I think for me, the behavior is the same. What I can say is, every company wants to be agile; that's the market drive - just get that right. Every company wants to be agile. In fact, you can almost sell anything to any company now in the name of Agile. Ula: 23:12 It's a buzzword, right? Raymond: 23:14 Yes. But then I always say this, ‘If I get in there, how can I add value to you?' So, you get in there, you stumble on arguments. Now one coach prefers SAFe (Scaled Agile Framework), another Coach tell you Scrum, another coach tells you Kanban is the way. Then I always challenge them by saying… When I come in with design thinking mentality, they look at me like, ‘where does this guy come from? Who are you? We are agile.' I say, ‘yes, but how do you draw funds from the manager to tell him you're agile?' They'll say ‘Hmm! That is a Product Manager's responsibility.' I say, ‘Oh really? I thought that's still under Agile, because a  Scrum Product Owner course teaches them (i.e. the Product Managers) how to draw money? Is it a “no”? Okay'. You see, when you find that a… That's what you see in companies. I think what we need to start to understand is…  I tell people, ‘Guide yourself with mentors', experience is key as well, you know. My experience, tells me that many companies are still on the journey, and I said agile is a journey. My gauge tells me every company now knows: there's no argument we have to be agile. So, we've crossed that stage. They know that we have to be adaptive. They know that now. The challenge many companies are facing now is, ‘How?' They now know, but it's the ‘how' now. (My) advice is, based on my experience, there is no pattern. All I can say is, as long as you have these three pillars in the mindset of what you do; the design thinking, lean thinking, agile thinking… I always wrap it up by saying (you must have) almost an entrepreneurial mindset as well. Ula: 24:46 Oh yeah. Raymond: 24:47 That will help. A bit of that will very, very help (i.e. help very much). The reason why I say entrepreneurial mindset is because then you're thinking differently. You are not there sitting down in a company waiting for your salary every month and just go home. You're inspired to say, ‘What problem are we solving? What customer problem are we solving out there? How can we be fruitful?' Now you're thinking entrepreneurial. I think that drive will start to send a different message to company structures; you start inspire people to work, in fact inspire people for new products. And because people love working agile, when you put agile in any office, (for example) Kanban, people love it. Why? Because it is liberating. Ula: 25:27 It is. The transparency... Raymond: 25:28 It has that way of making… The transparency! People love it. That's the key to (the) successful companies we see these days everywhere. We don't know how they succeed. But this is the principle they've been applying years ago when it was not branded anything. Now is becoming branded, whatever we call it now. Ula: 25:44 Yeah, I mean, it's interesting… Yeah… it helps to put a name to something but it's more about not enshrining it and kind of stifling the spirit of what that thing is meant to mean (therefore) losing the value. Raymond: 26:00 Yeah, I agree with you 100%. Ula: 26:02 Now, you mentioned the book, The Startup Way and I assume that you might have read some other books. If you were to gift or recommend, say two or three more books that have greatly shaped your thinking; your agile, lean, design thinking - which ones would you recommend? Raymond: 26:21 Wow, there are key ones, I think, if you want to be different. If you want to be ‘agile- different', like I mean, set yourself apart. You need to have a hold of this set of books, you know. I would say go for The Startup Way (by Eric Ries), Lean Startup (book by Eric Ries), Lean UX, Impact Mapping by Gojko, User Story Mapping by Jeff Patton. These would get you started. Ula: 26:47 Okay Raymond: 26:48 These are books I've seen that stood the test of time when it comes to this whole ‘game' of Agile. You, kind of… They will set you apart in your Agile thinking. Someone is going to be like, ‘You just became holy again in agile.' I'm telling you. With every page you read in this book, you'll probably read them again and again and you'll be wondering, ‘Where have I been in this world?' Ula: 27:11 Kind of reminds me, there are some books that I have read yet across different disciplines - although I tend to read more of business and self-improvement books. And there are some that are out there, which I'dd read quickly and I'll make a mental note to read them again at a slower pace. However, I also have a lot queued up. Raymond: 27:31 I have so many books but I buy physical books. Ula: 27:33 Yeah Raymond: 27:34 The kind of books I buy are around technology, innovation, entrepreneur… Ula: 27:38 So, there might be other professionals out there or people who want to make a headway into the lean, agile world as consultants or contractors. Now you said you came from Nigeria to the UK, so how did you get your first agile related role? Raymond: 28:00 Yeah, I think it's more of the experience first - in the four walls of the company, that's it I mean, there are two levels I call it like I do some private coaching and training for people who want to get into like a fundamental business analyst role. Then maybe progress to an agile role. But I would say, most of these things... As I said, the first thing is the mind. I always say this, it's difficult to teach you agile, (if) you don't understand Agile, it's difficult. So, I think what I tend to do is… there is a level of experience I hope you'd have experienced in the four walls of a company, deep problems. Then you can do some training or in most cases, enlightening yourself with some of these books. Read them, be sure you understand what they're saying. I always say understand why people use Agile. Don't understand Agile. Just understand why and relate it to your real world. Bring it home. Always bring it home because… How we bring it home? I tell people, look at the things you use from day to day. When you started using WhatsApp, it's not what it is now. WhatsApp started with just a message. There was no video, there was no record, there was no that whole thing. So, there were messages then later. This is agile. They were changing things, giving people what they want, changing it again, adding this, moving the colors. Now, connect Agile to your daily world. Then when you get to the company, it just starts to make sense. Because the companies you might get into, they are also as confused as you think you are. So, I guess the most important thing is passion. Get that passion in your mind. If you are agile, it would come out of your mind(set) and the way you talk, people will now know it's agile. But if you don't have it in your mind, as a project you (need to) change your mind(set). I always teach people this. Look at your life as well. You want to look for a house or a project you want to work on or you want to buy a new car. You thought you wanted to buy a Volvo. Suddenly, as you started going (car shopping), you find out that you don't like a Volvo. You decided to change it (the desired car) into Mercedes, why? Your requirements are changing even as a human - you haven't even gone a month and you've changed three decisions already. So, that is the adaptive behavior the world is (aiming) at. The system can manage it. What technique will manage this changing requirement every day, yet give the business (its desired) business outcomes, give customer, customer satisfaction. This is… my coaching to people is always (to) connect it with your day-to-day life first - make sense (of it). Then every other thing people are talking about can be reality now. Then, you can do the training, you can do the coaching, you can do the workshops, and they all begin to join dots together. I do workshops as well but then that's more… my training and workshops are more experiential. I bring case studies into the room and by time you go out, you understand what it means. Yeah, that's the way I look at it, really. Ula: 31:04 So, are these workshops public? Raymond: 31:06 At the moment, the organisations I consult with – I run them with them. But then I do them public, but that is once in a while. My plan this year is to have some public sessions, but I haven't put them in the calendar yet. I'm still trying to work out what customers want. I'm still going through a design thinking phase around it because I feel I don't want to just produce what I like; I want to see what people really want. And see where I can do something barest minimum that can help satisfy the need. So, say I'm at that stage where I'm a bit lean about it as well. But then I'm also willing to do anything on demand. If there's a certain group of people that come together and say, ‘I want to learn this thing. We're 10 of us, we are 20.' I do things like that sometimes. I did one in Cardiff last year (2018). A group of people came together - 12 of them - said they wanted to understand Business Analysis, how it links to agile and all that stuff. So, I did a bespoke material for them and I went and delivered it for a full one day. So, things like that I can do as well. But as I said, there is no one public (course) at the moment . Ula: 32:14 Okay, fantastic. Once you have finalized your calendar for some public training or workshop events, where would be the best place for (finding) this info? Raymond: 32:25 I think professionally, the best way to get me is LinkedIn. Ula: 32:27 Okay Raymond: 32:29 So, Raymond Chike, LinkedIn, that's the best way to get me professionally. Ula: 32:34 I'll put your LinkedIn profile URL in the shownotes. Raymond: 32:38 Yes. I have a meetup group in Gloucestershire called the Design Thinking Squad.   Ula: 32:43 Okay. Do you have a URL for that? Is it on Meetup? Raymond: 32:47 It's on meetup as well as, a group called Design Thinking Squad Gloucestershire. We did a Design Thinking Crash Course which is only about  2-3 hours. If I get a demand for it, I will arrange something. Ula: 32:59 So, anyone who's interested who probably is listening to this episode that wants to get in touch with you, the best would be your LinkedIn (profile). Okay. Wow, the time does fly when you're having fun. I've enjoyed the conversation. Raymond. Thank you so, so much for making the time. Raymond: 33:17 You are welcome. Ula: 33:18 Do you have any last word for the audience, before we wrap up? Raymond: 44:45 Yeah, I've enjoyed this conversation. Thank you as well for making this happen. I know it's been busy for me to really get the time around it but finally we made it work. We have been very adaptive and true to the nature of agile. I'd say to the listeners out there, keep your dreams alive. And… there's always a way around everything. Keep in touch. And, as I always say, the future belongs to those who learn faster. Ula: 33:54 Thanks a lot Raymond. Raymond: 33:56 Thank you so much.

Abstract:Nothing quite captures emotions and the perception of value as just having a simple conversation. JIRA tickets full of details still cannot display what a face-to-face conversation can. But challenging times, like now with the pandemic going on, require a different approach. Jeff Patton joins us to share his insights!What you'll discover in this show:-          COVID has shown that product delivery still continuous steadily-          Political discussions within the organizations are hard to break-          The point where conversations start to stop have a huge impact   Speakers:Jeff PattonVETERAN PRODUCT MANAGER, AGILE, LEAN, UX AND PRODUCT DESIGN EVANGELISTJeff Patton is the glue that connects good product management and strategy, lean user experience, and agile delivery practices together. He has authored numerous articles, essays and, most recently, a book, “User Story Mapping.” An independent consultant with a unique teaching and speaking style, he uses hand-drawings and engaging story-telling to share his passion for product design. Contact Jeff Patton: https://www.jpattonassociates.com/ https://www.linkedin.com/in/productdesigncoach/Sander Dur (host)Scrum Master, Agile Coach, trainer, and podcast host for ‘Mastering Agility”Sander Dur is a business agility enthusiast, with a passion for people. Whether it's healthy product development, agile leadership, measurement, or psychological safety, Sander has the drive to enable organizations to the best of their abilities. He is an avid article writer, working on a book about Scrum Mastery from the Trenches, and is connecting listeners with the most influential people in the industry. https://www.linkedin.com/in/sanderdur/ https://agilitymasters.com/en https://sander-dur.medium.com/ Additional resources: Buy Jeff's book right here!Support the show

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. There are characteristics we see over and over again in great product owners, we discuss those with Ines, and we cover User Story Mapping, a technique to help PO’s improve their game. The Great Product Owner: 3 characteristics for great Product Owners Ines describes for us 3 characteristics for great Product Owners which help the teams to understand the context and impact of their work, to feel motivated to contribute to the product, as well as to understand all the necessary details before committing to do the work. The Bad Product Owner: The Busy, Bossy and Absent PO In this segment, we talk about the PO  that was just a broken telephone for the team, and on top of that was bossy and too busy to answer questions. When you see these characteristics in the PO, what do you do? We discuss some approaches that might help, and discuss the Story Mapping technique (See here for a fully defined facilitation guide for the Story Mapping worksho Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Ines Garcia Ines is an Agile Coach, a Certified Scrum Professional® (CSP-SM), and a Salesforce MVP. She focuses on helping organizations every day to become more Agile whilst delivering Salesforce technology. She consults, speaks, and trains in these arenas always with the end in mind of enabling an evolution (not revolution). You can link with Ines Garcia on LinkedIn and connect with Ines Garcia on Twitter.

"Story Mapping ist meine liebste agile Praktik" sagt Tim. Im Gespräch mit Oliver erläutert er daher seine Leidenschaft für die Methode des Story Mapping und wie bzw. wo er Story Maps gerne einsetzt. Natürlich erfahrt ihr auch, aus welchen grundlegenden Elementen Story Maps bestehen und wie ihr sie mit euren Teams und Stakeholdern entwickeln könnt. Tim erklärt, warum für ihn die Diskussion über Wirkungsschnitte ("Target Outcomes") so zentral ist. Zudem hilft es massiv in der Diskussion mit deinen Stakeholdern. Zum anderen sorgt es für Klarheit - auch in der Diskussion mit dem ganzen Scrum Team bzw. Produkt- oder Projektteam. Target Outcomes bilden für Tim eine perfekte Verbindung zwischen einer agilen Roadmap und der Story Map. Je nach Abstraktionsebene kann ein solches Target Outcome sogar als Product Goal dienen. Wobei Product Goals vermutlich in der Regel etwas größer als ein Target Outcome sein dürften. Wenn ihr in dieser Weise ein (oder zwei) einzelne Slices der Story Map in euer Product Backlog überführt, habt ihr sofort mehr Fokus und damit Klarheit im Backlog. Auch Sprintziele (Sprint Goals) werden sich so sicherlich einfacher finden lassen. Zum Product Goal und Sprint Goal haben wir bereits Episoden in diesem Podcast veröffentlicht. Tim erwähnt diese Story Mapping Quellen: - Jeff Patton: User Story Mapping (Buch) - Jeff Patton: Story Mapping (Quick Reference) - Jeff Patton: Opportunity Canvas (Template) - Handouts, Übungen & Trainingsmaterial und der direkte Zugriff in die Dropbox von Jeff Patton (folgt dafür dem Link https://www.jpattonassociates.com/handouts/)

All the agility in a project isn't worth its salt unless the end result is usable. User Story Mapping can help. Friend of the show, Jaimie Olmstead, explains how to navigate a team through their product user's journey to build a backlog, identify any missing items, and paint a complete picture of a project plan.----Do you want to learn more about Scrum? Follow us!Twitter / Facebook: scrumsup | Instagram: twoscrumsupFind out more about Alley at https://alley.co

 Agile Atelier listeners! Welcome to another special episode today, where I talk to Jeff Patton on the different levels of planning seen in agile and non-agile environments. Jeff is most well-known for his book, User Story Mapping. He has designed and developed software for the past 20 years on a wide variety of projects from…… Continue reading Episode 29: Agility and Planning with Jeff Patton

James & Tim are both founders of Avion.io, a user story mapping tool that helps Product Teams to better collaborate and plan features, products, and services. When Tim came back from his Product Owner course 5 years ago, learning about user story mapping, he quickly realized together with James that this methodology makes planning much easier and efficient. Unfortunately, they were missing a tool to digitalize and remotely collaborate on a user story map. They sat together after work and started designing and developing Avion.io which they've launched in 2019. In this episode, they talk about the advantages of user story mapping as well as advanced techniques on release planning, MVP definitions, and some more cool story mapping life hacks. Table of content 0:30 - How Tim & James got into user story mapping 5:25 - User story mapping vs. customer journey mapping 8:30 - Story mapping during the product development cycle 13:30 - Product discovery with story mapping 19:00 - Defining MVPs and preparing the backlog 25:40 - Story mapping as a product documentation tool 26:15 - Advanced release planning with story mapping 32:15 - Downside of story mapping 35:25 - Bootstrapping Avion with story mapping 43:40 - Key takeaways from Tim & James 46:30 - Debrief Alex & Christian ✩ Follow The Product Bakery Podcast ✩

Choosing the right things to work on is often the hardest part in any role, especially product development. Whether it is strategic initiatives, product features, or backlog items, we have to ensure we're saying yes to the right things and saying no to the wrong things. In this episode we tackle a framework for making those hard decisions and how to incorporate the various prioritization methods (from MoSCoW to User Story Mapping) into your process. If you like this episode, you can find more information at https://productthinking.substack.com/p/strategic-prioritization

In this episode, Alex interviews co-host Christian Strunk to get some background on how he transitioned into Product Management. Christian started working as a baker before he studied business administration. While studying he founded his first start-up "Pocketrobe" which opened the doors into the world of Product Management... Besides his career path, Christian talks about his most favorite product planning methodology "user story mapping" and how to get started with it. If you're interested, listen in! For more information about story mapping & Product Management check out his blog. Episode minutes: 0:28 - Introduction Christian Strunk 8:00 - Product challenges in companies 8:45 - Get started with product planning 11:35 - Product planning with user story mapping 15:00 - Estabishing story mapping in the product development process 18:40 - When to not do user story mapping 21:25 - From planning to delivery (backlog preparation) 25:15 - Start planning from the end/back 30:30 - User story mapping or customer journey mapping? 35:05 - Christian's key takeaways & summary Connect with Christian: Website: www.christianstrunk.com Linkedin: @christianstrunk Twitter: @strunkchristian ✩ Follow The Product Bakery Podcast ✩

In this episode, Brian Kuhn, Vice President & General Manager of Elevate's Digital Strategy & Solutions Business, joins host Nicole Giantonio to discuss digital design thinking, digital transformation - which represents one-third of all IT spend globally, - and that today's organizations are using digital to get closer to end-users by accessing know-me insights.Brian said - "The machine will be a blunt instrument unless it incorporates the understanding of human beings who know those processes the best."Listen to hear his insights and experiences using technology and design thinking to digitally transform the legal operations and showing “know-me” insights to the end-user.Click on the links below to hear what we covered in this episode:[00:44] - How digital transformation Impacts the legal industry?[01:54] - Is the falling cost of technology, creating a risk?[02:35] - Law Firms in Transition 2019: An Altman Weil Flash Survey[03:21] - An Example where Brian explained how he is transforming the digital strategy at Elevate and why choosing the best technology is the critical element to drive the value.[05:26] - Dichotomy between machine learning and human learning – How Elevate has taken advantage of both to develop a scalable process for a customer?[07:41] - Does embedding the design thinking into the business processes yielding better results?o According to a McKinsey study, design-led companies had 32% more revenue and 56% higher total returns to shareholders compared with other companies.[08:54] - Is technology becoming more configurable and less expensive?o Businesses spent $1.2 Trillion in 2019 on Digital Transformation to grow, and in 2020, the worldwide IT spending is projected to total $3.9 trillion.[11:22] - The reason why the Fortune 500 CEOs are investing in AI.[12:48] - How can we persuade the stakeholders to embrace digital transformation for growth?[13:43] - How is Elevate using the Design thinking and User-Story Mapping tool to identify issues in the customer's business processes?[15:58] - Design Thinking hasn't been commercialized as an offering at scale yet within the legal industry.Enjoy!

Pour voir la version vidéo : https://youtu.be/gkxd5KH6HdM ----- En tant que Product Owner, avant de gérer un backlog, il faut le créer, l'initier, pour s'assurer de faire un bon produit. Quels sont les outils agiles de cadrage pour la vision produit, les user stories, etc. afin de bien commencer avec une équipe agile Scrum, avec un bon product backlog ? Cette vidéo fait partie de la série "Bien commencer Scrum", retrouvez la playlist ici ▶ https://www.youtube.com/watch?v=vCMrCJ-3Kf4&list=PLxTb_ZC4kmrQM2s2BTynZ3WShJhDBh57L&index=1 Découvrez-en plus dans la description ci-dessous

Podcast registrato a fine febbraio prima che la situazione coronavirus imponesse la quarantena. Una situazione difficile per tutti che vogliamo sdrammatizzare parlando di User Story Mapping

Сегодня я рассказываю о популярной технике для создания и управления скоупом требований в Аджайл: user story mapping (карта пользовательских историй). ********** Слушайте, оставляйте нам оценки и комментарии на платформах, где вы нас слушаете - для нас это важно :) ********** Мы в Instagram: Надя @na.ts , Кима @kima_yel ********** IT бизнес-анализ - это подкаст, где Кима делится с Надей ее взглядом и опытом в IT бизнес-анализе Кима -  IT бизнес-аналитик с 8-летним опытом в международной компании по разработке программного обеспечения Надя - финансист, который интересуется IT бизнес-анализом, и хотела бы изучить его с основ.

Ogni obiettivo di sprint dovrebbe essere un passo avanti verso un obiettivo di prodotto. Ogni obiettivo di prodotto dovrebbe aiutarci a raggiungere obiettivi di business e obiettivi utente, obiettivi che a loro volta dovrebbero aiutarci a realizzare la nostra visione. I diversi obiettivi sono quindi collegati tra loro e formano una catena che copre tutti gli aspetti della pianificazione del prodotto, da quelli strategici a quelli tattici. Impact Mapping e User Story Mapping sono due strumenti collaborativi che permettono di creare una "comprensione condivisa" tra team di sviluppo, product owner, stakeholder, designer... e questa è la vera chiave di volta per creare prodotti di successo.

Ogni obiettivo di sprint dovrebbe essere un passo avanti verso un obiettivo di prodotto. Ogni obiettivo di prodotto dovrebbe aiutarci a raggiungere obiettivi di business e obiettivi utente, obiettivi che a loro volta dovrebbero aiutarci a realizzare la nostra visione. I diversi obiettivi sono quindi collegati tra loro e formano una catena che copre tutti gli aspetti della pianificazione del prodotto, da quelli strategici a quelli tattici. Impact Mapping e User Story Mapping sono due strumenti collaborativi che permettono di creare una "comprensione condivisa" tra team di sviluppo, product owner, stakeholder, designer... e questa è la vera chiave di volta per creare prodotti di successo.

Listen in as Jay Stansell and James Sear and Tim Ramage chat about User Story Mapping for Modern Product Teams. To support the bushfire affected wildlife and communities of Australia that are mentioned in this episode head to bushfire.productcoalition.com To get pre-release access to all Product Coalition podcasts, product management mentorship, product management interview practice, and product management resume reviews, visit platform.productcoalition.comSupport the show (https://platform.productcoalition.com)

On this episode, we sit down with Red Hat Open Innovation Labs Senior Architect Patrick Carney to dive into Event Storming as way to align teams on a common understanding of the system they're building. Check out the Open Practice Library for yourself! openpracticelibrary.com ===== Event Storming: https://openpracticelibrary.com/practice/event-storming/ Cheetah facts: https://cheetah.org/learn/resource-library/ Value Slicing & User Story Mapping: https://openpracticelibrary.com/practice/user-story-mapping/ Autonomous Cheetah: https://www.cnn.com/2015/06/24/tech/mit-robotic-cheetah-darpa/index.html ===== Hit us up on Twitter: @practicelibrary Connect with Patrick LinkedIn: https://www.linkedin.com/in/patrick-s-carney/ Connect with Matt LinkedIn: https://www.linkedin.com/in/matttakane Twitter: @matt_takane Connect with Jerry LinkedIn: https://www.linkedin.com/in/jerry-becker Twitter: @jerryjokesalot Follow Open Practice Library Instagram: @OpenPracticeLibrary If you're liking this podcast so far, please review us on your fav podcast platform

Great Product Owners often focus on helping the team benefit from the knowledge and experience that stakeholders can bring to the team. In this episode, we learn about a PO that was focused on creating collaboration between team and stakeholders, as well taking the time to work together with the team to create a shared understanding of the product and the Vision for the team.  In this segment, we refer to the User Story Mapping technique popularized by Jeff Patton. Here is the User Story Mapping hands-on facilitator guide if you want to start using that technique at work.  The Bad Product Owner: The PO who didn’t want any help Sometimes we work with Product Owners that don’t want any help but are too busy to fully fulfill the requirements of the role. That’s never an easy situation for the team or the Scrum Master. Sami reminds us that we can take advantage of the PO being busy, and start offering help in certain tasks. Building trust with the PO is then a critical focus for Scrum Masters, and Sami shares her tips on how to build that relationship. In this segment, we refer to Module 02 (How Scrum Masters can onboard a new or beginner Product Owner) of the Coach Your Product Owner course, and how that can help you start a positive collaboration with your Product Owner. The course is available here: bit.ly/coachyourpo.   Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.   About Sami Prentice Sami is a Scrum Master in Denver, Colorado. She used to work in the beer industry before making the switch to Scrum Master and she is passionate about facilitating awesome meetings that don't suck.  You can link with Sami Prentice on LinkedIn.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website.  From tools to the habits that Product Owners need to drop, in this episode, we explore practices and an anti-pattern that can derail the relationship between PO and team. The Great Product Owner: The key tools/documents PO’s need to master When Product Owners are able to convey a message clearly, it is natural that the work with the team improves. However, there are certain tools that help that message stick and be followed by the team. In this segment, we explore 3 tools and 1 practice that can greatly help Product Owners convey their expected results, and be sure that the team understands what that means in practice. In this segment we refer to User Story Mapping, User Story slicing, Personas and Acceptance Test Driven Development.   The Bad Product Owner: The former team member who knew too much When a former team member, a developer, takes on the role of Product Owner, there are many possible anti-patterns to look out for. In this episode, we explore the case of the PO who knew too much, and decided to tell the team not only what to do, but also how to do it. Inevitably, problems followed. Listen in to learn how Dmytro helped that Product Owner. Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.   About Dmytro Balaba Dmytro calls himself one of the most dedicated Scrum Masters/Agile Coach in the world :) On his right-hand he has a tatoo with golden ratio, Fibonacci sequence. After almost 15 years of work in IT management Dmytro found himself balanced and happy. He’s been a full-time Scrum Master for more than 3 years. You can link with Dmytro Balaba on LinkedIn and connect with Dmytro Balaba on Twitter.

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website.  From the user-centric PO to the over-planner PO that failed to collaborate with the team, this episode covers plenty of aspects to keep an eye on when collaborating with your Product Owner. The Great Product Owner: The user-centric Product Owner Great Product Owners have a clear Vision for the product. But there’s a lot more to a great PO than the Vision. In this segment, we talk about the PO who was able to learn from quick releases, and validate their own assumptions about what value might mean for the end customer. Including, finding opportunities to help customers who were looking for a competitor product!  The Bad Product Owner: The non-collaborating Product Owner Usually, a Product Owner that has a clear set of items they want the team to work on would be on the “great product owner” category. But not in this case. Listen in to learn how a PO was good at planning but then failed at the most important thing: team collaboration. In this segment, we talk about the User Story Mapping workshop facilitator guide by Vasco Duarte. Check it out if you want to know how to prepare, and host a great User Story mapping workshop. Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate. About Eddy Bruin For many years, Eddy has been using serious games and learning metaphors to help teams and organizations move forward. He is an Agile and Test Coach with the mission to help teams deliver software people actually want to use while also enjoying their work. He helps teams to enable feedback loops continuously and likes to discuss all agile and test topics over a special beer. He loves to go to (un)conferences on serious games (for example Play14, Play4Agile), and also on Agile and Testing. You can link with Eddy Bruin on LinkedIn and connect with Eddy Bruin on Twitter.

On this first SunDDDay 26th May at 16:30 Central European Time (Amsterdam GMT +2), virtual DDD meetup will hold an online panel discussion where you can ask questions! Marco Heimeshoff, and Kenny baas-Schwegler (with a possible attendance by Zsófia Herendi and Trond Hjorteland) will discuss their experience with EventStorming and User story mapping for domain discovery. The two main questions are: * How can we best combine User Story Mapping and EventStorming for domain discovery. * How can we go from EventStorming to user stories.  

Netflix. Wir schauen es alle. Und ich glaube, das es eine der kompliziertesten, koordinierten Arbeitsformern ist, wenn z. Bsp. 20 Autoren eine konsistente Geschichte über 6 Staffeln a 15 Folgen erzählen. Jede Folge hat dabei einen Spannungsbogen, Drehungen und Wendungen, wiedererkennbare Charaktere, authentische Emotionen, Überraschungen und am Ende immer einen Cliffhanger, der dafür sorgt, dass wir am Schirm bleiben zum Binge Watching oder eben nächste Woche wieder einschalten. Wir wissen ein bisschen darüber wie das funktioniert und es muss ein schmaler Grad zwischen Kooperation, Planung und Kreativität und Delegation sein, der da beschritten wird. Wer ganz viel dazu weiss und überhaupt darüber, wie Story Telling funktioniert und wie wir es einsetzen können ist Christian Riedel, der Gründer von Growth by Story. Christian ist mein Gast in dieser 18. Folge von Stories Connecting Dots. Christian hilft Firmen dabei, Story Telling gezielt zur Verbesserung interner Kommunikation, Alignment innerhalb der Firma und auch beim Erzählen nach aussen - im Marketing - einzusetzen. Um das zu können, hat Christian Cultural Studies und Marketing studiert. Das hat ihm aber nicht gereicht. Er hat noch Game Research und Design dazu gepackt und schließlich auch noch eine Masterclass im Drehbuchschreiben durchgezogen. Das er Geschichten schreiben kann, hat der Kurzkrimi-Preis bewiesen, den er für deine Kurzgeschichte „Terroir" bekommen hat. Beruflich hat er in vielen Positionen und Kontexten gearbeitet. Ich habe ihn durch seine Arbeit bei Jimdo kennengelernt. Bei Jimdo hat er unglaublich dazu beigetragen, der Firma ein Gesicht, eine Stimme und eben eine Geschichte auch aussen zu geben. In dieser Folge sprechen wir vor allem darüber, was Story Telling kann und wofür man es einsetzen kann. In einer, bald erscheinenden, weiteren Folge sprechen wir darüber, wie Christian mit seinen Kunden am Story Telling arbeitet. Story Telling ist etwas fundamentales, archaisches und wir alle verstehen Geschichten. Wie Laufen, Sprechen und Atmen können wir es einfach. Umso spannender ist es, sich bewusster damit auseinander zu setzen und zu verstehen was Story Telling ist und kann. Passend dazu kam mir gerade noch der Artikel Why Humans Need Stories von Patrick Tanguay unter. Geschichten gab es schon immer - sie scheinen der Kitt zwischen Menschen zu sein und die Interaktionen - z. Bsp. Kooperation - zu ermöglichen. Christian spricht einen sehr wichtigen Aspekt an: die soziale Bedeutung von Geschichten: Wenn wir Aktionen im Nachhinein nicht begründen können, wirken wir autistisch oder asozial. Geschichten helfen uns, Verhalten im Nachhinein erklären zu können - sie helfen uns Verständnis zu schaffen. Für mich sind Geschichten so wichtig, weil sie Gruppen helfen ein gemeinsames Verständnis eines gemeinsamen Vorhabens zu erreichen. Und die bedeutsamsten Vorhaben bekommen wir nur in Gruppen hin. Alleine sind wir alle Zwerge. Daher setze ich Geschichten ein, wo immer es notwendig ist, in Gruppen dieses gemeinsame Verständnis zu erzeugen. Ich rede gerne davon „Kommunikation zu erzwingen“. Natürlich mache ich das nicht alleine und es ist nicht meine Idee. Die Geschichte von agiler Produktentwicklung ist voll davon und alleine die Begriffe User Stories und User Story Mapping zeigen woher sie kommen. Geschichten sind letztlich die einfachste und billige Weise, mit möglichen Zukünften umzugehen und diese verstehen zu können. Deshalb haben sie auch einen wichtigen Platz in der Produktarbeit. Bevor wir coden und entwickeln, sollten wir uns - billiger - über Geschichten annähern um zu verstehen ob die ausgedachte Zukunft Sinn macht. Ich glaube, wir können Story Telling nicht „benutzen" ohne es zu verstehen. Ich glaube, zu verstehen, wie andere Story Telling professionalisieren und fast schon industrialisieren, hilft uns dabei, unsere Arbeit mehr als kreative Zusammenarbeit zu verstehen und weniger als ein „Abarbeiten von Aufträgen". Die Metapher Story Telling macht uns erfolgreicher als die Metaphern „Fabrik" oder „Produktion". Zitate „Man darf die Regel nicht mit dem Ergebnis verwechseln … dafür sind auch zu viele von diesen Prinzipien Ex-Post von erfolgreichen Geschichten abgeleitet worden." „Never be boring!" „Das Emotionale führt zu einem Unsicherheitsgefühl, so dass man gegebenenfalls versucht, es über Regeln und Prozesse aus der Welt zu schaffen." „Aus der Falle kommt man nur raus, wenn man sich von dem Weltbild verabschiedet, dass der Mensch ein rationales Wesen ist, das in seinem Denken einem Computer ähnelt. Das ist er nicht." „(Geschichten erzählen) … hilft denen mit Visionen und Ideen, die eigene Idee für andere greifbar zu machen." „Story Telling führt zu einer Klärung, weil ich mir erst einmal Gedanken machen muss, wie ich es jemand anderem erkläre." „Man ist versucht, das Boot mit dem Ufer zu verwechseln. … Weil es komplizierter ist, sich Gedanken über das Ziel zu machen, macht man sich lieber Gedanken darüber, das Boot zu verbessern." „Die Magie im Writers Room liegt darin, die Balance zu finden von Strukturierung (meist mit Karteikarten an der Wand) und dem Detail dahinter. Also die Szenen zu planen, aber sie dann von einer Einzelperson ausfüllen zu lassen." Links - Growth by Story: Christians Firma - „Why Humans Need Stories" - Patrick Tanguay bei kottke.org - „Our fiction addiction: Why humans need stories" - BBC - Writers Room - die von Christian angesprochene Serie von Sundance, zu sehen bei Sky Arts  

Jeff Patton is an independent consultant, providing training, coaching and consulting services. He has designed and developed software for the past 20 years on a wide variety of projects from on-line aircraft parts ordering to electronic medical records. Jeff has also authored numerous articles, essays and, most recently, a book, “User Story Mapping”. In this episode Jeff Patton tells us why we need to spend time with the people who will use the software we deliver. Jeff also talks about the future of I.T. jobs and why you need to find that one thing that you’re passionate about. To find out more about this episode, visit the show notes page at www.itcareerenergizer.com/e52

Co-founder and Principal Software Craftsman of Greater Sum, Mike Clement is passionate about raising the bar of technical excellence in the software development community. One way to do that is by using user story maps. While Clement doesn't advocate for getting rid of backlogs altogether, he believes that user story mapping helps bring the story and user journey out of disparate tasks. The problem is backlogs don't immediately show how different user stories work together, and prioritization doesn't always help. Clement describes how user story mapping helps the business and teams to think about slices of value that can then be turned into a backlog for an upcoming iteration. This helps limit work in progress (WIP) and drive toward delivering real value. Howard Sublett hosts at Southern Fried Agile 2017 in Charlotte, North Carolina. To receive real-time updates: Podcast library: www.agileamped.com Subscribe to our newsletter: www.solutionsiq.com/agile-amped/ Connect on Twitter: twitter.com/AgileAmpedFollow us on Facebook: www.facebook.com/agileamped

Episode 15 of the Modern Agile Show features an interview with Jeff Patton, veteran agilest, author of the best-selling book, User Story Mapping and the guy who teaches the fantastic workshop, Passionate Product Leadership.

Agile UX Product Design with Yana Carstens and Jeff Patton Follow us on Twitter! @techdoneright (https://twitter.com/tech_done_right), and leave us a review on Apple Podcasts (https://itunes.apple.com/us/podcast/tech-done-right/id1195695341?mt=2). Guests Jeff Patton (https://twitter.com/jeffpatton): Author of User Story Mapping: Discover the Whole Story, Build the Right Product (https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909) and owner of Jeff Patton & Associates (http://jpattonassociates.com/). Yana Carstens (https://twitter.com/YanaCarstens): Senior User Experience Designer at TableXI (http://www.tablexi.com/). Summary Agile practices help you build software. UX design helps you build the right software. Teams often struggle integrating UX design into agile practice. In this episode, Jeff Patton, author of User Story Mapping, and UX Designer Yana Carstens talk about the importance of bringing UX design together with development and how to bring your team from unconscious competence to conscious competence. Notes 01:47 - Jeff’s Involvement with Company Product Development 03:31 - The History of Agile Software Development (https://en.wikipedia.org/wiki/Agile_software_development) 05:37 - The Role and Integration of the UX Designer 09:00 - Creating Products Without a Design Process - FUBU (https://en.wikipedia.org/wiki/FUBU) 12:21 - Consciousness and Competency - The Four Stages of Competence (https://en.wikipedia.org/wiki/Four_stages_of_competence) 16:08 - Advice for Newbies Striving to Reach the Competence Level in UX - The User Experience Team of One: A Research and Design Survival Guide by Leah Buley (https://www.amazon.com/User-Experience-Team-One-Research/dp/1933820187) 19:11 - Deciding Design Cadences Within Cycles 23:20 - When Designers are Sprinting Ahead of Developers; Lean User Experience - Implementing Lean UX In Large Organizations (https://www.axure.com/blog/archie-miller-of-carmax-on-implementing-lean-ux-in-large-organizations/) 28:48 - Inceptions and Product Strategy Workshops to Integrate Design Into Agile Development 31:16 - Team Development: The Benefits of Hiring Experienced Professionals and Upscaling the People You’ve Got 34:38 - UX Practices in the 90's vs 2010's - Agile 2017 Conference (https://www.agilealliance.org/agile2017/) Special Guests: Jeff Patton and Yana Carstens.

Darren Petersen is a Senior Technical Project Manager at Lullabot. He’s also incredibly knowledgeable about Agile. In this interview Darren and I discuss how Agile has been implemented at Lullabot. We dig into what works, what doesn’t, why he moved away from Story Points and all, and how Lullabot has been able to get dedicated teams in place. Note: During the interview Darren and I have a brief conversation about why it makes no sense to force yourself into the As a (some user) I want to (some action) so I can (some benefit) format just for the sake of using it. I promised to get him an official answer. You can find that here: SHOW NOTES 00:08 Interview Begins 00:47 Background on Lullabot 01:33 Managing 50 distributed team members 03:04 Using social media tools to stay connected with remote staff 05:57 Using Agile at Lullabot for client work 12:02 Making the case for some upfront planning, before using Agile during Development 12:50 Taking on the cost of teaching Agile to the client (who doesn’t care about Agile) 14:22 The way Lullabot sets up Teams to use Agile for client work 15:22 How can a digital agency maintain the business with dedicated teams 20:35 How dedicated teams impact the staff members morale and performance at Lullabot 23:27 Teaching customers to write decent User Stories 28:07 Should you force yourself into a User Story format when it doesn’t make sense? * 29:32 Why Darren doesn’t like using Story Points 33:00 How did Darren get so deep with Agile and what drives him to keep learning about it 36:19 Getting in touch with Darren 37:01 Interview Ends CONTACTING DARREN Twitter https://twitter.com/dsayswhat Email: darren.petersen@lullalbot.com About: https://www.lullabot.com/about/darren-petersen Lullabot https://www.lullabot.com LINKS MENTIONED IN THIS PODCAST User Stories Applied by Mike Cohn http://amzn.to/2vKv4JI Troy Magennis & Focused Objective http://focusedobjective.com User Story Mapping by Jeff Patton http://amzn.to/2wckyOg Agile Manifesto http://agilemanifesto.org

strong>Episode 6 - Solutions Episode - Glenn Mason - Using a Youtube Video as a Minimum Viable Product Lots of good information in this edition Using a YouTube Video as a minimum viable product Why "Scratching an itch" is the key ingredient in 50% of successful start-ups Why email is the "Raw Material" of our "Happy Customer" factory Our first discussion of the "WinterHaven method" - My Nickname for Dean Jacksons revolutionary approach to email marketing What is "User Story Mapping" and how mapping out the clients journey is an incredibly useful exercise Links from this episode Get Dean's book on his email marketing system for free Glenn's web development company The Video that kicked things off The GreyZoned website The Site Glenn built for me! The Your First Dollar book is out!!! You can download the book on the "Your First Dollar System" for free at this link

The post MBA081: User Story Mapping with David Hussman appeared first on Mastering Business Analysis.

We’ll take a look at why teams often use user stories to capture agile requirements and how the format often gets misused. If a user story isn’t a detailed requirement, then what is it? Mentioned in this episode:  User Story Mapping by Jeff Patton Like the podcast? I’d love it if you’d take 60 seconds to rate...

After chasing him across the east coast of Australia, Craig sits down with Jeff Patton at YOW! Conference in Sydney. Along the way they fail to remember the subtitle of Jeff’s “User Story Mapping” book and talk about: Art school dropout to software developer to early Extreme Programming “Extreme Programming Explained” by Kent Beck (and we agree the … Continue reading →

A story map is a simple way to visualize your product idea from your users’ perspective. Mapping your product's story uses the same approach scriptwriters use to think through a movie or TV story idea. It's fast, collaborative, and telling your product's story helps you spot the holes in your thinking. Once created, a map lets you think through options and alternative ideas that'll make your product better. It's easy to slice out what you think is a smallest viable product, and to identify the next experiment that'll help you validate your product concept.

Jeff Patton, author of User Story Mapping, teaches us how to map user stories by focusing on the user's journey to an outcome. He shares his opinion on the notorious "MVP" and how he helped Gary Levitt build his MVP with Mad Mimi.

In this episode consultant, author, and agile thought leader Jeff Patton shows us how to use Story Maps to create a shared understanding of a feature and create thin slices that relate to the minimum viable product and additional releases.  Jeff also shares his thoughts on the proper way to use User Stories and how to avoid […] The post MBA016: User Story Mapping with Jeff Patton appeared first on Mastering Business Analysis.

Vic is joined by Brett Palmer (@brett_palmer) and Larry Lawhead (@LarryLawhead) for a lively morning of Agile and coffee. Today our heroes discuss the following topics: Agile Planning - discussed WSJF and Donald Reinertsen's book "The Principles of Product Development Flow" User Story Mapping Roles in pair-coaching Servant Leadership AgileGathering.com has the info about our upcoming Agile Coach Camp US West, April 10-12, 2015

While at the Prairie DevCon in Calgary, Carl and Richard chatted with Steve Rogalsky about User Story Mapping. Steve explains how User Story Mapping helps with visualizing beyond a serial list of features into categories of features in the product. The conversation also explores how Kanban, Scrum and other techniques work with User Story Mapping, as well as the struggles of using Microsoft Project.Support this podcast at — https://redcircle.com/net-rocks/donations