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. I 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 they add 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 to add these items to the Product Backlog.
(Note: To reduce the accidental accumulation of new technical debt, Scrum 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.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
- Applying Professional Scrum
- Introductory class for those new to Scrum
- Professional Scrum Master
- Geared towards Scrum Masters coaching teams
- Professional Scrum Master II
- Advanced class for Scrum Masters
- Professional Agile Leadership
- For leaders and managers of Agile teams
- Professional Scrum Product Owner
- For Product Owners
- Professional Scrum Product Owner - Advanced
- Advanced class for Product Owners
- Professional Scrum with Kanban
- For anyone interested in learning about implementing Kanban principles within a Scrum Team
- Scaled Professional Scrum with Nexus
- For three or more teams working together on a single product
Both public and private classes are available. To learn more, contact Rebel Scrum.
