Many well-meaning practitioners have misconceptions about Scrum. Scrum is a framework for doing complex work, not a how-to playbook. It’s incomplete by design because there are no simple best practices to fit all situations in complex environments. As the 2020 Scrum Guide puts it, “Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.” This very incompleteness is one of the strengths of Scrum, but without specific guidance, some myths have evolved about the right way to run a Scrum Team.
Misconceptions about Refinement—the process of adding detail, order and size to individual Product Backlog items can be highly detrimental to a team's ability to deliver value to the business frequently. We dive into the most common myths below. Don't fall for it if someone tells you these practices are part of Scrum.
Misconception # 1: The Product Owner alone is accountable for Product Backlog refinement
Product Backlog refinement is critical to the Scrum Team. If they don't correctly size higher-ordered Product Backlog items, the team will be unable to complete them to deliver value each Sprint. While the Product Owner is accountable for the order and content of the Product Backlog, Developers are accountable for sizing individual Product Backlog items. It makes sense when you think about it. Developers should size the work because they are the ones who will be accountable for delivering the work.
In addition to sizing Product Backlog items, Developers are accountable for collaborating with the Product Owner to maximize the product’s value. This also makes sense because Developers have a deep understanding of the product and could have valuable improvement ideas or be aware of obstacles, such as technical debt, which are slowing delivery, and should be addressed through improvement items added to the Product Backlog.
Misconception #2: Technical debt is the Developers’ problem
Closely related to the first misconception is the idea that technical debt is a problem for the Developers to sort out on their own. Technical debt is a common software development term describing coding decisions that might slow future delivery of value to the customer. For example, delaying necessary upgrades is a common type of technical debt. Poorly organized code or unnecessary code lines are also examples of technical debt.
Not all technical debt is bad. A Product Owner might decide to delay an upgrade to release new high-value features to the customer sooner. Likewise, the Product Owner might authorize an experiment or a pilot that does not have a robust technical framework to get customer feedback about usage.
As the name implies, technical debt needs to be “paid back” to avoid slowing future delivery of value. The team might address technical debt through improvements added to the Product Backlog. For example, upgrades, bugs, and new features should be ordered by the Product Owner, giving the Product Owner greater control and accountability for the product as a whole.
Developers should make the Product Owner aware of technical debt they may not be aware of, such as code that isn’t well documented or well organized, so that the Product Owner can decide whether or not to add these items to the Product Backlog.
(Note: To reduce the accidental accumulation of new technical debt, teams should regularly review their Definition of Done.)
Misconception #3: We can’t break this Product Backlog item down any smaller because then we might have to return to the same part of the code again in the future, and that’s wasteful!
We use Scrum in complex environments where more is unknown than known. As a result, the Product Backlog is an evolving to-do list based on customer feedback, market changes, and sometimes even the weather. We will never have a complete list of needed changes for a given module. We know that we will come back to this module in the future, even if we don’t know when.
What we do know is that delivering value frequently is a key ingredient for customer satisfaction and reducing risk for the business. We do know that working on the highest priority over lower priority items eliminates waste. We do know that a successful small deliverable is easier to achieve than delivering a mountain, making our customers happier. T