Paul and Ian Culling - Introduction to Chartering and Story Mapping
•Download as PPTX, PDF•
1 like•875 views
This document introduces collaborative chartering and storymapping. It discusses determining participants, establishing goals and success measures, mapping the community, and establishing a cadence. It also discusses experiences with storymapping and observations of feature-oriented vs user-centered approaches. Storymapping workshops are proposed to identify key personas, capture activities and tasks, and author stories in a persona-driven way.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (13)
Similar to Paul and Ian Culling - Introduction to Chartering and Story Mapping
Similar to Paul and Ian Culling - Introduction to Chartering and Story Mapping (20)
Recently uploaded
Recently uploaded (20)
Paul and Ian Culling - Introduction to Chartering and Story Mapping
- 1. Collaborative Chartering&Storymapping An Introduction
- 4. What We’re Not Talking About
- 5. What We Are Talking About
- 6. Test Drive Your Project
- 7. The Mechanics Determining who to invite A Name and time frame An Elevator Pitch Goals and Success Measures Mapping the Community Strengths & Challenges Establishing a cadence
- 8. Who’s Coming to the Party Skills and Experience Over Titles and Org. charts
- 9. Who’s Coming to the Party Think about: Investors or sponsors? Product or Project Vision? Domain Expertise? Market opportunity and needs knowledge? Builders of the product? Packaging and deployment? Document and provide training? This is just a guide…
- 10. A Name & Time Frame What’s in a name? The not too distant future
- 11. A Name & Time Frame
- 13. AgileSherpa A gentle guide to the best of the Agile landscape wherever it lives.
- 14. Roadmapping Capture and visually communicate the longer-term direction of our products.
- 15. DINERO ‘Get my reps out of invoicing’ –automagic invoicing and online payments.
- 16. Goals & Success Measures
- 18. How will this project improve the product?
- 19. What value are we creating for the users?
- 20. Are there technology goals? Are we paying down technical debt?
- 21. What are the Social (community) goals?
- 25. Our Experiences
- 29. Our Experiences
- 30. Storymapping
- 31. Agile Product Planning - Observations Feature-oriented vs. user-centered Process-driven (template-head) Sentence completion over storytelling Mad dash to iterate – crank out a backlog! Delivery quickly outpaces Discovery
- 32. A Process and a Template As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ As ____ I need to ____ so that ____ “As _______ I need to _________ so that I can _________” user story value
- 33. An Evolution Persona Story Title Story Title Story Title “As _______ I need to _________ so that I can _________” Image - Story Test - Story Test - Story Test persona user task test Desc - Story Test - Story Test - Story Test Value - Story Test - Story Test - Story Test - Story Test - Story Test - Story Test A Refactoring
- 34. Story Map sneak peek… Persona Activity Task Task Task Task Task Task Activity Task Task Task Task Task Task Task
- 35. Story Map Workshop Identify & Rank Key Personas Those that are doing it, find it valuable or will support it Who gets the most value, or is most important to serve? Capture Key Activities & User Tasks “What do you do at work?” Activities “Tell me that story” Tasks “Are there any variations?” Alternate paths Mile-wide, Inch-deep
- 36. Participants Informed: end users & domain experts Inspired: product visionaries/sponsors Decision Makers: product owners Builders (design – dev – test) Fewer is Better
- 37. Pragmatic Personas, vs… Ca < our goal is to create discussion starters >
- 41. knowledge of domain - increased productivity?
- 42. FT / PT - fewer steps?
- 43. incentives - more fun?- level of engagement - easier to use?
- 44. Story Maps ( what’s needed; what’s wanted? )
- 47. An Example
- 48. Let’s Map the Point of Sale Make Sales Add Item Calc Total Take Payment Print Receipt Calc Tax Scan Item Open / Close Register Print GiftRcpt Key In Item Take Cash Take Returns Take Credit Add Survey Take Coupon Take Check
- 49. Story Maps Foster Story Telling(and re-telling/reminding/reorienting)
- 50. When is value delivered? Activity Task Task Task Task Task Task Task Task Activity Task Task Task Task Task Task Task Task Task Task
- 51. Benefits User-Centered mindset A governor on feature invention & cleverness (yours truly included) Empathy Context Collaborative Lightweight
- 52. Our Experiences
- 58. Our Experiences
- 59. Special thanks toDavid Hussman www.DevJam.com David.Hussman@DevJam.com t: @davidhussman Watch for his new book from Pragmatic Programmers
- 60. Resources www.DevJam.com (David Hussman) www.AgileProductDesign.com (Jeff Patton) TBD Title, David Hussman www.PragProg.com (beta soon)
- 61. Paul Culling Paul.Culling@VersionOne.com Ian Culling Ian.Culling@VersionOne.com www.VersionOne.com
Editor's Notes
- Not traditional kick off meeting: 1 way discussion (talked to) where you’re told what will be built, by whom and by when.Not massive document that is often never read, created by few without feedback from the larger project community
- Not about shelfware, it’s about big visible PURPOSE. The WHY.collaborative (lightweight0) chartering involves the appropriate members of the project community and the appropriate level of ceremony. Collaborative chartering aims to create a session filled with discussion from all points of view.describe what project community meanstalking about test driving your project
- The project community (builders to customers to Trackers – more on that later) uses chartering to look at what success might look like who is in the mix (builder/customer/trackers), what they are building and why. smooth sailing, can uncover how much is not known or what is unclear. End with a project community that is bought in and committed to the project and it can end with the realization that a project should be killed before it startsBRING UP IMAGEfrom a real project, posted on a wall in the project areathe messy nature promotes revisiting. It’s not sterilized document people are afraid to mess withProject team can go to it, if things are changing or the project is losing its way, it may be time to update or do another chartering session NOT buried in desk after the ‘chartering’ toll gate has been passed
- appropriate ceremony, appropriate time on each ‘section’inspect and adapt and the perils of dogma
- exploratory, informative and rich discussion
- Less is more – too big a group and discussion is stifled, looking for free flowing discussionBeware the dominator and be prepared to facilitate around them if there is one in your community
- Brief intro – foundationhave a name? It should. This is a LOW CEREMONY activity. May come quickly, may take longer – if problem, bad smell.======TIME FRAME======== “What is a meaningful time frame for our charter?” Too far into the future - you can’t realistically determine what success means – goals are untestable Too short a period – are you introducing unneeded process or ceremony? Depends on your company, industry or domain: If you release quarterly then maybe that is a good time frame. Longer time frames can give valuable insight into long term roadmaps but shorter time frames give more actionable AND testable goals
- Everything I just talked about is displayed in this small space doesn’t seem like much information but brings great clarity to the foundation of the project you can also see, ironically, that this was their scrum pilot
- explain elevator pitch some also call it a vision statement, like this team, but I’m personally not fond of that name. to me it lends itself to being buzzwordy, meaningless feces that a bad marketing team would come up with what we’re looking for is 1 or 2 sentences that actually means something to the project community as a whole – if somebody asked about the project you could rattle it off and they would understand what you’re up to Can you describe what you are building and why it is valuable? takes time – don’t go for unrealistic – come back to it later when more info is in the open – does it still fit?
- what future success might look like may be product, technology, process or something elsenot wish lists, must be testable and tangible within time frame if 1 person talking, either true product owner or just a control freak try to get more than one person talking ask silent people to offer their ideas don’t try to organize just yet, it can kill momentum10 or so visible goals =====STARTER QUESTIONS===== suggest this order: business or product, move on to technology and then new process being introduced (like scrum in this project)SUCCESS MEASURES – Now the harder work – trying to figure our what success might look like within time framescalability example: how much now? Users or ?? Way to measure scalability?not creating detailed requirements – discovery around what is known and unknown Iterate, cycle back, rewrite unclear goals
- Discussing names, dates and elevator pitch just the beginning Elevator pitch should have got the group going, discussing, thinking next work item around what future success might look like may be product, technology, process or something else not wish lists, must be testable and tangible within time frame if 1 person talking, either true product owner or just a control freak try to get more than one person talking ask silent people to offer their ideas don’t try to organize just yet, it can kill momentum 10 or so visible goals STARTER QUESTIONS suggest this order: business or product, move on to technology and then new process being introduced (like scrum in this project)SUCCESS MEASURES – Now the harder work – trying to figure our what success might look like within time frame scalability example: how much now? Users or ?? Way to measure scalability? not creating detailed requirements – discovery around what is known and unknown Iterate, cycle back, rewrite unclear goals
- Getting to know players and relationship to each other do this by building a map of community and extended community two types one is more traditional and one is notWhat do you do and When will we see you? Name, skills (tasks) and time available as people to provide in their own wordsnot “role” unless it describes what they do (how people see their work in their words, not their manager’s) will BA or PM really tell you (and community) what they do day-to-day? asking people to take ownership of what they do in the community builds communities instead of just teaching processes and practices VENN GOES SOCIAL – shows some skills but mostly relationshipsBuilders, Investors or Trackers, Product Planners and DesignersIf they build it they will come (product planners)Are we there yet? (trackers) Everyone who makes the product clickable (builders)Who is needed but not present? Discussions started are more valuable than the picture created
- This is where we look at what is going for us and what is going against us Strengths come in many forms: technical skills, history of delivery, strong sponsorship deep domain knowledge or subject matter expertise Challenges and constraints need open discussion which constraints can be changed and which are out of the control? Also where you would discuss community values: quality? Empathy? Trust? This is can affect the elevator statement and cause to revisitRoadblocks? Working agreements?
- Complete charter by discussing cadence: who, where, and how often people will meet including:iteration lengthPlanning days and timesstand up time and location core hourscollaboration hoursestablish and record key dates
- Personas (15 – 30 minutes)Come up with 3 or 4 provisional personas that will get value from or depend on the product. Consider people:that find it valuablethat are doing itthat will support itFor each persona, complete an index card (simply format in the slide deck) that includes a:Name (sticky name – alliteration helps)Sketched out headshot (a conversation starter)Bullets that describe that person (who is this person?)Bullets that highlight the values (what are our selling points to this person?) Rank Personas (5 minutes)Who’s most important to serve? Who gets the most value? Storymapping: Activities and User Tasks (1 hour max; ~15 minutes/persona)Through repetitive storytelling, for each persona (in rank order):Name 4 or 5 (max) high-level activities (“what do you do at work?”) à activitiesWalk a day in the life for each activity (“tell me that story”) à user tasksBack up and re-tell the experience (“are there any variations”) à alternate paths/tasksAs they’re captured, lay them out on the table next to the persona they’re about (I’ve attached a very simply visual of the layout)Going mile-wide, inch deep: don’t go more that 3 levels deep in variations