Feature-Set (a.k.a. Product Backlog) Management in Scrum Instructor: Mike O’Dell

The Product Backlog A prioritized list of desired product functionality A highly visible artifact at the heart of the Scrum framework and process A tool for communicating with your Product Owner/Product Sponsor/end-user comunity A critical input to the Sprint Planning process

Product Backlog Items (PBIs) Features, functions that have tangible value to the customer/end-user Changes/enhancements to an existing or previously implemented feature or function Defects that need to be fixed Technical improvements to the product Knowledge acquisition work associated with the product Anything else the Product Owner deems valuable

Product Backlog Items (PBIs) PBI Type Example Feature/Function As a customer service representative I want to create tickets for customer issues so I can manage their support requests. Change/ Enhancement As a customer service representative I want my default ticket display to be by last name instead of ticket number so I can more easily find a specific customer’s service tickets. Defect Fix defect #256 in the defect tracking system so that special characters in a customer name do not make customer searches crash. Technical Improvement Move service ticket tracking data to the latest version of the Oracle DBMS. Knowledge Acquisition Create a prototype or proof of concept for the two proposed navigation models for the ticket tracking system and run tests to determine which is the most efficient. Product Owner Additional Prepare a mock-up of the proposed service ticket tracking GUI to be used for marketing research sessions with top-tier national customers. Some examples from Essential Scrum, Kenneth S. Rubin

Product Backlog Characteristics DEEP Detailed appropriately: PBIs near the top (in priority) that we intend to work on soonest should be very detailed and small. Those near the bottom can remain as epics until the move up. Emergent: It is never frozen. Instead, it is continuously updated based on new information. Estimated: Each PBI has a size (effort) estimate. Those near the top should be most accurate and small enough to be completed in “a few days.” Prioritized: Especially important to have accurate prioritization for next few Sprints.

Product Backlog Characteristics DEEP: Detailed appropriately. Source: Essential Scrum, Kenneth S. Rubin

Product Backlog Grooming Consists of three primary activities: Creating and refining (adding details to) PBIs Estimating PBIs Prioritizing/reprioritizing PBIs Employs DEEP Is an ongoing, collaborative effort, involving Product Owner Development team (everyone) Internal and external stakeholders Other subject matter experts, partners

Product Backlog Grooming Story Abstraction Hierarchy Source: Essential Scrum, Kenneth S. Rubin

Estimation, Capacity, Velocity Estimation is the process of determining the effort required to complete (100% DONE!) each PBI on the Product Backlog Capacity is the effort available from the team to complete PBIs during the Sprint Velocity is the amount of work completed during a Sprint

Estimation Estimation is required for the entire Product Backlog (Release Planning) and for each Sprint (Sprint Planning) Items higher in priority, or required earlier, need most accurate estimates (and smaller PBIs) Items lower in priority/later require less accuracy Must be done at the beginning of the Project then refined at the beginning of each Sprint Must be done by the whole team, using a common baseline Use an approach that works best for your team, product

Estimation - When Source: Essential Scrum, Kenneth S. Rubin

Estimation - How Critical Rules and Concepts: Estimate AS A TEAM Estimates are not commitments Focus on accuracy, not precision Use relative instead of absolute sizes Source: Essential Scrum, Kenneth S. Rubin

Relative sizes or adjective calibration Estimation - How Use the approach that works best for your team Estimation Poker Relative sizes or adjective calibration Betting Analogy Buckets or Bins Source: Essential Scrum, Kenneth S. Rubin

Capacity for work on PBIs during this Sprint Capacity is used to determine what can (will) get done during each Sprint. Team capacity for the Sprint >= the sum of estimated size of PBIs to be completed in the Sprint Use the same units/metrics/sizings as for estimation Consider actual effort available for work on PBIs Other Sprint Activities Other Non-Sprint Commitments Personal Time Sprint Buffer Capacity for work on PBIs during this Sprint Total work capacity during Sprint

Velocity Adds the size of all PBIs completed during a Sprint Only count PBIs that are complete (100% DONE) Measures output, not effort, outcome or benefit Why measure velocity? Scrum Planning: (estimated size of release) ÷ (measured velocity) = (number of Sprints required to complete release) Sprint Planning: (velocity per Sprint) >= (size estimate for PBIs in Sprint Metric: evaluate the team’s performance vs. processes/procedures and determine ways to optimize performance

Velocity Source: Essential Scrum, Kenneth S. Rubin

Velocity Product Backlog Item “Story Points” Sprint Review Results 2 Accepted1 3 1 Accepted 5 4 8 Rejected 9 Sprint Velocity 10 1 100% Done Source: Essential Scrum, Kenneth S. Rubin

Velocity Source: Essential Scrum, Kenneth S. Rubin

Estimated Size, Velocity, Duration (or capacity) Source: Essential Scrum, Kenneth S. Rubin

Product Backlog Management FACT: Ongoing Product Backlog grooming and sequential, iterative development in Scrum can lead to excessive change. Agile (Scrum) addresses change in a economically feasible way… Change is more expensive late than early on. Excessive elimination of change early (as in classic “plan-driven” processes such as Waterfall) contributes to necessary late change In Scrum, change is the norm, embrace it GOAL: keep the cost of change curve flat as long as possible by accepting and adapting to necessary change.

Product Backlog Management Scrum Traditional, Plan-Driven Cost of Change Late change = higher costs Early attempt to eliminate change = wasted effort Small, incremental changes = Small, incremental costs Time

Sources of Change End-users: driven by the “need” for additional or different functionality, or unclear/impossible goals Marketers: driven by the fact that markets and customer perspectives on requirements change (“killer-app” or “latest and greatest” syndromes) Developers: driven by emotional/ intellectual desire to build the “best” widget

When Change is Necessary Customers don’t know what they want You need to be responsive to the customer The market is changing rapidly You want to give latitude (flexibility) to the developers

Late Project Feature Cuts Goal: Eliminate features in an effort to meet the project’s schedule/budget goal Fact: Project may (will?) fall behind for many reasons, so this may be necessary Fact: Removing features too late incurs additional costs and schedule impact Approach: analyze the cost of removal and reusability, then strip out unused code, remove documentation, eliminate test cases, etc.