A lot of people are passionate about Scrum, and why not? Most of us spend the majority of our waking hours at work, and the agile framework can make it infinitely more pleasant and efficient. The 15th annual State of Agile Report reveals that over 90% of the teams working within an agile framework use Scrum. What’s more, agile adoption grew from 37% in 2020 to 86% in 2021 for software teams. Inevitably, that rapid increase means that many individuals working within agile environments have not yet undertaken formal training in one of its frameworks. That’s a perfect storm for misinformation to spread.
Last week, we talked about common misconceptions related to the Daily Scrum. This week we’ll focus more broadly on misconceptions impacting everything from the Product Backlog to the composition of the Scrum Team itself.
Misconception # 1: Developers should not spend more than 10% of their time on Product Backlog refinement.
This topic is discussed in Scrum.org’s Applying Professional Scrum class. A previous version of the Scrum Guide did include verbiage suggesting developers spend 10% of their time on refinement. However, today’s Scrum Guide no longer provides that direction, recognizing that in complex environments, we need to rely upon the intelligence of those using Scrum to sort out the best way to apply the framework to their unique environment.
Each Scrum Team should decide for itself how much time to spend refining the Product Backlog. The amount of time will depend on the product’s complexity, maturity, marketplace (e.g., phase in the product life cycle), the level of innovation required, and other factors such as deadlines or holidays. If the team spends too much refining, it may create waste by either refining too many Product Backlog items or adding too much detail to each one. If they spend too little time in refinement, the team is prone to waste time in the Sprint discussing questions they could have resolved in advance.
Misconception # 2: You shouldn't share Scrum Team members or have them work part-time
Many people think that Scrum Team members shouldn’t be assigned to a team part-time. However, there is nothing in the Scrum Guide prohibiting it. There are, of course, trade-offs for part-time Scrum Team members. If too many individuals are part-time, the team may not accomplish as much meaningful work during a Sprint. Additionally, with part-time members it can be more difficult for the team to learn how much work they can achieve during a Sprint, particularly if a member’s part-time status fluctuates. Moreover, if the part-time members support multiple Scrum Teams, they can feel exhausted attending numerous Daily Scrum meetings and splitting their focus. The Scrum Team should consider these trade-offs when self-organizing into teams that include part-time members.
Misconception # 3: The timebox for Sprint Planning, Sprint Review, and Sprint Retrospective for Sprints shorter than one month is proportionately shorter (e.g., Retrospective timebox for a one-week Sprint is 45 minutes).
Timeboxes are an essential part of all Scrum events because they help limit waste and support empiricism, making decisions based on what is known. For example, the result of the Sprint Planning event should be enough of a plan for the team to get started. Going forward, the team will continuously adapt the Sprint Backlog during the Sprint as they discover more information.
The team might spend less time in events such as Sprint Planning and the Sprint Review for shorter Sprints, but it is not necessarily proportional. The timebox for these events will depend on the product, the team’s experience level, and the number of Scrum Team members.
Misconception # 4: The Product Owner does not need to attend the Retrospective.
Many mistakenly believe that the Product Owner does not need to attend the Retrospective event. The Product Owner is a peer member of the Scrum Team. If the Product Owner does not attend, the team loses a key improvement opportunity. For example, imagine that the Developers want additional information on each Product Backlog item to improve their ability to deliver a Done increment. They cannot have this discussion effectively if the Product Owner doesn’t attend the Retrospective.
Misconception # 5: You can’t hold Developers accountable for not delivering PBIs within the Sprint because they self-manage.
This misconception is a delicate one. Developers should be holding each other accountable for their work together to deliver a Done increment that meets the Sprint Goal. Unfortunately, sometimes a Developer does not pull their weight. If a Developer goes Sprint after Sprint without closing a single Product Backlog item or contributing meaningfully to the team’s progress either by taking ownership in Refinement or working collaboratively with other Developers, then the Scrum team should take action by discussing the issue at the Retrospective openly. If team members have tried in vain to hold another accountable for contributing to the team’s success, they might need to escalate the concern to the appropriate individual, such as a manager or human resources. Self-management does not exempt Developers from being accountable.
Conclusion
If you find yourself facing any of these misconceptions, consider signing your team up for the Applying Professional Scrum class with Rebel Scrum. Applying Professional Scrum is the best class for those practicing Scrum without formal knowledge about the framework and who want to expand their team’s productivity and practices.
If you are currently practicing the Scrum Master accountability, consider signing up for the Professional Scrum Master class with Rebel Scrum. The Professional Scrum Master course is the best class for Scrum Masters who are looking for ways to improve the efficiency of their Scrum Teams.
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.