Creating and Maintaining the Product Backlog Presented by: In partnership with: 1
Josh Fruit Agile Coach & Trainer Davisbase Consulting Background in Development with 6 years IT Management leading cross-functional development teams Led Agile transformations from small teams to large programs over last 5 years Scaled Agile Framework Program Consultant (SPC), Professional Scrum Master (PSM), Certified Scrum Master (CSM) Track the conversation on Twitter @davisbase @ASPE_SDLC #agile 2
Objectives Review what makes up the Product Backlog Explore who creates the Product Backlog and why it is important Discuss User Stories and their importance Examine what a User Story should look like Discuss what to watch out for in the Product Backlog 3
Agile Planning Agile practices embrace continuous planning Always accurate, but with varying levels of precision Just-In-Time approach 4
The Product Roadmap Connecting the Product Vision to our approach Effective tool to provide the team with incentive and focus Not a commitment...only a plan 5
Themes Group similar stories into product themes Product Vision Themes can help with planning: Roadmap Release SECURITY PROD. MGMT CUST. MGMT PAYMENTS ADVERTISING Prioritization 6
Theme Prioritization We will determine priority at multiple levels: Themes, Epics, User Stories Prioritization of Themes may not be linear (you may have themes represented more than once at different points on the roadmap) Can help establish your roadmap 7
Roadmap Examples Jan Feb Mar Apr May Jun Security User Admin Payments Fulfillment Product Admin Q1 Q2 Q3 Security User Admin Fulfillment Product Admin User Admin Payments Security 8
Product Backlog A prioritized list of all user stories that may be delivered New items can be added at any time to the Product Backlog Items are defined, prioritized, sequenced by Product Owner with input from others Team members estimate items in Product Backlog relative to each other using predetermined scale (story points) 9
Product Owner Role Critically important for the success of an Agile project A great product owner should be: Available. To the team. Knowledgeable. About the product. Empowered. To make business decisions. A part of the team, not apart from the team. The business and development team must act as true partners in order to succeed. Copyright 2013 Davisbase Consulting. Licensed for Classroom Use Only. 10
The Agile Team Product Owner Product Vision and Roadmap Manage the Product Backlog Be prepared with details at the appropriate time Set clear expectations for acceptance COMMUNICATE What is needed Team Member Estimate our work Plan and commit for the iteration Execute the iteration Demo the completed features Retrospective COMMUNICATE How do we deliver Copyright 2013 Davisbase Consulting. Licensed for Classroom Use Only. 11
User Roles Why are User Roles important? Unique perspectives change requirements and acceptance criteria Who are your target customers? What do they use the software for? How do they use the software? What are their priorities? 12
User Stories Brief, simple requirement statement from a User perspective Acceptance criteria Documented and visible Ron Jeffries Three C s Card, Conversation, Confirmation 13
User Stories - Examples As an instructor, I want to post my presentation online so that I do not need to send it. As a patient, I want to access test results online, so that I can get them at my convenience without calling my doctor. 14
User Story Agile requirements are written from a customer s perspective, in plain language to minimize the barrier to customer involvement. Understanding the why can be as important as the what. Information gems exist in knowing why our customers want what they ask for. As an instructor, I want to post my presentation online so that I do not need to send it. As a patient, I want to access test results online, so that I can get them at my convenience without calling my doctor. 15
User Story Who What Why As an instructor, I want to post my presentation online so that I do not need to send it. Who What Why As a patient, I want to access test results online, so that I can get them at my convenience without calling my doctor. 16
Why the Why Agile Requirements Traditional Requirements As an instructor, I want to post my presentation online so that I do not need to send it. Ability for user to post a presentation online. As a patient, I want to access test results online, so that I can get them at my convenience without calling my doctor. Enable Patients to have access to test results online. 17
User Stories INVEST acronym (Bill Wake) Independent Negotiable Valuable Estimable Sized appropriately Testable 18
User Stories: INVEST Independent Avoid dependencies with other stories whenever possible Able to deliver as a product increment independently As a patient, I want to access test results online, so that I can get them at my convenience without calling my doctor. As a patient, I want to login to my online account so that I can see my account information securely. 19
User Stories: INVEST As a patient, I want to access test results online, so that I can get them at my convenience without calling my doctor. As a patient, I want to access all past test results online, so that I can get them at my convenience without calling my doctor. Negotiable Stories are NOT a contract Too much detail up front gives the impression that more discussion is not necessary Create foundational stories if necessary 20
User Stories: INVEST Valuable Should show value to: - Users - Customers - Stakeholders Agile teams understand the subjective nature in defining quality 21
User Stories: INVEST Estimable Enough detail to allow the team to estimate Challenges estimating if... Too big Insufficient information Lack of domain knowledge 22
User Stories: INVEST PRODUCT BACKLOG Sized Appropriately Small enough to be completed in a single iteration if possible Small for the near future Larger stories are okay further out (Epics) LOW Prioritization HIGH 0-6 Months * CURRENT RELEASE SCHEDULE 6-12 Months * FUTURE RELEASE SCHEDULE 12 + Months * FUTURE RELEASE SCHEDULE Release schedule timeframes are examples only 23
User Stories: INVEST Testable Acceptance criteria stated in customer terms Automate whenever possible All team members should demand clear acceptance criteria As a retiree, I want to see a summary of my investment accounts on one screen so that I can decide where to focus my attention All investment accounts linked to the user profile Account number, name, total value today displayed 24
What to Watch Out For Mike Cohn s Catalog of Story Smells Stories that are too small Stories too big...too many being split later Interdependent stories Goldplating Too much detail Interface detail too soon Thinking too far ahead Lack of customer participation, writing and prioritizing 25
Non-User Stories Technology foundation stories At times these can be stated in customer terms Dependencies from external teams Creative elements Spikes Other types of stories... defects, maintenance, training, etc. As a developer, I want to upgrade to the latest version of the database software so that we have a supported product Spike: As a developer, I need to investigate a semantic search algorithm to facilitate natural language searching of the person s financial record. 26
Non-User Stories: Constraints Constraints often do not represent user functionality Should be documented and remain visible for team, but does not go into the product backlog Should be stated in measurable terms and be testable As a patient, I want the system to function like the other systems in the suite so that it is familiar and easy to use. As a stakeholder, I want page load times to conform to current standards so that patients will be able to use the system on a dial-up connection. 27
Story Review As the team prepares stories for an iteration, more detailed collaboration is necessary for some stories Level of formalization should be determined by the team Ensure the team is engaged and collaborating 28
Story Review - Methods Whiteboard discussion Use Cases Process flows/diagrams Requirements/Design Documentation - please ensure this is done as a result of collaboration, NOT in place of collaboration Screen Mockups More ideas... 29
Sprint Zero Some teams use a Sprint 0 to prepare their Product Backlog, infrastructure, etc. Keep it as short as possible (1-2 weeks max.) Goals: Get some quality items on the Product Backlog Provide a minimal environment to enable writing and testing of code Make proper, effective planning of Sprint 1 possible 30
Process Overview Mon Tues Wed Thur Fri Sprint Planning Daily Scrum Daily Scrum Daily Scrum Daily Scrum Sprint 1 Daily Scrum Story Review Daily Scrum Daily Scrum Daily Scrum Sprint Review Demo Retrospective Sprint Planning Daily Scrum Daily Scrum Daily Scrum Daily Scrum Sprint 2 Release Plan Daily Scrum Story Review Daily Scrum Daily Scrum Daily Scrum Sprint Review Demo Retrospective 31
Summary Highlights Product Owner role is the content authority for the Product Backlog Development Team including developers and testers gives input to the Product Backlog and determines the how Both Product Owner and Development Team collaborate routinely on shaping, sizing and sequencing user stories in the Product Backlog Product Backlog is dynamic and evolves over time 32
Thank you! STAY CONNECTED www.davisbase.com www.aspe-sdlc.com @davisbase @ASPE_SDLC Now is the time for questions! Remember, any unanswered questions will be captured and responses provided online. 33