Stories, Backlog & Mapping


Published on

The goal of this presentation is to explore the most efficient way to manage the product backlog, using blitz planning, story maps (walking skeleton) and improving the quality of our stories by focusing on stronger acceptance criteria, as well as using personas. The benefit of having a better way to organize and visualize the product backlog is to improve our ability to conduct release and iteration planning, as well as produce a better product road map. By attending this session you will be better equipped to help your team and product owner work with the product backlog. As a project manager, you will be introduced to simple techniques that will help you better manage your Agile project and improve visibility to all the work.

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Stories, Backlog & Mapping

  1. 1. Stories, Backlog & Mapping
  2. 2. About Dimitri Ponomareff Dimitri Ponomareff ( is a Coach. Whether it's a sports team, software products or entire organizations, Dimitri has that ability to relate and energize people. He is consistently recognized as a very passionate and successful change agent, with an overwhelming capacity to motivate and mobilize teams on their path to continuous improvements. He is a master facilitator, as well as a captivating speaker with consistent, positive feedback regarding his ability to engage an audience. As a certified Coach, Project Manager and Facilitator of "The 7 Habits of Highly Effective People", Dimitri brings a full spectrum of knowledge in his delivery of methodologies. Through teaching by example, he is able to build teams of people who understand where to focus their work to generate the most value. He has coached and provided tailor-made services and training for a multitude of organizations. The short list includes, American Express, Charles Schwab, Bank of America, Morgan Stanley, Best Western, Choice Hotels, JDA Software, LifeLock, First Solar, Infusionsoft and Mayo Clinic. Dimitri enjoys his work, and does everything to ensure he shares his knowledge with others who seek it.
  3. 3. Agile Stories ● Why, What & How ● Work breakdown structure (WBS) ● What is a story? ○ Story form ○ Cards - Conversation - Confirmation ● Story writing workshops ○ Epics and story breakdown ○ INVEST guideline ● Stories vs. Use Cases vs. Requirements ● Product Backlog of stories ● Personas
  4. 4. Why, What & How ● WHY are we doing this? Voice of the stakeholder (Stakeholders) ● WHAT needs to be done? Voice of the user (Product Owner, Subject Matter Expert) ● HOW do we build it? Voice of the developer (Scrum Team)
  5. 5. Alternative to Work Breakdown Structure (WBS) Activity Functionality Analysis Design Coding Testing Feature Feature Feature Module Module Module WBS or traditional projects Functionality Activity Story Story Story Story Analysis Design Coding Feature Breakdown Structure Testing Define the project plan in terms of what will be delivered rather than what work steps will be performed.
  6. 6. What is a User Story? ● User Stories provide a light-weight approach to managing requirements for a system. ● A short statement of function captured on an index card and/or in a tool. ● The details are figured out in future conversations between the team and the product owner or customers. ● This approach facilitates just in time requirements gathering, analysis and design by the following activities: ○ Slicing user stories down in release planning ○ Tasking user stories out in sprint planning ○ Specifying acceptance test criteria for user stories early in development
  7. 7. Story Form As a < role > I can < activity > so that < business value > ● Role - represents who is performing the action. It should be a single person, not a department. It may be a system if that is what is initiating the activity. ● Activity – represents the action to be performed by the system. ● Business Value – represents the value to the business. Why is this story important?
  8. 8. Acceptance Criteria ● like stories it's written in simple language ● define the conditions of success/satisfaction ● provide clear story boundaries ● remove ambiguity by forcing the team to think through how a feature or piece of functionality will work from the user’s perspective ● checklist or template of things to consider for each story ○ list of impacted modules and/or documents ○ specific user tasks, business process or functions ● establish the basis for acceptance testing ○ steps to test the story (given-when-then scenarios) ○ type of testing (manual vs. automated)
  9. 9. The 3 C's 1. Card Written on a card 2. Conversation Details captured in conversations 3. Confirmation Acceptance criteria confirm that the story is Done. Source: XP Magazine 8/30/01, Ron Jeffries As a user, I can login and gain access to the intranet, so that I can collaborate with all the organization. What about expired accounts? Can it remember my login? 1.Expired accounts fail 2. Remember the login, not the password 3. After 3 attempts the account is locked out for 24h (SOX compliance)
  10. 10. Story writing workshops ● define clear roles: facilitator and story writer ● include the entire team and anyone who can express the WHAT aligned to the WHY (subject matter experts, users, customers, etc...) ○ all participants must stay away from the HOW ○ promote open discussion and use open ended questions ● consider using story-boarding technique ○ work around themes/features ○ begin with the end in mind ● write as many stories as possible, plan for 2-4 hours ○ no need for prioritization ○ high level acceptance criteria
  11. 11. Product, Epics & Stories Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Product Epics Stories
  12. 12. Start with Epics and break down into Stories As a frequent flyer, I want to rebook a room I take often As a frequent flyer, I want to book a room using miles As a frequent flyer, I want to request an upgrade As a frequent flyer, I want to check if my upgrade cleared. As a frequent flyer, I want to book a room. As a frequent flyer, I want to check my account. As a frequent flyer, I want to … Frequent flyer
  13. 13. INVEST guideline from Bill Wake I - Independent The user story should be self contained, in a way that there is no inherent dependency on another user story. N - Negotiable User stories, up until they are part of a Sprint, can always be changed and rewritten. V - Valuable A user story must deliver value to the end user. E - Estimable You must always be able to estimate the size of a user story. S - Sized appropriately User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. T - Testable The user story or its related description must provide the necessary information to make test development possible.
  14. 14. Stories vs. Use Cases vs. Requirements Stories Use Cases Requirements Goal generate conversation capture a behavior establish a contract Scope a single activity a process "day in the life" everything Format a single sentence numbered bullets specifications Completeness open for negotiation and refinements locked, changes may impact entire process locked, require scope change and approvals Language simple, comprehensible structured, flows precise, technical
  15. 15. Personas ● modeling techniques to describe your target audience ○ Behavior patterns ○ Goals ○ Skills ○ Attitudes ○ Motivation ○ Environment ● useful when you don’t have easy access to real users ● help to guide your decisions about functionality and design ● be in your user's shoes - think the way that your users would ● ideal for building test script relying
  16. 16. Backlog Management ● Blitz Planning ● Product Road Map ● Story Mapping ○ The Walking Skeleton ○ Release Planning ● Wireframes
  17. 17. Blitz Planning Process/Mechanics ● everyone writes down all the tasks they know of onto index cards and throws them onto a long table ● everyone sorts, adds estimates and notes ● we look for the Walking Skeleton and the First Delivery ● we strategize and restrategize about roadblocks, costs, time, resources, moving the cards around as we go ● some people might see this as an annotated Pert chart, constructed collaboratively with cards Allow 90 minutes - 15 minutes for instructions, 40+ minutes for the assignment, 20 minutes to discuss, and 15 minutes for variations in the program. The key is to see the variations of the project plan grow under your eyes. Blitz Planning is also known as Project Planning Jam Session (as in jazz)
  18. 18. Product road map ● a roadmap is a planned future, laid out in broad strokes ○ proposed product releases, listing high level functionality or release themes, rough target dates ● intentions for the future given what we know and believe today - they are not commitments (disclaimer) ● should be formulated by first understanding the target users, the market, and the underlying technologies ● short development cycles and repeated prioritization of functionality in the product backlog clashes with a long term product map - making a long range roadmap has always been a real challenge in general ● forms an integral part of any product strategy and provide the framework for plan changes and the impact they would have on the product ● a good product roadmap should invariably deliver the right products with the right features at the right time to the right customers
  19. 19. Product road map example...
  20. 20. Product Backlog of stories ● a list of all desired work on the project “The requirements” ● owned, managed and prioritized by the Product Owner ● items estimated by the team ● re-prioritized at the start of each iteration ● ideally expressed such that each item has value to the users or customers of the product
  21. 21. Story Mapping Problem ● You have a backlog full of stories. ● You have a set of prioritized features that need to go out with your next release. ● You are in need of a simple and quick way of viewing dependencies between stories and mapping features and tasks to their corresponding stories. What do story maps do? ● Group related stories together ● Break down stories from a user point of view ● Make visible the workflow or value chain ● Provide a useful context for prioritization ● Help confirm the completeness of your backlog ● Plan releases in complete and valuable slices of functionality
  22. 22. Story Mapping How do you do story mapping? ● Choose user roles for the product ● Figure out what each user does within the product ● Map those user-roles to User Activity, User Task, and User Subtask (Color coordination helps) ● Cluster items that seem similar and create labels for the clusters ● Arrange activities in a swim-lane to visualize workflow ● Meet with stakeholders and spot check the workflow ● On review, make changes ● Identify goals of the release with user-specific stories in mind
  23. 23. Story Mapping ● helps us focus on the big picture and why we are building the product (business value instead of feature details) ● look at product backlog differently ● keep breaking things down as you go down a path of functionality ● organize the backlog into a logical units for development ● elicit the core functionality of a product from a user-centric point of view ● focus on what the customers or users must do in order for the product to be useful (bells and whistles can come later) activity activityactivity task task task task task task task task details details details details details details
  24. 24. The Walking Skeleton The Walking Skeleton is a tiny implementation of the of the system that performs a small end-to-end function. It is missing the flesh of the application functionality. The Backbone The Walking Skeleton necessity time Plan using your backbone!
  25. 25. Release #4 Release #3 Release #2 Release #1 - Walking Skeleton Story Mapping & Release Planning necessity time necessity time
  26. 26. Wireframes ● Remember: the most effective/rich level of communication is 2 people in front of a white board ○ helps the team to communicate better internally and externally ● wireframe capture something in it's simplest form (bare bones) ○ flesh out something - based on the idea of adding flesh to a picture that shows only the bones of a creature Steps for using wireframes 1. we rapidly create wireframes from the basic description of a user story 2. we gather feedback and adjust the wireframes accordingly (no coding yet) 3. the user interface is designed based on the approved wireframe ● various tools can be used for creating wireframes, but keep it simple! ○ Visio, wiki, scanned drawing, etc...
  27. 27. Wireframes (example & pros/cons) PROS ● simple and fast visual format ● generate feedback ● minimize rework / uncover potential gaps ● reduces miscommunication ● illustrates dependencies ● easy review process ● great when associated with workflow diagramming ● uncover usability issues (early) CONS ● may limit the team creativity if they are over-engineered or stylized ● may create false promises about layout or system functionality ● not kept up to date with the story (acceptance criteria) ● should not be created too early ● who is responsible (ideally) to create/manage the wrieframes ● eventually reach a point of diminishing returns
  28. 28. © Torak, Inc. Agile, Kanban & DevOps Coaching Learn more at Learn more at Learn more at
  29. 29. Thank You
  30. 30. Resources and References ● ● ● ● Agile and Iterative Development: A Manager’s Guide by Craig Larman ● Agile Estimating and Planning by Mike Cohn ● Agile Project Management with Scrum by Ken Schwaber ● Agile Retrospectives by Esther Derby and Diana Larsen ● Agile Software Development Ecosystems by Jim Highsmith ● Agile Software Development with Scrum by Ken Schwaber and Mike Beedle ● Scrum and The Enterprise by Ken Schwaber ● User Stories Applied for Agile Software Development by Mike Cohn
  31. 31. This presentation was inspired by the work of many people and we have done our very best to attribute all authors of texts and images, and recognize any copyrights. If you think that anything in this presentation should be changed, added or removed, please contact us.