Contents
Chapter 1 Continuously Improving Your Scrum Practice
Focus on Seven Key Areas to Improve Your Scrum Practice
Empiricism Is at the Heart of Scrum
Mastering Scrum Means Improving Teamwork
Every Scrum Team Must Focus on Improving the Value That Its Product Delivers
Every Strong Team Has a Distinct Team Identity
To Improve, Teams Must Hone Their Team Processes
The Organization Can Greatly Influence the Team’s Performance
Growing Scrum Requires a Team to Improve Other Capabilities
A Process for Continuous Improvement
Experiment with Different Approaches
Chapter 2 Creating a Strong Team Foundation
What Makes a Good Team Member?
Who Should Be on a Scrum Team?
Development Teams Need to Know About More Than Just Development
How Do Scrum Teams Form Working Agreements?
What Does Self-Organization Look Like?
How Do Scrum Teams Collaborate?
Characteristics of Productive and Adaptable Teams
Chapter 3 Delivering “Done” Product Increments
What Is a Definition of “Done”?
Benefits of a Definition of “Done”
How to Create a Definition of “Done”
Using Sprint Goals to Get to “Done”
Using the Sprint Goal for an Effective Daily Scrum
Getting PBIs to “Done” Earlier in the Sprint
Limiting Work Items in Progress
Building in Quality from the Beginning
Making Technical Debt Transparent
Making Technical Debt “Repayment” Visible
Chapter 4 Improving Value Delivered
Delivering Faster Is a Good Start, But Not Enough
Product Value and the Scrum Team
Using the Product Vision to Enliven Team Purpose, Focus, and Identity
Focusing PBIs on User Outcomes
Improving Value Delivered During the Sprint
Inspecting and Adapting Based on Feedback
Effective Sprint Reviews Include Value Realized
Gathering Stakeholder Feedback
Planning with a Product Mindset
Minimum Viable Product Backlog Refinement
Breaking PBIs Down to Focus on Valuable Outcomes
How Much Can You Get “Done” in a Sprint?
How Much Time Should You Spend on Improving This Sprint?
How Large Should a Release Be?
Chapter 6 Helping Scrum Teams Develop and Improve
Using the Sprint Retrospective to Uncover Areas for Improvement
Identifying and Removing Impediments
Tracking Impediments and Quantifying Impacts
Growing Individual and Team Capabilities
Make Time for Continuous Learning and Growth
Leverage Knowledge and Experience in the Organization
Being an Accountable Scrum Master
Measuring the Success of a Scrum Master
Effective Scrum Masters Vary Their Approach Based on Context
Chapter 7 Leveraging the Organization to Improve
Organizations Need to Evolve to Succeed
The Impacts of Performance Reviews and Compensation
Sourcing Strategies and Team Impacts
Getting Comfortable with Transparency
A Culture of Accountability, Not a Culture of Blame
Letting Go of (the Illusion of) Control
The Real Power of the Iron Triangle
Iterative and Incremental Budgeting
Chapter 8 Conclusion and What’s Next
Business Agility Requires Emergent Solutions
Appendix A A Self-Assessment for Understanding Where You Are
Effective Empiricism with Scrum
Analysis of Assessment Answers
Appendix B Common Misconceptions About Scrum
Scrum Is Not a Methodology or a Governance Process
Scrum Is Not a “Silver Bullet” or a Way to Get Developers to Work Faster
The Product Owner’s Main Focus Is Not Documentation of Requirements
The Product Backlog Is Not an Agile Version of a Traditional Requirements Document
The Product Backlog Is Not a List of All Requests
The Daily Scrum Is Not a Status Meeting
A Sprint Can Be Successful Even When All Planned Sprint Backlog Items Are Not Completed
The Scrum Master Is Not Responsible for Tracking the Development Team’s Work
The Sprint Review Is Not an Acceptance Meeting