Book Notes #21: Essential Scrum: A Practical Guide - Kenneth S. Rubin

William Meller - Essential Scrum - A Practical Guide
Essential Scrum is the complete guide and reference to use Scrum to develop innovative products and services that delight your customers.


Title: Essential Scrum: A Practical Guide to the Most Popular Agile Process
Author: Kenneth S. Rubin
Themes: Agile, Career, Cases, Technology, Management, Business
Year: 2012
Publisher: Addison-Wesley
ISBN: 0321700376, 9780321700377
Pages: 504

Whether you are new to Scrum or years into your use, this book will introduce, clarify, and deepen your Scrum knowledge at the team, product, and portfolio levels. 

Drawing from Rubin’s experience helping hundreds of organizations succeed with Scrum, this book provides easy-to-digest descriptions enhanced by more than two hundred illustrations based on an entirely new visual icon language for describing Scrum’s roles, artifacts, and activities.

Essential Scrum will provide every team member, manager, and executive with a common understanding of Scrum, a shared vocabulary they can use in applying it, and practical knowledge for deriving maximum value from it.

A very helpful aspect of the book is the detailed "visual language," Kenny created while writing the book. He created icons for every possible aspect of Scrum and these are used to make up dozens and dozens of figures to illustrate all the work and knowledge flows of a Scrum project. 

His diagrams definitely go well beyond the typical double-loop depiction of Scrum.

William Meller - Essential Scrum: A Practical Guide - Kenneth S. Rubin

This book offers a bypass to many of the pitfalls and will accelerate a team’s ability to produce business value and become successful with Scrum. 

My Book Highlights:

"... Plan-driven development works well if you are applying it to problems that are well-defined, predictable, and unlikely to undergo any significant change..."

"... The product owner is responsible for what will be developed and in what order. The ScrumMaster is responsible for guiding the team in creating and following its own process based on the broader Scrum framework. The development team is responsible for determining how to deliver what the product owner has asked for..."

"... Grooming refers to a set of three principal activities: creating and refining (adding details to) PBIs, estimating PBIs, and prioritizing PBIs..."

"... A product backlog item can be considered done only when both the item-specific acceptance criteria (for example, “works with all of the credit cards”) and the sprint-level definition-of-done (for example, “live on the production server”) items have been met..."

"... In product development, however, the goal is to create a unique single instance of the product, not to manufacture the product..."

"... Whereas the sprint review is a time to inspect and adapt the product, the sprint retrospective is an opportunity to inspect and adapt the process..."

"... As a general rule, the development team should allocate up to 10% of its time each sprint to assisting the product owner with grooming activities..."

"... The fact is, when developing innovative products, you can’t create complete requirements or designs upfront by simply working longer and harder. Some requirements and designs will always emerge once product development is underway; no amount of comprehensive up-front work will prevent that..."

"... Scrum is a refreshingly simple, people-centric framework based on the values of honesty, openness, courage, respect, focus, trust, empowerment, and collaboration..."

"... Each day during sprint execution, the team members help manage the flow of work by conducting a synchronization, inspection, and adaptive planning activity known as the daily scrum..."

"... Scrum embraces the fact that in product development, some level of variability is required in order to build something new..."

"... Scrum can be used for new product development and Kanban for interrupt-driven support and maintenance..."

"... Iterative development acknowledges that we will probably get things wrong before we get them right and that we will do things poorly before we do them well..."

"... Incremental development is based on the age-old principle of “Build some of it before you build all of it..."

"... With an agile approach, you begin by creating a product backlog — a prioritized list of the features and other capabilities needed to develop a successful product. Guided by the product backlog, you always work on the most important or highest-priority items first. When you run out of resources (such as time), any work that didn’t get completed will be of lower priority than the completed work..."

"... The work itself is performed in short, timeboxed iterations, which usually range from a week to a calendar month in length. During each iteration, a self-organizing, cross-functional team does all of the work — such as designing, building, and testing — required to produce complete, working features that could be put into production..."

"... Typically the amount of work in the product backlog is much greater than can be completed by a team in one short-duration iteration. So, at the start of each iteration, the team plans which high-priority subset of the product backlog to create in the upcoming iteration..."

"... At the end of the iteration, the team reviews the complete features with the stakeholders to get their feedback. Based on the feedback, the product owner and team can alter both what they plan to work on next and how the team plans to do the work..."

"... At the end of each iteration, the team should have a potentially shippable product (or increment of the product), one that can be released if appropriate..."

"... Though Scrum is an excellent solution for many situations, it is not the proper solution in all circumstances. The Cynefin framework (Snowden and Boone 2007) is a sense-making framework that helps us understand the situation in which we have to operate and decide on a situation-appropriate approach..."

"... Scrum is not a silver bullet or a magic cure. Scrum can, however, enable you to embrace the changes that accompany all complex product development efforts..."

"... Although the Scrum framework is simple, it would be a mistake to assume that Scrum is easy and painless to apply. Scrum doesn’t prescriptively answer your process questions; instead, it empowers teams to ask and answer their own great questions. Scrum doesn’t give individuals a cookbook solution to all of their organizational maladies; instead, Scrum makes visible the dysfunctions and waste that prevent organizations from reaching their true potential..."

"... Plan-driven processes (waterfall, traditional, sequential, anticipatory, predictive, or prescriptive development processes )are so named because they attempt to plan for and anticipate upfront all of the features a user might want in the end product and to determine how best to build those features. The idea here is that the better the planning, the better the understanding, and therefore the better the execution..."

"... Plan-driven development works well if you are applying it to problems that are well-defined, predictable, and unlikely to undergo any significant change. The problem is that most product development efforts are anything but predictable, especially at the beginning. So, while a plan-driven process gives the impression of an orderly, accountable, and measurable approach, that impression can lead to a false sense of security. After all, developing a product rarely goes as planned. [P]lan-driven development approaches are based on a set of beliefs that do not match the uncertainty inherent in most product development efforts..."

"... Scrum, on the other hand, is based on a different set of beliefs — ones that do map well to problems with enough uncertainty to make high levels or predictability difficult..."

It is a comprehensive overview of Scrum. It goes from the principles of agile through the mechanics of sprints to the roles on a Scrum team and all the way up to topics like technical debt and portfolio management with Scrum. 

Some key insights and learnings from the book include:

 - Scrum is a lightweight framework for managing complex projects and products. It is based on the Agile principles of flexibility, collaboration, and customer satisfaction.

 - The three roles in Scrum are the Product Owner, ScrumMaster, and Development Team. Each role has specific responsibilities and works together to deliver a potentially releasable product increment at the end of each Sprint.

 - The Scrum events are Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. These events provide a structure for the Development Team to plan, execute, inspect, and adapt their work.

 - The Scrum artifacts are the Product Backlog, Sprint Backlog, and Increment. These artifacts provide visibility into the work being done and the progress being made.

 - Empirical process control is used in Scrum to allow the team to inspect and adapt their work based on actual results, rather than relying on detailed upfront planning.

 - Scrum is highly adaptable and can be used in a wide variety of contexts, including software development, product development, and even non-technical projects.

The book also covers important topics such as how to scale Scrum, how to measure and improve performance, and how to overcome common challenges.

Chapters of the Book:

Chapter 1: Introduction
  What Is Scrum?
  Scrum Origins
  Why Scrum?
  Genomica Results
  Can Scrum Help You?
  Complex Domain
  Complicated Domain
  Simple Domain
  Chaotic Domain
  Interrupt-Driven Work

Chapter 2: Scrum Framework
  Scrum Roles
  Product Owner
  Development Team
  Scrum Activities and Artifacts
  Product Backlog
  Sprint Planning
  Sprint Execution
  Daily Scrum
  Sprint Review
  Sprint Retrospective

Chapter 3: Agile Principles
  Variability and Uncertainty
  Embrace Helpful Variability
  Employ Iterative and Incremental Development
  Leverage Variability through Inspection, Adaptation, and Transparency
  Reduce All Forms of Uncertainty Simultaneously
  Prediction and Adaptation
  Keep Options Open
  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
  Validated Learning
  Validate Important Assumptions Fast
  Leverage Multiple Concurrent Learning Loops
  Organize Workflow for Fast Feedback
  Work in Process (WIP)
  Use Economically Sensible Batch Sizes
  Recognize Inventory and Manage It for Good Flow
  Focus on Idle Work, Not Idle Workers
  Consider Cost of Delay
  Adapt to Real-Time Information and Replan
  Measure Progress by Validating Working Assets
  Focus on Value-Centric Delivery
  Go Fast but Never Hurry
  Build In Quality
  Employ Minimally Sufficient Ceremony

Chapter 4: Sprints
  Establishes a WIP Limit
  Forces Prioritization
  Demonstrates Progress
  Avoids Unnecessary Perfectionism
  Motivates Closure
  Improves Predictability
  Short Duration
  Ease of Planning
  Fast Feedback
  Improved Return on Investment
  Bounded Error
  Rejuvenated Excitement
  Frequent Checkpoints
  Consistent Duration
  Cadence Benefits
  Simplifies Planning
  No Goal-Altering Changes
  What Is a Sprint Goal?
  Mutual Commitment
  Change versus Clarification
  Consequences of Change
  Being Pragmatic
  Abnormal Termination
  Definition of Done
  What Is the Definition of Done?
  Definition of Done Can Evolve Over Time
  Definition of Done versus Acceptance Criteria
  Done versus Done-Done

Chapter 5: Requirements and User Stories
  Using Conversations
  Progressive Refinement
  What Are User Stories?
  Level of Detail
  INVEST in Good Stories
  Sized Appropriately (Small)
  Nonfunctional Requirements
  Knowledge-Acquisition Stories
  Gathering Stories
  User-Story-Writing Workshop 
  Story Mapping

Chapter 6: Product Backlog
  Product Backlog Items 
  Good Product Backlog Characteristics
  Detailed Appropriately
  What Is Grooming?
  Who Does the Grooming?
  When Does Grooming Take Place?
  Definition of Ready
  Flow Management
  Release Flow Management
  Sprint Flow Management
  Which and How Many Product Backlogs?
  What Is a Product?
  Large Products—Hierarchical Backlogs
  Multiple Teams—One Product Backlog
  One Team—Multiple Products

Chapter 7: Estimation and Velocity
  What and When We Estimate
  Portfolio Backlog Item Estimates
  Product Backlog Estimates
  Task Estimates
  PBI Estimation Concepts
  Estimate as a Team
  Estimates Are Not Commitments
  Accuracy versus Precision
  Relative Size Estimation
  PBI Estimation Units
  Story Points
  Ideal Days
  Planning Poker
  Estimation Scale
  How to Play
  What Is Velocity?
  Calculate a Velocity Range
  Forecasting Velocity
  Affecting Velocity
  Misusing Velocity

Chapter 8: Technical Debt
  Consequences of Technical Debt
  Unpredictable Tipping Point
  Increased Time to Delivery
  Significant Number of Defects
  Rising Development and Support Costs
  Product Atrophy
  Decreased Predictability
  Universal Frustration
  Decreased Customer Satisfaction
  Causes of Technical Debt
  Pressure to Meet a Deadline
  Attempting to Falsely Accelerate Velocity
  Myth: Less Testing Can Accelerate Velocity
  Debt Builds on Debt
  Technical Debt Must Be Managed
  Managing the Accrual of Technical Debt
  Use Good Technical Practices
  Use a Strong Definition of Done
  Properly Understand Technical Debt Economics
  Making Technical Debt Visible
  Make Technical Debt Visible at the Business Level
  Make Technical Debt Visible at the Technical Level
  Servicing the Technical Debt
  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

Chapter 9: Product Owner
  Principal Responsibilities
  Manage Economics
  Participate in Planning
  Groom the Product Backlog
  Define Acceptance Criteria and Verify That They Are Met
  Collaborate with the Development Team
  Collaborate with the Stakeholders
  Domain Skills
  People Skills
  Decision Making
  A Day in the Life
  Who Should Be a Product Owner?
  Internal Development
  Commercial Development
  Outsourced Development Project
  Component Development 
  Product Owner Combined with Other Roles
  Product Owner Team
  Product Owner Proxy
  Chief Product Owner

Chapter 10: ScrumMaster
  Principal Responsibilities
  Servant Leader
  Process Authority
  Interference Shield
  Impediment Remover
  Change Agent
  A Day in the Life
  Fulfilling the Role
  Who Should Be a ScrumMaster?
  Is ScrumMaster a Full-Time Job?
  ScrumMaster Combined with Other Roles

Chapter 11: Development Team
  Role-Specific Teams
  Principal Responsibilities
  Perform Sprint Execution
  Inspect and Adapt Each Day
  Groom the Product Backlog
  Plan the Sprint
  Inspect and Adapt the Product and Process
  Cross-Functionally Diverse and Sufficient
  T-Shaped Skills
  Musketeer Attitude
  High-Bandwidth Communications
  Transparent Communication
  Focused and Committed
  Working at a Sustainable Pace

Chapter 12: Scrum Team Structures
  Feature Teams versus Component Teams
  Multiple-Team Coordination
  Scrum of Scrums
  Release Train

Chapter 13: Managers
  Fashioning Teams
  Define Boundaries
  Provide a Clear Elevating Goal
  Form Teams
  Change Team Composition
  Empower Teams
  Nurturing Teams
  Energize People
  Develop Competence
  Provide Functional-Area Leadership
  Maintain Team Integrity
  Aligning and Adapting the Environment
  Promote Agile Values
  Remove Organizational Impediments
  Align Internal Groups
  Align Partners  
  Managing Value-Creation Flow
  Take a Systems Perspective
  Manage Economics
  Monitor Measures and Reports
  Project Managers
  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
  Portfolio Planning
  Product Planning (Envisioning)
  High-Level Product Backlog
  Product Roadmap
  Release Planning
  Sprint Planning
  Daily Planning

Chapter 16: Portfolio Planning
  Scheduling Strategies
  Optimize for Lifecycle Profits
  Calculate Cost of Delay
  Estimate for Accuracy, Not Precision
  Inflow Strategies
  Apply the Economic Filter
  Balance the Arrival Rate with the Departure Rate
  Quickly Embrace Emergent Opportunities
  Plan for Smaller, More Frequent Releases
  Outflow Strategies
  Focus on Idle Work, Not Idle Workers
  Establish a WIP Limit
  Wait for a Complete Team
  In-Process Strategies
  Use Marginal Economics

Chapter 17: Envisioning (Product Planning)
  SR4U Example
  High-Level Product Backlog Creation
  Product Roadmap Definition
  Other Activities
  Economically Sensible Envisioning
  Target a Realistic Confidence Threshold
  Focus on a Short Horizon
  Act Quickly
  Pay for Validated Learning
  Use Incremental/Provisional Funding
  Learn Fast and Pivot (aka Fail Fast)

Chapter 18: Release Planning (Longer-Term Planning)
  Release Constraints
  Fixed Everything
  Fixed Scope and Date
  Fixed Scope
  Fixed Date
  Variable Quality
  Updating Constraints
  Grooming the Product Backlog
  Refine Minimum Releasable Features (MRFs)
  Sprint Mapping (PBI Slotting)
  Fixed-Date Release Planning
  Fixed-Scope Release Planning
  Calculating Cost
  Communicating Progress on a Fixed-Scope Release
  Communicating Progress on a Fixed-Date Release

Chapter 19: Sprint Planning
  Approaches to Sprint Planning
  Two-Part Sprint Planning
  One-Part Sprint Planning
  Determining Capacity
  What Is Capacity?
  Capacity in Story Points
  Capacity in Effort-Hours
  Selecting Product Backlog Items
  Acquiring Confidence
  Refine the Sprint Goal
  Finalize the Commitment

Chapter 20: Sprint Execution
  Sprint Execution Planning
  Flow Management 
  Parallel Work and Swarming
  Which Work to Start
  How to Organize Task Work
  What Work Needs to Be Done?
  Who Does the Work?
  Daily Scrum
  Task Performance—Technical Practices
  Task Board
  Sprint Burndown Chart
  Sprint Burnup Chart

Chapter 21: Sprint Review
  Determine Whom to Invite
  Schedule the Activity
  Confirm That the Sprint Work Is Done
  Prepare for the Demonstration
  Determine Who Does What
  Sprint Review Issues
  Sporadic Attendance
  Large Development Efforts

Chapter 22: Sprint Retrospective
  Define the Retrospective Focus
  Select the Exercises
  Gather Objective Data
  Structure the Retrospective
  Set the Atmosphere
  Share Context
  Identify Insight
  Determine Actions
  Close the Retrospective
  Follow Through
  Sprint Retrospective Issues

Chapter 23: The Path Forward
  There Is No End State
  Discover Your Own Path
  Sharing Best Practices
  Using Scrum to Discover the Path Forward
  Get Going!

With Essential Scrum, Kenny brings us back to the heart of Scrum. And the teams can begin to make the decisions necessary to implement Scrum, making it their own. 

This book serves as an indispensable guide, helping teams choose among the billions of possible ways of implementing Scrum and finding one that leads to success.

Kenneth S. Rubin provides Scrum and Agile training and coaching to help companies develop products more effectively and economically. A Certified Scrum Trainer, he has trained more than eighteen thousand people in Agile and Scrum, Smalltalk development, managing object-oriented projects, and transition management. He has coached hundreds of companies, ranging from startups to the Fortune 10. Rubin was the first Managing Director of the worldwide Scrum Alliance, a nonprofit organization focused on successful Scrum adoption. His diverse development roles have included successful stints as Scrum product owner, ScrumMaster, and developer. Rubin’s executive management roles have included CEO, COO, VP of Engineering, VP of Product Management, and VP of Professional Services.

I am incredibly grateful that you have taken the time to read this post. 

Your support and engagement mean the world to me, and I truly appreciate your interest in the topics I write about. 

I hope that you have found this post informative, educational and engaging. 

If you are interested in reading more of my work, please visit other articles here on the website.

I promise to continue providing valuable and high-quality content for your enjoyment and education. 

Thank you again for reading and I hope to see you soon!

Here are some related articles you may enjoy:

There are even more good things I've prepared for you!

Subscribe below or click here to receive new posts in your Email!

Do you want to read some book notes and recommendations? Discover more here!

Do you want to have amazing weekly content curation? Discover more here!

Follow me on LinkedIn - Twitter - Instagram

Ready to make a positive impact? 

Support my work by sharing my content with your network. 

Your simple act of kindness can reach new heights and help spread valuable information.

Want to show your support in a tangible way? A virtual coffee is a small but mighty way to show your appreciation and give me the extra energy to keep crafting valuable content!

William Meller - Subscribe

1 comment:

  1. It is really a lot of books about agile and scrum, thanks for sharing!