Contents
Scrum Activities and Artifacts
Employ Iterative and Incremental Development
Leverage Variability through Inspection, Adaptation, and Transparency
Reduce All Forms of Uncertainty Simultaneously
Accept That You Can’t Get It Right Up Front
Favor an Adaptive, Exploratory Approach
Embrace Change in an Economically Sensible Way
Balance Predictive Up-Front Work with Adaptive Just-in-Time Work
Validate Important Assumptions Fast
Leverage Multiple Concurrent Learning Loops
Organize Workflow for Fast Feedback
Use Economically Sensible Batch Sizes
Recognize Inventory and Manage It for Good Flow
Focus on Idle Work, Not Idle Workers
Adapt to Real-Time Information and Replan
Measure Progress by Validating Working Assets
Focus on Value-Centric Delivery
Employ Minimally Sufficient Ceremony
Avoids Unnecessary Perfectionism
What Is the Definition of Done?
Definition of Done Can Evolve Over Time
Definition of Done versus Acceptance Criteria
Chapter 5 Requirements and User Stories
Good Product Backlog Characteristics
When Does Grooming Take Place?
Which and How Many Product Backlogs?
Large Products—Hierarchical Backlogs
Multiple Teams—One Product Backlog
Chapter 7 Estimation and Velocity
Portfolio Backlog Item Estimates
Consequences of Technical Debt
Rising Development and Support Costs
Decreased Customer Satisfaction
Attempting to Falsely Accelerate Velocity
Myth: Less Testing Can Accelerate Velocity
Technical Debt Must Be Managed
Managing the Accrual of Technical Debt
Use a Strong Definition of Done
Properly Understand Technical Debt Economics
Make Technical Debt Visible at the Business Level
Make Technical Debt Visible at the Technical Level
Not All Technical Debt Should Be Repaid
Apply the Boy Scout Rule (Service Debt When You Happen Upon It)
Repay Technical Debt Incrementally
Repay the High-Interest Technical Debt First
Repay Technical Debt While Performing Customer-Valuable Work
Define Acceptance Criteria and Verify That They Are Met
Collaborate with the Development Team
Collaborate with the Stakeholders
Who Should Be a Product Owner?
Outsourced Development Project
Product Owner Combined with Other Roles
Is ScrumMaster a Full-Time Job?
ScrumMaster Combined with Other Roles
Inspect and Adapt the Product and Process
Cross-Functionally Diverse and Sufficient
Chapter 12 Scrum Team Structures
Feature Teams versus Component Teams
Provide a Clear Elevating Goal
Provide Functional-Area Leadership
Aligning and Adapting the Environment
Remove Organizational Impediments
Project Management Responsibilities on a Scrum Team
Retaining a Separate Project Manager Role
Chapter 14 Scrum Planning Principles
Don’t Assume We Can Get the Plans Right Up Front
Up-Front Planning Should Be Helpful without Being Excessive
Keep Planning Options Open Until the Last Responsible Moment
Focus More on Adapting and Replanning Than on Conforming to a Plan
Correctly Manage the Planning Inventory
Favor Smaller and More Frequent Releases
Plan to Learn Fast and Pivot When Necessary
Chapter 15 Multilevel Planning
Product Planning (Envisioning)
Optimize for Lifecycle Profits
Estimate for Accuracy, Not Precision
Balance the Arrival Rate with the Departure Rate
Quickly Embrace Emergent Opportunities
Plan for Smaller, More Frequent Releases
Focus on Idle Work, Not Idle Workers
Chapter 17 Envisioning (Product Planning)
High-Level Product Backlog Creation
Economically Sensible Envisioning
Target a Realistic Confidence Threshold
Use Incremental/Provisional Funding
Learn Fast and Pivot (aka Fail Fast)
Chapter 18 Release Planning (Longer-Term Planning)
Refine Minimum Releasable Features (MRFs)
Communicating Progress on a Fixed-Scope Release
Communicating Progress on a Fixed-Date Release
Selecting Product Backlog Items
Task Performance—Technical Practices
Confirm That the Sprint Work Is Done
Chapter 22 Sprint Retrospective
Define the Retrospective Focus