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. The only thing that is better than a great product is a great product that gets better all the time.
Misconception # 4: We can’t break this Product Backlog item down smaller because then we might have to rerun the same tests in the future, and that’s wasteful!
If we tried to make all of the changes that we would ever need for a module right away, then our Product Backlog items would be really large and each Product Backlog item might include work that otherwise would be considered lower priority. Consider the image below, which shows a hypothetical Product Backlog. What is more wasteful, working on lower priority work or testing as we go to ensure high quality?
From a short-term perspective, it may look as though making all the changes in one module before moving on to the next is best, but it doesn’t make sense from a larger perspective. What is “lean” and what is “wasteful” depend entirely on perspective and what our priorities are. If the goal is to deliver high-value work, providing it in smaller bites and delivering Product Backlog items as ordered in the Product Backlog is the best approach. That could mean we need to make one change in a particular module and then move on to the next Product Backlog item.
Misconception #5: We can’t go to production until we have enough functionality ready to make a splash, so why should we break these stories up smaller?
Scrum relies on incremental product delivery to control risk and increase predictability. Incremental means that we deliver work in bite-sized pieces of end-to-end functionality. Incremental delivery benefits the Scrum Team’s Developers as much as the customer. Developers using incremental delivery can thoroughly test the integrated increment at least once per Sprint. For example, a team using incremental delivery to develop a web form will break up the work so that each Product Backlog item represents a usable change that includes the user interface and database connectivity. This team would discover technical issues much faster than a team that first developed the full user experience before ever connecting to the database. This is just one of the ways that iterative delivery reduces risk. By testing a fully integrated increment at least every Sprint, the Scrum Team can identify defects early when they are often easier to fix. As a result, even if the Product Owner decides to wait for a minimum viable product before releasing to production, incremental delivery still has the value of reducing risk faster, providing greater visibility, and retaining the ability to change direction.
Conclusion
If your team is struggling with incremental delivery, discuss it at your next Sprint Retrospective and brainstorm ways that you can better embody the principle. For Product Owners looking for ways to enhance the ability of their teams to deliver value incrementally, signup for Rebel Scrum's upcoming Professional Scrum Product Owner class, scheduled for March 17-18, 2022. Interested in enhancing your skills as a Scrum Master but can't take time away from work? Signup for Rebel Scrum's upcoming weekend Professional Scrum Master class, scheduled for February 19-20.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
Introductory class for those new to Scrum
Geared towards Scrum Masters coaching teams
Advanced class for Scrum Masters
For leaders and managers of Agile teams
Professional Scrum Product Owner
For Product Owners
Both public and private classes are available. To learn more, contact Mary Iqbal.
