Kevin Burns presented on story writing and mapping. He discussed how story mapping can help teams build a shared understanding of user needs and priorities to develop the right product. Story mapping organizes user tasks and details product features in a narrative format to help identify what should be included in minimum viable releases.
User Story Mapping is an approach for organizing and prioritizing user stories to plan valuable incremental product releases. It addresses problems with flat backlogs by showing features from the user's perspective and understanding the big picture. The process involves brainstorming major user tasks, grouping them from left to right in order of completion, then adding detailed user stories which are prioritized and broken into releases. Combining Impact Mapping with User Story Mapping allows prioritizing deliverables to achieve user goals through understanding individual scenarios and planning iterative delivery.
This document discusses user story mapping and provides an example of mapping out a morning routine. It explains that user story mapping helps create a shared understanding by focusing conversations on user experiences. The mapping process involves writing individual tasks or stories, organizing them into a narrative flow, exploring alternatives, distilling the map into a backbone, and slicing tasks to achieve specific outcomes. It then demonstrates this process by mapping out tasks for different goals of getting ready in the morning, either in a rush or with more leisurely time.
User Story Mapping Workshop (Design Skills 2016)Bartosz Mozyrko
User Story Mapping (USM) is a top-down approach of gathering "requirements" in agile environments.
"A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that deliver value to users and business with each release (from Jeff Patton's The New User Story Backlog Is a Map)."
The document discusses a presentation on using user story mapping to build better products. The presentation aims to teach how to use a user story backlog to describe a user's experience with a product. It covers mapping user stories based on user experience, planning valuable incremental releases from the story map, and iteratively constructing software. The presentation discusses starting with user stories, mapping them based on tasks and activities, and slicing the story map into valuable product releases.
User story mapping involves organizing user stories and tasks on a board to help plan and prioritize work. It is not the same as defining tasks, use cases, documents, or big stories that describe large amounts of work. Effective user story mapping divides stories into logical groups called "user activities" and smaller detailed tasks, then arranges them on a board from left to right in order of time. The mapped stories are then broken into iterative releases to guide incremental development.
Kevin Burns presented on story writing and mapping. He discussed how story mapping can help teams build a shared understanding of user needs and priorities to develop the right product. Story mapping organizes user tasks and details product features in a narrative format to help identify what should be included in minimum viable releases.
User Story Mapping is an approach for organizing and prioritizing user stories to plan valuable incremental product releases. It addresses problems with flat backlogs by showing features from the user's perspective and understanding the big picture. The process involves brainstorming major user tasks, grouping them from left to right in order of completion, then adding detailed user stories which are prioritized and broken into releases. Combining Impact Mapping with User Story Mapping allows prioritizing deliverables to achieve user goals through understanding individual scenarios and planning iterative delivery.
This document discusses user story mapping and provides an example of mapping out a morning routine. It explains that user story mapping helps create a shared understanding by focusing conversations on user experiences. The mapping process involves writing individual tasks or stories, organizing them into a narrative flow, exploring alternatives, distilling the map into a backbone, and slicing tasks to achieve specific outcomes. It then demonstrates this process by mapping out tasks for different goals of getting ready in the morning, either in a rush or with more leisurely time.
User Story Mapping Workshop (Design Skills 2016)Bartosz Mozyrko
User Story Mapping (USM) is a top-down approach of gathering "requirements" in agile environments.
"A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that deliver value to users and business with each release (from Jeff Patton's The New User Story Backlog Is a Map)."
The document discusses a presentation on using user story mapping to build better products. The presentation aims to teach how to use a user story backlog to describe a user's experience with a product. It covers mapping user stories based on user experience, planning valuable incremental releases from the story map, and iteratively constructing software. The presentation discusses starting with user stories, mapping them based on tasks and activities, and slicing the story map into valuable product releases.
User story mapping involves organizing user stories and tasks on a board to help plan and prioritize work. It is not the same as defining tasks, use cases, documents, or big stories that describe large amounts of work. Effective user story mapping divides stories into logical groups called "user activities" and smaller detailed tasks, then arranges them on a board from left to right in order of time. The mapped stories are then broken into iterative releases to guide incremental development.
Kevin Burns presented on story writing and mapping. He discussed how story mapping can help teams build a shared understanding of user needs and priorities to develop the right product. Story mapping organizes user tasks and details product features in a narrative format to help identify what should be included in minimum viable releases.
The document discusses common smells and anti-patterns related to user stories. It identifies 9 major issues: 1) forgetting about conversation, 2) thinking everything needs to be a user story, 3) thinking a user story needs to include everything, 4) skipping acceptance criteria, 5) not having a definition of done, 6) taking on stories that are too big or risky, 7) splitting stories incorrectly, 8) not having a definition of ready, and 9) skipping product backlog refinement. Examples are provided for each issue.
Creating a backlog of user stories is pretty straight forward but it doesn't help you when it comes to decisions like what to build first, how to prioritize and groom the backlog, how to scope and plan the project, and how to visualize progress. The traditional backlog is simply too flat and often too long to help you see the bigger picture and make good decisions. User Story Mapping helps simplify all of these common project issues. By adding a third dimension to your backlog, your team will make better decisions about priorities, scope, and planning while improving your ability to visualize progress.
In this practical session I’ll cover the basics of user story mapping before walking you through case studies of how our teams are using this approach and the results we are achieving. I'll show you the before, during, and after pictures from several projects so that you can understand how our maps progress during the projects and how we use them to influence iterative development, promote good decision making, and visualize priorities, plans, scope and progress.
Certified Scrum Product Owner: class desk, posters and photosAlexey Krivitsky
The document provides an overview of agile product management and scrum. It discusses key concepts like lean, agile, scrum roles and artifacts, ceremonies like sprints and planning, and topics like minimum viable products, user stories, prioritization techniques, and product backlog refinement. The document is a training guide or presentation on agile product management best practices.
User Story Mapping, Discover the whole storyJeff Patton
Variations of these slides have been used in a variety of talks.
These slides support discussions on why stories work, and when they don't. And, on story mapping, how and why it works.
The document contains instructions for drawing a summer meadow scene with specific elements like flowers, grass, cows, birds, and a sun. It begins with more open requirements to draw blue and red flowers with cows and birds under a sun. Then it provides closed, detailed requirements specifying the number and characteristics of each element to include in the drawing. The document discusses the difference between open and closed requirements.
Writing Good User Stories (Hint: It's not about writing)one80
User stories are typically the foundation of the Product Backlog. However, the original purpose has been lost. This is from a presentation that was given to help remind everyone of what User Stories are, and what they aren't. The purpose of User Stories is to drive conversations, not to hand "requirements" from one group to the next.
The document discusses how to break down large requirements into smaller, independent user stories for agile software development. It recommends following the INVEST principles to create user stories that are independent, negotiable, valuable, estimable, small, and testable. Some patterns for splitting large stories are also described, such as breaking stories into workflow steps, major efforts, business rule variations, and operations. The goal is to create functional pieces that deliver business value iteratively in a manageable way.
Tips for Effectively Applying the Product Owner RoleRoman Pichler
This slide deck offers tips to successfully apply the product owner role. It distinguishes different product owner flavours, explains hope the Scrum product owner role differs from the SAFe one, and how product ownership can be scaled.
Introduction to user story mapping open camp editionMichael Calleia
Revised and expanded talk on User Story Mapping.
User Story Mapping is a simple yet powerful and flexible tool that combines the visualization of software systems and user needs. While not the only tool you need, it is a powerful one to learn and keep in your toolkit. Learn to go from user stories to better conversations while increasing shared understanding.
Lean Startup + Story Mapping = Awesome Products FasterBrad Swanson
To deliver the right outcomes, you need to learn your customers needs and validate your assumptions as early as possible. This means getting an early version of your product completed to start testing, validating and improving. This session will demonstrate how to combine Lean Startup and User Story Mapping techniques to determine where to start and how to learn early and often.
Participants will start with a partially completed Lean Canvas to flesh out and then define a product roadmap by building a Story Map. We will use Lean Startup concepts of Minimal Viable Product (MVP) and validated learning to focus on outcome over output.
Learning objectives:
Understand the importance of accelerated learning and techniques to achieve it
How a Lean Canvas can help shape your product vision and MVP
How to build a story map to create a product roadmap
How to use a story map to validate your users' journey
This document discusses user stories (also called PBIs), which are short descriptions of a software feature written from the perspective of an end user. It provides templates and examples for writing user stories, as well as tips on splitting large stories into smaller, testable pieces. Some key points covered include writing stories that focus on the user's goal and benefit, using personas to discover needed features, and decomposing large "epic" stories until they are clear and feasible to implement.
The document discusses various options and variations for user interactions on a system, including:
- Searching in different languages or with different date ranges and criteria
- Creating policies with different review requirements
- Payment options with PayPal, Stripe or check
- Entering and uploading data in different formats
- Getting search results at different speeds
- Performing different account actions like signing up, editing settings, and deleting
It also provides advice on splitting user stories that are too large, suggesting combining very small stories or dividing large ones based on components like the front end, business rules, backend, and database.
User Story Mapping (USM) helps teams get a common understanding of requirements from the user's perspective to facilitate backlog creation. It improves backlog quality and team communication. USM creates a map with user stories arranged in a usage flow. Each story follows the "As a <user>, I want <goal> so that <benefit>" format. Together, the mapped stories provide an overview of a product from the user experience while maintaining granular stories for planning and testing.
Re-uploading my User Story Splitting workshop; it seems to have gone missing.
This is a slide deck I have used for helping people learn various user story splitting techniques.
Do you want to write great User Stories that provide the vehicle for conversation and confirmation that we build the right thing? Do you struggle with splitting stories so that they still provide business value but can be accomplished within a fraction of your iteration? We will do a quick refresher on User Story formatting to include Acceptance Criteria. Additionally we will learn techniques for splitting stories in this interactive workshop.
This document discusses improving user stories by following best practices like the INVEST acronym. It explains that user stories address common requirements gathering pitfalls by focusing on delivering value to end users, using their language, and enabling prioritization and incremental development. The document provides guidelines for writing "good" user stories, including having context, value, and acceptance criteria, as well as being independent, negotiable, estimable, small in size, and testable. It also identifies potential "user story smells" to avoid.
This document discusses agile software development practices with a focus on user stories. It covers the objectives of using user stories, a brief history and motivation for agile practices, an overview of the agile process including daily standups and planning meetings, and the components and writing of user stories. It also discusses managing projects using tools for planning, estimating, and tracking progress. Key practices for development teams like refactoring, test automation, and dealing with unplanned tasks are also summarized.
This document discusses writing effective user stories for agile software development. It defines what user stories are, how they follow the INVEST model, and how to gather and manage user stories through techniques like user role modeling, interviews, observation, and workshops. It also covers pros and cons of the user story approach.
Splitting Stories with the Hamburger Method - A Simple 5 Step ProcessStephen Tucker
The document discusses Adzic's Hamburger Method for vertically splitting user stories into smaller stories. It provides an overview of the method, which involves identifying layers or types of tasks needed to complete the story, then identifying options for each task from least to greatest value. The first "bite" or user story combines the least valuable option from each task. Subsequent bites build on prior bites by enhancing them. The document includes an example application of the method and a quiz.
User Story Mapping: Discover the whole story, build the right productJoan Choi
This document provides an overview and summary of the book "User Story Mapping: Discover the whole story, build the right product" by Jeff Patton. The book discusses how using a technique called Story Mapping can help product teams focus on users and their experiences, improve communication, and ultimately build better products. Story Mapping is a process that involves writing out stories step-by-step, organizing them, exploring alternative stories, distilling them into a "backbone", and slicing out tasks to achieve specific outcomes. It is presented as a way to create a better environment for developing more effective products.
The document discusses common smells and anti-patterns related to user stories. It identifies 9 major issues: 1) forgetting about conversation, 2) thinking everything needs to be a user story, 3) thinking a user story needs to include everything, 4) skipping acceptance criteria, 5) not having a definition of done, 6) taking on stories that are too big or risky, 7) splitting stories incorrectly, 8) not having a definition of ready, and 9) skipping product backlog refinement. Examples are provided for each issue.
Creating a backlog of user stories is pretty straight forward but it doesn't help you when it comes to decisions like what to build first, how to prioritize and groom the backlog, how to scope and plan the project, and how to visualize progress. The traditional backlog is simply too flat and often too long to help you see the bigger picture and make good decisions. User Story Mapping helps simplify all of these common project issues. By adding a third dimension to your backlog, your team will make better decisions about priorities, scope, and planning while improving your ability to visualize progress.
In this practical session I’ll cover the basics of user story mapping before walking you through case studies of how our teams are using this approach and the results we are achieving. I'll show you the before, during, and after pictures from several projects so that you can understand how our maps progress during the projects and how we use them to influence iterative development, promote good decision making, and visualize priorities, plans, scope and progress.
Certified Scrum Product Owner: class desk, posters and photosAlexey Krivitsky
The document provides an overview of agile product management and scrum. It discusses key concepts like lean, agile, scrum roles and artifacts, ceremonies like sprints and planning, and topics like minimum viable products, user stories, prioritization techniques, and product backlog refinement. The document is a training guide or presentation on agile product management best practices.
User Story Mapping, Discover the whole storyJeff Patton
Variations of these slides have been used in a variety of talks.
These slides support discussions on why stories work, and when they don't. And, on story mapping, how and why it works.
The document contains instructions for drawing a summer meadow scene with specific elements like flowers, grass, cows, birds, and a sun. It begins with more open requirements to draw blue and red flowers with cows and birds under a sun. Then it provides closed, detailed requirements specifying the number and characteristics of each element to include in the drawing. The document discusses the difference between open and closed requirements.
Writing Good User Stories (Hint: It's not about writing)one80
User stories are typically the foundation of the Product Backlog. However, the original purpose has been lost. This is from a presentation that was given to help remind everyone of what User Stories are, and what they aren't. The purpose of User Stories is to drive conversations, not to hand "requirements" from one group to the next.
The document discusses how to break down large requirements into smaller, independent user stories for agile software development. It recommends following the INVEST principles to create user stories that are independent, negotiable, valuable, estimable, small, and testable. Some patterns for splitting large stories are also described, such as breaking stories into workflow steps, major efforts, business rule variations, and operations. The goal is to create functional pieces that deliver business value iteratively in a manageable way.
Tips for Effectively Applying the Product Owner RoleRoman Pichler
This slide deck offers tips to successfully apply the product owner role. It distinguishes different product owner flavours, explains hope the Scrum product owner role differs from the SAFe one, and how product ownership can be scaled.
Introduction to user story mapping open camp editionMichael Calleia
Revised and expanded talk on User Story Mapping.
User Story Mapping is a simple yet powerful and flexible tool that combines the visualization of software systems and user needs. While not the only tool you need, it is a powerful one to learn and keep in your toolkit. Learn to go from user stories to better conversations while increasing shared understanding.
Lean Startup + Story Mapping = Awesome Products FasterBrad Swanson
To deliver the right outcomes, you need to learn your customers needs and validate your assumptions as early as possible. This means getting an early version of your product completed to start testing, validating and improving. This session will demonstrate how to combine Lean Startup and User Story Mapping techniques to determine where to start and how to learn early and often.
Participants will start with a partially completed Lean Canvas to flesh out and then define a product roadmap by building a Story Map. We will use Lean Startup concepts of Minimal Viable Product (MVP) and validated learning to focus on outcome over output.
Learning objectives:
Understand the importance of accelerated learning and techniques to achieve it
How a Lean Canvas can help shape your product vision and MVP
How to build a story map to create a product roadmap
How to use a story map to validate your users' journey
This document discusses user stories (also called PBIs), which are short descriptions of a software feature written from the perspective of an end user. It provides templates and examples for writing user stories, as well as tips on splitting large stories into smaller, testable pieces. Some key points covered include writing stories that focus on the user's goal and benefit, using personas to discover needed features, and decomposing large "epic" stories until they are clear and feasible to implement.
The document discusses various options and variations for user interactions on a system, including:
- Searching in different languages or with different date ranges and criteria
- Creating policies with different review requirements
- Payment options with PayPal, Stripe or check
- Entering and uploading data in different formats
- Getting search results at different speeds
- Performing different account actions like signing up, editing settings, and deleting
It also provides advice on splitting user stories that are too large, suggesting combining very small stories or dividing large ones based on components like the front end, business rules, backend, and database.
User Story Mapping (USM) helps teams get a common understanding of requirements from the user's perspective to facilitate backlog creation. It improves backlog quality and team communication. USM creates a map with user stories arranged in a usage flow. Each story follows the "As a <user>, I want <goal> so that <benefit>" format. Together, the mapped stories provide an overview of a product from the user experience while maintaining granular stories for planning and testing.
Re-uploading my User Story Splitting workshop; it seems to have gone missing.
This is a slide deck I have used for helping people learn various user story splitting techniques.
Do you want to write great User Stories that provide the vehicle for conversation and confirmation that we build the right thing? Do you struggle with splitting stories so that they still provide business value but can be accomplished within a fraction of your iteration? We will do a quick refresher on User Story formatting to include Acceptance Criteria. Additionally we will learn techniques for splitting stories in this interactive workshop.
This document discusses improving user stories by following best practices like the INVEST acronym. It explains that user stories address common requirements gathering pitfalls by focusing on delivering value to end users, using their language, and enabling prioritization and incremental development. The document provides guidelines for writing "good" user stories, including having context, value, and acceptance criteria, as well as being independent, negotiable, estimable, small in size, and testable. It also identifies potential "user story smells" to avoid.
This document discusses agile software development practices with a focus on user stories. It covers the objectives of using user stories, a brief history and motivation for agile practices, an overview of the agile process including daily standups and planning meetings, and the components and writing of user stories. It also discusses managing projects using tools for planning, estimating, and tracking progress. Key practices for development teams like refactoring, test automation, and dealing with unplanned tasks are also summarized.
This document discusses writing effective user stories for agile software development. It defines what user stories are, how they follow the INVEST model, and how to gather and manage user stories through techniques like user role modeling, interviews, observation, and workshops. It also covers pros and cons of the user story approach.
Splitting Stories with the Hamburger Method - A Simple 5 Step ProcessStephen Tucker
The document discusses Adzic's Hamburger Method for vertically splitting user stories into smaller stories. It provides an overview of the method, which involves identifying layers or types of tasks needed to complete the story, then identifying options for each task from least to greatest value. The first "bite" or user story combines the least valuable option from each task. Subsequent bites build on prior bites by enhancing them. The document includes an example application of the method and a quiz.
User Story Mapping: Discover the whole story, build the right productJoan Choi
This document provides an overview and summary of the book "User Story Mapping: Discover the whole story, build the right product" by Jeff Patton. The book discusses how using a technique called Story Mapping can help product teams focus on users and their experiences, improve communication, and ultimately build better products. Story Mapping is a process that involves writing out stories step-by-step, organizing them, exploring alternative stories, distilling them into a "backbone", and slicing out tasks to achieve specific outcomes. It is presented as a way to create a better environment for developing more effective products.
Build – Measure – Learn is one of the most important mechanisms of agile software development. However, this mechanism is often crippled in nowadays projects, where traditional approaches of requirements gathering are bloating up product backlogs that cannot be prioritized anymore in a meaningful way. The results are customers not interested in iteration results, release to production that happens only at the end of the project, and feedback from customers when it is already too late and the budget is burned up.
Story mapping is a method that aligns user stories along desirable outcomes, so that customers can give sooner meaningful feedback, and release to production can happen earlier. The method helps slicing and prioritizing user stories, and addresses the product design aspect that is missing when just working with a product backlog. The method is highly visual and facilitates shared product ownership among product owner, team and customer.
This presentation provide an introduction to the concept of story mapping, with examples and experience gathered in own projects.
At the heart of it, how we build great products is by listening to people's needs and problems, and then devising solutions to them. We can communicate those solutions through storytelling and intentional visualization. When combined, these tools tell a better more compelling story and allow us to make real change in the world.
This document summarizes three user research hacks presented by Gene Smith at UX Lisbon in 2012. The hacks provide kludgy but effective ways to conduct user research when clients have small budgets, limited time, or lack executive support. The first hack uses a content prioritization card sort to understand users' information needs. The second hack uses A/B testing in SurveyMonkey to evaluate website mockups. The third hack boosts interview responses by having participants select emotion cards to describe their experiences. The goal is to provide low-cost, high-impact ideas for user research projects.
The document provides an overview of the product management lifecycle and role. It discusses defining product opportunities by understanding customer problems, technologies, and a company's capabilities. It also covers product discovery frameworks like minimum viable products and jobs-to-be-done. The agenda includes understanding customers, creating personas and wireframes, using analytics to check hypotheses, and approaching typical PM interview questions with a focus on structured thinking.
The document provides an overview of the product management lifecycle and role. It discusses defining product opportunities by understanding customer problems, technology solutions, and a company's capabilities. It also covers product discovery frameworks like minimum viable products and jobs-to-be-done. The agenda includes understanding customers, creating personas and wireframes, using analytics to check hypotheses, and approaching typical PM interview questions with a focus on structured thinking.
User Story Mapping for Minimum Lovable Productsuxpin
You'll learn:
How to visualize user needs instead of product features
How to make better decisions when prioritizing a UX backlog
How to align sprints with UX strategy
Content Strategy Academy Presentation SlidesHarvardComms
The document provides tips and best practices for writing content in a digital context. It recommends using short sentences of 15-20 words on average, using bulleted lists to break up long pieces of information, and using active voice to increase comprehension and clearly state who is responsible for actions. The document also discusses research on how people interact with content online, scanning pages and barely scrolling, emphasizing the need for brevity and clear organization of information.
User Story Mapping for Minimum Lovable ProductsKelley Howell
I gave this presentation at the UX Agile Summit, 2017.
If you have ever sat there staring at your screen or a white board, wondering where to start. If you've ever wondered how you could possibly organize all these user stories into some kind of well-organized plan for iteratively releasing your product, this talk is for you!
In this talk, I will share a way you can generate user stories, organize your backlog, and plan out releases in a way that will ensure that the product is not just minimally viable, but minamally lovable.
This slide deck covers why primary market research (aka customer development, customer research or customer empathy) is important and necessary, outlines how to organize a successful research program, provides a sampling of common qualitative and quantitative primary market research techniques, and provides an FAQ section on common questions.
Materi Perancangan Aplikasi Mobile yang disampaikan pada acara Bimbingan Teknis Entrepreneurship Kreatif Digital (Mobile Application dan Game) 16-17 September 2016 oleh Hanifah M Azzahra, S.Sn., M.Ds. yang diadakan oleh Badan Ekonomi Kreatif (Bekraf) bekerjasama dengan Universitas Brawijaya Malang
User Story Maps: Secrets for Better Backlogs and PlanningAaron Sanders
User story mapping is an intuitive way to build and organize a product backlog. During this session you’ll get hands-on experience building a user story map. You’ll learn:
How story mapping drives productive conversations with users and stakeholders.
How to plan incremental releases of your product using minimal holistic slices that deliver value at each product release.
Secrets to effective prioritization for both planning releases, and figuring out what to build next.
Tactical management of your backlog as you grow your working software to releasability.
The backlog building and managing strategies in this session will take you well beyond the agile basics.
Experiments never killed anybody - Rajiv Srivatsa, UrbanLadder & Thiagarajan,...ProductNation/iSPIRT
The document discusses the importance of experiments in validating ideas and making decisions. It provides examples from Urban Ladder of how they designed and conducted experiments to test assumptions and gather user feedback. Key aspects of experiment design discussed are identifying the problem, developing hypotheses to test, running targeted experiments to collect meaningful data, and using the results to inform next steps. Conducting many small, low-cost experiments is advocated over large projects to reduce risks and costs from failed assumptions.
The Secret to Successful Survey ProjectsBrent Chudoba
Better decision making fueled by data. A primer on how to run a successful survey project from hypothesis through survey design, analysis and implementation.
Webinar - Data Stories to Attract BusinessesErik Larson
Everyone loves a good story and businesses are no different. This webinar covers the powerful science behind storytelling and persuading with data. Includes great success stories of economic development organizations. More information at www.eimpact.report
UX Field Research Toolkit - Updated for Big Design 2018Kelly Moran
Looking for practice with in-depth UXR fieldwork methods? You may have read about these techniques in the past, but methods must be practiced to be understood. projekt202 has been employing the experience research craft with great success since 2003. This workshop is your opportunity to try these tools of the trade in a structured environment without pressing deadlines or looming stakeholders. Our experienced research and design professionals will share industry tips and tricks that will help you put theory to practice.
The workshop will be hands-on and interactive; instructional elements will be reinforced with stories of impact to real projects. We will not only cover methods of gathering user data, but the importance of spending time internalizing and analyzing the data through activities such as affinity diagramming, persona building, and journey mapping. Participants will gain exposure to these important practices in a low-pressure atmosphere and with the guidance of experienced professionals.
Presented at ThreeBridge Solutions at Minneapolis SAFe Meetup on Aug 2nd, 2018. This talk walked through the challenges of a large scale, green-field, application development and how we solutioned efficient communication across the program in order to maximize software engineering efficient delivery of value.
What makes a great scrum team coach example with poll resultsDevJam
The document presented techniques and topics for being a great scrum team coach, including the Westrum model for organizational information processing, Conway's law, context switching costs, child vs adult learning styles, the Socratic method, scientific management vs servant leadership, and the Shu Ha Ri model of skill development. The presentation included exercises for identifying top coaching attributes and practices and discussing how to implement them.
How do you know you are delivering value minnebar13 - 4-13-18 with poll res...DevJam
In honor of Robert M. Pirsig, author of Zen and the Art of Motorcycle Maintenance, let’s have a Chautauqua on quality and value how we’re measuring it. Piggy-backing on last year’s theme from the Twin Cities Agile Day, we’re part of an AntiFrAgile organization if we’re measuring the right stuff. Are we measuring the right stuff? How do you know? I’ll share some philosophy, thoughts, and experience to start our discussion. We’ll use a polling tool to make the discussion interactive, participatory, and allow you to share your stories and experience.
How do you know you are delivering value pmi mn 3-19-18 with poll resultsDevJam
The document is a presentation about how to deliver value, quality, and have a beneficial impact. It discusses themes of transparency, caring, continuous learning, and measures. It emphasizes the importance of understanding customer needs, continuously learning, and using meaningful quantitative measures to evaluate impact and ensure value is being delivered.
How do you know you are delivering value agile day twin cities 11-17-2017 w...DevJam
In honor of Robert M. Pirsig’s, author of Zen and the Art of Motorcycle Maintenance, let’s have a Chautauqua on quality and value how we’re measuring it. We’re part of an AntiFrAgile organization if we’re measuring the right stuff. Are we measuring the right stuff? I’ll share some philosophy and experience to start our discussion. We’ll use a polling tool to make the discussion interactive, participatory, and allow you to share your stories and experience.
How do you know you are delivering value lean meetup with polling resultsDevJam
Presented by Kevin Burns at the Lean Startup Circle MN Sept. 7, 2017. Kevin merged concepts from many influential authors into a group discussion regarding measuring value in our business environments.
How do we know we're delivering value? MNAEG May 23, 2017DevJam
In honor of Robert M. Pirsig, we had a discussion on how to measure value (quality, impacts, and outcomes). We spend too much time looking for efficiency and not enough time figuring-out how to measure whether the features we're delivering are having a beneficial impact.
How do we know we're delivering value? Twin Cities Agile Meetup May 9, 2017DevJam
In honor of Robert M. Pirsig, Kevin gave a chautauqua on value, quality, and making a difference at the Twin Cities Agile Meetup Group meeting May 9th, 2017
Most organizations are measuring costs but few are measuring the impact their software changes are having on users and their organizations bottom-line. This talk brings together concepts from different authors to discuss how to measure software delivery value, impact and outcomes.
The document discusses collaboration in agile software development. It defines collaboration as working with others to achieve shared goals through cooperation and teamwork. The document emphasizes that collaboration should happen throughout the agile process, including collaborative chartering at the beginning to define goals and working agreements, daily standups for updates, reviews and demos to get feedback, and retrospectives for continuous improvement. It questions whether development teams are collaborating enough with their customers and each other.
Evidence based decision-making - lean product developmentDevJam
Presentation mostly based on Don Reinertsen's book The Principles of Product Development: Flow, Second Generation Lean Product Development. It was presented at the MN Agile Experience Group meeting at the University of St. Thomas on Jan. 17, 2017.
The document discusses what makes a great product coach. It begins with an agenda that covers coaching topics like learning styles, the Socratic method, and leadership approaches. It then describes surveys and exercises to identify coaching attributes and practices. The presentation aims to increase understanding of great coaching and identify new techniques to try. It covers concepts like child and adult learning differences, leadership models, and Agile principles. The goal is for attendees to learn coaching methods and recognize how to apply them.
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
Artificia Intellicence and XPath Extension FunctionsOctavian Nadolu
The purpose of this presentation is to provide an overview of how you can use AI from XSLT, XQuery, Schematron, or XML Refactoring operations, the potential benefits of using AI, and some of the challenges we face.
Transform Your Communication with Cloud-Based IVR SolutionsTheSMSPoint
Discover the power of Cloud-Based IVR Solutions to streamline communication processes. Embrace scalability and cost-efficiency while enhancing customer experiences with features like automated call routing and voice recognition. Accessible from anywhere, these solutions integrate seamlessly with existing systems, providing real-time analytics for continuous improvement. Revolutionize your communication strategy today with Cloud-Based IVR Solutions. Learn more at: https://thesmspoint.com/channel/cloud-telephony
Top Benefits of Using Salesforce Healthcare CRM for Patient Management.pdfVALiNTRY360
Salesforce Healthcare CRM, implemented by VALiNTRY360, revolutionizes patient management by enhancing patient engagement, streamlining administrative processes, and improving care coordination. Its advanced analytics, robust security, and seamless integration with telehealth services ensure that healthcare providers can deliver personalized, efficient, and secure patient care. By automating routine tasks and providing actionable insights, Salesforce Healthcare CRM enables healthcare providers to focus on delivering high-quality care, leading to better patient outcomes and higher satisfaction. VALiNTRY360's expertise ensures a tailored solution that meets the unique needs of any healthcare practice, from small clinics to large hospital systems.
For more info visit us https://valintry360.com/solutions/health-life-sciences
How Can Hiring A Mobile App Development Company Help Your Business Grow?ToXSL Technologies
ToXSL Technologies is an award-winning Mobile App Development Company in Dubai that helps businesses reshape their digital possibilities with custom app services. As a top app development company in Dubai, we offer highly engaging iOS & Android app solutions. https://rb.gy/necdnt
E-commerce Development Services- Hornet DynamicsHornet Dynamics
For any business hoping to succeed in the digital age, having a strong online presence is crucial. We offer Ecommerce Development Services that are customized according to your business requirements and client preferences, enabling you to create a dynamic, safe, and user-friendly online store.
Using Query Store in Azure PostgreSQL to Understand Query PerformanceGrant Fritchey
Microsoft has added an excellent new extension in PostgreSQL on their Azure Platform. This session, presented at Posette 2024, covers what Query Store is and the types of information you can get out of it.
Flutter is a popular open source, cross-platform framework developed by Google. In this webinar we'll explore Flutter and its architecture, delve into the Flutter Embedder and Flutter’s Dart language, discover how to leverage Flutter for embedded device development, learn about Automotive Grade Linux (AGL) and its consortium and understand the rationale behind AGL's choice of Flutter for next-gen IVI systems. Don’t miss this opportunity to discover whether Flutter is right for your project.
SMS API Integration in Saudi Arabia| Best SMS API ServiceYara Milbes
Discover the benefits and implementation of SMS API integration in the UAE and Middle East. This comprehensive guide covers the importance of SMS messaging APIs, the advantages of bulk SMS APIs, and real-world case studies. Learn how CEQUENS, a leader in communication solutions, can help your business enhance customer engagement and streamline operations with innovative CPaaS, reliable SMS APIs, and omnichannel solutions, including WhatsApp Business. Perfect for businesses seeking to optimize their communication strategies in the digital age.
Hand Rolled Applicative User ValidationCode KataPhilip Schwarz
Could you use a simple piece of Scala validation code (granted, a very simplistic one too!) that you can rewrite, now and again, to refresh your basic understanding of Applicative operators <*>, <*, *>?
The goal is not to write perfect code showcasing validation, but rather, to provide a small, rough-and ready exercise to reinforce your muscle-memory.
Despite its grandiose-sounding title, this deck consists of just three slides showing the Scala 3 code to be rewritten whenever the details of the operators begin to fade away.
The code is my rough and ready translation of a Haskell user-validation program found in a book called Finding Success (and Failure) in Haskell - Fall in love with applicative functors.
5. Peace Corp Recruitment and Public Affairs
Story of how we used technology to
improve Peace Corp recruitment.
Switch from USPS to email
Switch from manual data entry to wild-card
search in gopher email system and screen
scraping results, an early for of ETL.
Conduct direct email campaigns when spam
still meant ‘meat in a can’
kburns@sagesw.com, @kevinbburns 5
7. How is value determined?
• Is value determined by delivery on
time, on budget, and on scope?
• Are your features delighting your
customers?
• Is all scope created equal?
• How do you know the value of the
scope?
kburns@sagesw.com, @kevinbburns 7
8. In a survey of 4 products, 65% of the features were rarely or never used.
How much money could have been
saved if we never built them?
In the Waterfall project world, we have to ask
for everything we can think of because capital
will end at the end of the project. Instead we
should be asking what has the most value in
terms of the business outcome and/or impact
and how are we going to measure it.
kburns@sagesw.com, @kevinbburns 8
9. Traditional Process
Schedule / CadenceTeam / CostRequirements
Schedule / Waterfall Features
Agile Approach
Team / Cost
Stabilize
Variable
kburns@sagesw.com, @kevinbburns 9
13. Do we all have
the same
understanding?
How do we
know?
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 13
14. Stop trying to write perfect
documents
Good documents are like
vacation photos
Document to help remember
Take a picture of your work to
help remember
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 14
15. Your job isn’t to write
better docs, it’s to
change the world.
Can you turn your
work into a Vocation?
kburns@sagesw.com, @kevinbburns 15
16. Stories create Understanding
• Stories aren’t a written form of requirements; telling stories through
collaboration with words and pictures is a mechanism that builds
shared understanding.
• Stories aren’t the requirements; they’re discussions about solving
problems for our organization, our customers, and our users that lead
to agreements on what to build.
• Your job isn’t to build more software faster: it’s to maximize the
outcome and impact you get from what you choose to build.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 16
17. Focus on User Interactions
Story mapping keeps us
focused on users and
their experience, and
the result is a better
conversation, and
ultimately a better
product.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
Good story conversations are about who
and why, not just what.
kburns@sagesw.com, @kevinbburns 17
18. Where to start?
• There’s always more to build than you have people, time, or money for.
• The goal shouldn’t be to implement everything we can think of, rather
what is the minimal amount we should implement to achieve desired
impact.
• Start with the most important user/customer.
• Map for a product release across multiple teams to visualize
dependencies.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 18
19. Story Mapping Mechanics
• Mapping your story helps you find holes in your thinking.
• Map only what you need to support your conversation.
• Reorganizing cards together allows you to communicate without saying
a word.
• Focus on the breadth of the story before diving into the depth.
• Use short verb phrases to capture what the user wants to do.
• Scope doesn’t creep; understanding grows.
• Focus on what you hope will happen outside the system to make
decisions about what’s inside the system.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 19
20. User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 20
21. Release slicing (roadmap) – MVP for release?
Don’t Prioritize Features
Prioritize Outcomes
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 21
22. Minimum Viable Product (MVP) defined
• The minimum viable product is the smallest product release that
successfully achieves its desired outcomes.
• Minimum is a subjective term. So be specific about who it’s subjective to—
because it’s not you. Be specific about who your customers and users are,
and what they need to accomplish. What’s minimum to them?
• The minimum viable solution is the smallest solution release that
successfully achieves its desired outcomes.
• A minimal viable product is also the smallest thing you could create or do
to prove or disprove an assumption. Eric Reis – Lean Startup
• Minimum viable product experiment
• Minimum valuable solution/product
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 22
23. What’s the Opportunity?
• What is the big idea?
• Who are the customers?
• Who are the users?
• Why would they want it?
• What problems would it solve for customers and users that they
couldn’t solve today?
• What benefit would they get from buying and using it?
• Why are we building it?
• If we build this product and it’s successful, how does that help us?
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 23
24. Test your assumptions and hypothesis
• Validate that the problems you’re solving really exist.
• Prototype and test with users to learn whether your solution is
valuable and usable.
• Users want more than they use. (50-80% more)
• Build > Measure > Learn, rinse and repeat
• Development Partners (from the business) help validate your
assumptions and hypothesis
• Iterate until Viable/Valuable is achieved
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 24
25. Bad Release
Strategy
Good Release
Strategy
Treat every release as an experiment and be mindful of
what you want to learn.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 25
26. User Story Mechanics
• User tasks are the basic building blocks of a story map.
• Use the goal-level concept to help you aggregate small tasks or decompose
large tasks.
• Maps are organized left-to-right using a narrative flow: the order in which
you’d tell the story.
• Details, alternatives, variations, and exceptions fill in the body of a map.
“What about…?”
• Activities aggregate tasks directed at a common goal.
• Activities and high-level tasks form the backbone of a story map.
• Use slices to identify all the tasks and details relevant to a specific
outcome.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 26
27. User Story Mechanics Summary
• Tasks are short verb phrases that describe what people do.
• Tasks have different goal levels.
• Tasks in a map are arranged in a left-to-right narrative flow.
• The depth of a map contains variations and alternative tasks.
• Tasks are organized by activities across the top of the map.
• Activities form the backbone of the map.
• Slice map to identify tasks you’ll need to reach a specific outcome.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 27
28. 6 Steps to Story Mapping
1. Frame the problem
2. Map the big picture
3. Explore users and interactions
4. Slice out a release strategy
5. Slice out a learning strategy
6. Slice out a development strategy
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 28
29. More on Why
• We can both read the same document, but have a different
understanding of it.
• Kent Beck’s simple idea was to stop trying to writing the perfect
document, and to get together to tell stories.
• Stories get their name from how they’re supposed to be used, not from
what you’re trying to write them.
• If you’re not getting together to have rich discussions about your stories,
then you’re not really using stories.
• The best solutions come from collaboration between the people with the
problems to solve and the people who can solve them.
• Story conversations are about working together to arrive at the best
solution to a problem we both understand.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 29
30. Ron Jeffries 3 Cs from Extreme Programming Installed
Card: Write what you’d
like to see in the
software on index cards.
Conversation: Have a
rich conversation about
what to build.
Confirmation: Agree on
how you’ll confirm
definition of done.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 30
31. Story card attributes
• Title (name)
• Description (Who, What, Why)
• Acceptance Criteria (Definition of Done)
• Story number
• Estimate, size, or budget
• Value
• Metrics
• Dependencies
• Status
• Dates
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 31
32. Working remotely
• Use a document camera or web camera during a video conference to
let remote people see what’s being created on the wall.
• When collaborating remotely, use tools that allow everyone to see,
add to, and organize the model concurrently.
• Use tools to post pictures, videos, and text to help you retain and
remember your conversations.
• Use tools to sequence, track, and analyze progress.
• Handing off all the details about the story to someone else to build
doesn’t work. Don’t do that.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 32
33. For every story, there are two to follow. Alistair Cockburn
• In a traditional process, learning gets referred to as scope creep or
bad requirements.
• In an Agile process, learning is the purpose.
• Plan on learning from everything you build.
• Plan on being wrong at least half the time.
• Validated learning over working software (or comprehensive
documentation) Kent Beck
• Try using stories to drive the making of anything, whether it’s
software or not.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 33
34. Decompose
• If the story describes a solution that’s too expensive, consider a
different solution that helps you reach the goal.
• If the story describes a solution that’s affordable but big, break it into
smaller parts that allow you to evaluate and see progress sooner.
• Don’t break down big things into big plans. Break big things into small
things with small plans.
• You can deliver “half a baked cake, not a half-baked cake.”
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 34
35. Right-sizing
• A right-sized story from
a business perspective
is one that helps a
business achieve a
business outcome.
• A right-sized story from
a user’s perspective is
one that fulfills a need.
• A right-sized story from
a development team’s
perspective is one that
takes just a few days to
build and test.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 35
36. Conversations are one of the best tools for breaking
down big stories.
User Story Mapping, Discover the Whole Story, Build the Right Product – Jeff Patton
kburns@sagesw.com, @kevinbburns 36
37. Spike Stories
• From the Extreme Programming community
• Effort designed to learn
• Might not result in shippable code
• Should be timeboxed (<20hrs)
• Impacts team capacity
• Most teams don’t put story points on them until they know whether
or not it will become real work intended for release. (they don’t want
to inflate velocity for stuff that might not ship)
kburns@sagesw.com, @kevinbburns 37
38. MVP
Innovation
User
UX, BA, QA, SME
Business
Valuable
Design Usable
Software Engineering
AD, DD, DA
Business Customer
PO, SM, BL
Use scientific method
(measurable) to learn
and discovery your
Minimum Viable
(Valuable) Product
(MVP)
Technically
Feasible
MVP innovations emerge
from Conversations kburns@sagesw.com, @kevinbburns 38
39. INVEST in stories
•Independent – stand-alone
•Negotiable – there is more than one way to implement/solve
•Valuable – useful and ROI
•Estimable – we’re able to size it
•Small – deliverable within a few days
•Testable – can validate when done
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
kburns@sagesw.com, @kevinbburns 39
40. Define SMART story tasks
•Specific – discrete, known
•Measurable – testable, DoD
•Achievable – owner has skills to deliver it
•Relevant – needed to deliver story effectively
•Time-boxed – there is an understanding of duration
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
kburns@sagesw.com, @kevinbburns 40
41. Story writing options
This can work for System as user
• Given a certain precondition situation
• When a certain interaction occurs
• Then the system does this
An example:
• Given my bank account is in credit, and I made no withdrawals recently,
• When I attempt to withdraw an amount less than my card's limit,
• Then the withdrawal should complete without errors or warnings
http://martinfowler.com/bliki/GivenWhenThen.html
kburns@sagesw.com, @kevinbburns 41
42. Story Mapping Exercise Options
• Tasks when you wake-up in the morning
• Flight booking system
• Real scenario from work
kburns@sagesw.com, @kevinbburns 42
Traditional project management is very plan driven.
Agile is about starting with the schedule and cost then determining how much functionality can be delivered in that time for that amount of money.
Who are the companies we think would buy the product?
Who are the types of people inside those companies we think would use the product, and what would they be using it for?