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

2. 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

3. 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

4. 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

5. 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.

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

7. 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

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

9. 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

10. 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

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

12. 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

13. 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

14. 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

15. 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

16. Velocity
Source: Essential Scrum, Kenneth S. Rubin

17. 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

18. Velocity
Source: Essential Scrum, Kenneth S. Rubin

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

20. 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.

21. 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

22. 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

23. 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

24. 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.