• Save
Product Backlog Mapping
Upcoming SlideShare
Loading in...5
×
 

Product Backlog Mapping

on

  • 695 views

Learn to use the user story backlog as a way to describe user’s experience with your product. ...

Learn to use the user story backlog as a way to describe user’s experience with your product.
Section 1: Importance of Product Owners Roll.
 Identifying Scrum’s Product Owners roll.
 Diagrammatic representation of PO Activities.
 Diagrammatic representation of Product Feature Development tracks.
Section 2: User stories & Product Backlog Management.
 Agile User Stories overview .
 Acceptance Criteria.
 Backlog Management.
Section 3: Project Scope, Product Backlog and Story Mapping.
 User Story Mapping Steps.
 Story Mapping example with valuable releases.
 Benefits of User Story Mapping.

Statistics

Views

Total Views
695
Views on SlideShare
695
Embed Views
0

Actions

Likes
3
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Product Backlog Mapping Product Backlog Mapping Presentation Transcript

  • B Y : N . P A U L T I T L E : P R O J E C T M A N A G E R Product Backlog mapping 1
  • Goals and Agenda: Goal: Learn to use the user story backlog as a way to describe user’s experience with your product. Section 1: Importance of Product Owners Roll.  Identifying Scrum’s Product Owners roll.  Diagrammatic representation of PO Activities.  Diagrammatic representation of Product Feature Development tracks. Section 2: User stories & Product Backlog Management.  Agile User Stories overview .  Acceptance Criteria.  Backlog Management. Section 3: Project Scope, Product Backlog and Story Mapping.  User Story Mapping Steps.  Story Mapping example with valuable releases.  Benefits of User Story Mapping. 2
  • Scrum’s Product Owner Role : The Product Owner role is generally filled by a single person supported by a collaborative team, Subject Matter Expert  Understand the domain well enough to envision a product .  Answer technical questions on the domain for those creating the product. End User Advocate  Describe the product with understanding of users and use, and a product that best serves both. Customer Advocate  Understand the needs of the business buying the product and select a mix of features valuable to the customer. Business Advocate  Understand the needs of the organization paying for the software’s construction and select a mix of features that serve their goals. Communicator  Capable of communicating vision and intent – deferring detailed feature and design decisions to be made just in time. Decision Maker  Given a variety of conflicting goals and opinions, be the final decision maker for hard product decisions. Section 1 333
  • :- Communicate Business Goals, Customer Goals, End User Goals. :- Coordinate involvement of SMEs, users, and business stakeholders. :- Coordinate with other product owners to insure product releases. Organize the backlog into incremental releases Specify objective acceptance criteria for stories Create and maintain the product backlog Participate daily Available to answer questions and clarifications Verify stories are done based on acceptance criteria Evaluate product at end of Sprint and add or remove stories from backlog as necessary Section 1 4
  • Product Feature Development tracksProduct OwnerTeam Development Team Implement iteration 1 features • Gather user input for iteration 3 features. • Design iteration 2 features. • Support iteration 1 development. implement iteration 2 features, fix iteration 1 bugs if any • gather user input for iteration 4 features. • design iteration 3 features. • support iteration 2 development. • validate iteration 1 features. implement iteration 3 features, fix iteration 2 bugs if any • gather user input for iteration 5 features. • design iteration 4 features. • support iteration 3 development. • validate iteration 2 features. • Planning. • Gather user input for iteration2. • Design for iteration 1 features – high technical requirements, low user requirements. • Development environment setup. • Architectural roadmap design. Sprint 0 Sprint 1 Sprint 2 Sprint 3 time supportdev supportdev Section 1 5
  • User stories & Product Backlog Management Agile User Stories:  Why, What & How.  What is a story? ○ Story form. ○ Cards - Conversation – Confirmation. ○ Acceptance Criteria. Product Backlog Management:  Blitz Planning.  Product Road Map.  Project scope, product backlog & Story Mapping.  User Story Mapping Steps with example.  Benefits of User Story Mapping Section 2 6
  • Agile User Stories Overview: 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) 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: o Slicing user stories down in release planning. o Tasking user stories out in sprint planning. o Specifying acceptance test criteria for user stories early in development. Section 2 7
  • Agile User Stories Overview: 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? The 3 C’s  Card – Write on an Index Card.  Conversation – Details captured from conversations  Confirmation – Acceptance criteria confirm that the story is Done. 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. Fail Expired accounts. 2. Remember the login, not the Password. 3. After 3 attempts the account is locked out for 24 hours (SOX compliance) Section 2 8
  • Acceptance Criteria:  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 - 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) Section 2 9
  • Backlog Management:  Blitz Planning  Product Road Map  Project Scope, Product Backlog and Story Mapping with example.  Benefits of user story mapping. Section 2 10
  • 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.  Look for the Walking Skeleton and the First Delivery.  Strategize and re-strategize 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 logic behind 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) Section 2 11
  • Product Road Map:  A roadmap is a planned future, laid out in broad strokes.  proposed product releases, listing high level functionality or release themes with high level target dates.  Given Intentions for the future about what we know and believe today - they are not commitments.  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 – in general making a long range roadmap has always been a challenge.  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. Section 2 12
  • Project Scope, Product Backlog and Story Mapping • Project Scope: Can be expressed as “scope and vision statement”, “operational concept”, “statement of work” (SOW). OR, As a Work breakdown structure (WBS)/ Product breakdown structure (PBS) or a Product backlog. In general – WBS expresses the SOW as activities – PBS/Backlog expresses SOW as features. • Product Backlog: A typical Scrum backlog comprises different types of items like Features, Bugs, Technical work, Knowledge acquisition etc. Because there's really no difference between a bug and a new feature, each describes something different that a user wants, bugs are also put on the Scrum product backlog. • Story Mapping: Building or arranging user stories into a helpful shape which is more useful can be treated as User Story Map. Section 3 13
  • User Story Mapping Steps Step1: Place activities – big user stories (UX), Epics (Mike Cohn) – at the top.  An activity is something people do –  Has lots of steps, and  Doesn't always have a precise workflow.  E.g. Building an email system.  Managing email.  Configuring email servers.  Setting up out of office responses.  Activities provide the context. Step2: Break activities down into user tasks i.e. smaller stories  E.g. Read Message, Send Message, Delete Message etc.  A user task is something that someone does to reach a goal. Step3: Move from left to right and top to bottom. Section 3 14
  • User Story Mapping Steps Step4: Arrange stories in the logical order in which they would be completed – grid form. Step5: Test your map.  Discussion / walk it through.  Analyzing and finding things we have missed. Step6: Annotate it. Step7: Use different color for different levels. Step8: Display it as a information radiator.  Use for sprint or iteration planning.  Mark of progress. Section 3 15
  • E.g. Building an email system Section 3 User Activities / Backbone / Epics Tasks / Walking Skeleton User Stories / Sub-tasks Sprint 0 Sprint 1 Sprint 2 Sprint 3 16
  • Benefits of User Story Mapping  Allows you to see the big picture in your backlog.  Provides a better tool for making decisions about grooming and prioritizing the backlog.  Promotes silent brainstorming and a collaborative approach to generating user stories.  Encourages an iterative development approach where early deliveries validate your architecture and solution.  Is a great visual alternative to traditional project plans.  Is a useful model for discussing and managing scope.  Allows you to visualize dimensional planning and real options for your project/product. Section 3 17
  • QA Session and References. 18  Official Scrum References:  http://www.scrumalliance.org/  http://www.scrum.org/  http://scrumsource.com/blog/  http://agileproductdesign.com/  Next Session:  Will be declared as soon as possible.