According to the 15th annual State of Agile Report, released in July 2021 at digital.ai, there has been a tremendous increase in the adoption of agile frameworks over the past year. Within software teams, agile adoption grew from 37% in 2020 to 86% in 2021. This rapid growth undoubtedly means many individuals working within agile frameworks have not undertaken formal training in it. It’s the perfect environment for misinformation to spread. Below are a few of the most common misconceptions about Scrum.
Misconception # 1: During Sprint Planning, the Developers "commit" to completing the selected PBIs in the Sprint.
The purpose of the Sprint Planning meeting is to plan the work for the upcoming Sprint. During Sprint Planning, the Scrum Team choses a Sprint Goal, selects Product Backlog items they believe will best accomplish the Sprint Goal, and creates a plan for delivering the selected Product Backlog items. The purpose of the Sprint is to deliver a Done increment that meets the Sprint Goal, NOT to deliver every single Product Backlog item identified at the Sprint Planning meeting.
During the Sprint, there may be surprises. These unexpected surprises can happen in complex work, no matter how well a team plans. For example, if the team is building a new software product, they may find that certain features take longer than expected. If this should happen, the team will discuss it at the Daily Scrum and decide what to do. The team might realize that they can’t complete all of the Product Backlog items they identified in the Sprint Planning meeting. In this case, negotiating with the Product Owner to determine which Product Backlog items are necessary to deliver the Sprint Goal and which ones can go will allow the team to focus on delivery.
If the above happens, it is not a failed Sprint. Every Sprint is an opportunity to learn. If the team can deliver a Done increment that meets the Sprint Goal, the Sprint is a success, even if the team had to remove some of the work they had initially hoped to accomplish.
There must be a balance. Team members should hold each other accountable to do what is possible to deliver against the originally agreed-upon Product Backlog Items identified for the Sprint. If a Scrum team is consistently not able to deliver a large proportion of the work planned for the Sprint, this should be discussed at the Sprint retrospective. Teams should agree upon a target percent complete figure for all Sprints. Predictably is an important aspect of forecasting.
Scrum is a framework that relies upon the intelligence of those using it. It’s helpful in a complex environment where more is unknown than known. At the Sprint Planning meeting, the team might not plan the activities that will take place every single day in fine detail. They are more likely to create a plan with enough information to get started, and then they begin work on delivering the Increment. The Developers then meet every day at the Daily Scrum event, where they discuss their progress towards the Sprint Goal and adapt their plan accordingly. This empirical approval of making decisions based on what is known is the best approach to deliver complex work.
Misconception # 2: One person cannot play more than one “role” in Scrum
The Scrum Guide doesn’t define roles. Instead, it describes three accountabilities that are part of the Scrum framework. Anyone on the team can manage these accountabilities.
These accountabilities are Product Owner, Developers, and Scrum Master. The Product Owner accountability is to maximize the value of the work the Scrum Team produces, and the key tool in accomplishing this task is ownership of the Product Backlog (the to-do list) for the team. The Developers’ accountability is to create a Done, usable increment each Sprint; they are self-managing and together have all of the skills necessary to deliver a usable product increment each sprint. The third accountability is Scrum Master, who seeks to improve the application of Scrum by coaching the Scrum Team on Scrum theory and practices.
Nowhere in the Scrum Guide does it say that one individual cannot manage both the Scrum Master accountability and the Developer accountability. Likewise, in no place is it stated that the Product Owner accountability is a full-time endeavor.
Scrum is a framework, not a set of work instructions. It relies upon the intelligence of those practicing it. A team has the autonomy to decide that the Product Owner accountability can be performed simultaneously with another accountability, such as that of Scrum Master or Developer by a single individual.
Depending on the size of the team, doubling up accountabilities might make sense. For example, on a three-person Scrum Team, it could be reasonable for one individual to wear multiple hats on a team.
Of course, there are trade-offs when a larger team has an individual wearing multiple hats. For teams with nine developers, for instance, it might be difficult for a single person to manage more than one accountability at a time.
Misconception # 3: Velocity is part of Scrum, and it's the best way to measure team performance
Of course, velocity matters, but it is not a measure of team performance. Instead, it’s an optional tool the Scrum team can use to plan and forecast work. The word velocity does not even appear in the Scrum Guide, and it is not part of the Scrum framework. If you are seeking to measure the performance of a Scrum team, measure based on outcomes (like profit, customer satisfaction, product quality), not based on outputs (such as velocity or number of Product Backlog items closed per Sprint.) When you measure what matters, you are helping the team to FOCUS on what matters.
What is velocity? Velocity is a complementary practice used by many Scrum teams. It indicates the amount of Product Backlog turned into an increment of product during a Sprint by a Scrum Team. Velocity is frequently referred to as a measure of how many points the team closes in a given sprint.
Frequently, those outside of the Scrum Team, such as Managers and Executives, learn about the concept of velocity and believe that this is the best way to measure the performance of the Scrum Team. It’s not. The best measure of team performance is the creation of a Done, usable increment at the end of each Sprint.
How is velocity used? Developers use velocity to gauge how much work to pull in a Sprint during the Sprint Planning event. Some teams use points to relatively size Product Backlog Items so that work similar in complexity, risk, and effort receives similar point estimates. It’s an improvement compared with estimating using hours because it takes the question of over or underestimating off the table. If a team estimates a story at a certain point size and then can close a set of pointed stories, they learn over time how many points they can close based on their estimation style. The average number of points closed per sprint is the team’s average velocity. It takes the guesswork out of determining how much work the team can accomplish in a sprint.
Velocity is also a useful tool for Product Owners because it enables them to forecast when Product Backlog items will be completed. For example, suppose a team has a steady velocity of a certain number of points per sprint. In that case, you can use simple math to determine how many points worth of work they can expect to complete in future sprints, and from there, project dates into the future for when they might complete desired Product Backlog items.
Many leaders mistakenly believe that velocity is the best measure of team performance and that well-performing Developers should continually improve in velocity over time. This is not the case. A steady velocity might signify that the Developers are performing well and are consistently turning Product Backlog items into increments of Done product. Developers becoming increasingly efficient might have an increasing velocity, but then again, they might not. An increase in velocity could mean they have simply switched to a new point system. Likewise, you can’t compare the velocity for one team to the velocity for another team. Even if they are using the same point system, they might be accustomed to applying different points for similar-sized Product Backlog Items.
Understandably, this is a lot for leaders to digest.
Fortunately, there is a simpler path to measuring team performance. Is your team creating a Done increment each Sprint? Are they living the Scrum values? Are value metrics improving for the product? How responsive is the team (lead time, cycle time)? These are just a few of the options for measuring team performance. Base your measures on what matters for the product, and remember that each metric you choose is just the start of the conversation.
For more ideas on how to measure the success of your Scrum team, see the Evidence-Based Management guide, or attend an upcoming EBM class. For a discussion on team metrics in the context of coaching teams to greater performance, attend a future Professional Agile Leadership class with Rebel Scrum.
Misconception # 4: When multiple Scrum Teams are working on the same product, each Scrum Team needs to be a feature team.
I get why people think this. When multiple Scrum Teams are working together on a single product, it can be daunting to think about how to organize those teams. I have seen managers spin on this topic for weeks. Many believe that the only way to go is by splitting the product into logical features based on logical areas within the code and assigning a team or two to each feature. This is not the case. In the first place, when there are fewer than nine teams, it can work very well to set up the teams so that any team can work on any area of the system. This organizational strategy leads to great flexibility, allowing teams to focus on the highest priority work and deliver it much faster than feature teams might be able to do. Second, it is better to let the teams determine the best way to organize themselves. Give them guidelines (e.g., fewer than ten team members per team, including the Product Owner, each team must have all the skills necessary to deliver a done increment at the end of the Sprint), provide them with an overview of the Product Goal and the upcoming work, and let them decide how best to organize to deliver the work.
Additionally, when there are more than three teams on a product, they will likely need to scale. Scaling means finding ways to help the various Scrum Teams work together to manage dependencies and coordinate their work to create a single, integrated increment each Sprint. Nexus is the simplest scaling method there is. Simple is better. That’s why SCRUM is so popular, after all; because, with complex work, less structure is better. To learn more about scaling teams with Scrum, attend Rebel Scrum’s Scaling Professional Scrum class.
Misconception # 5: The Product Owner alone is the one who should write the Product Backlog items, acceptance criteria, split the PBIs, and get PBIs to a ready state.
While the Product Owner is accountable for the Product Backlog, the Product Backlog is something that the Scrum team collaborates on. Product Backlog refinement is a balancing act. The Product Owner primarily focuses on what they would like to add to the product and why. The Developers concentrate on collaborating with the Product Owner to refine valuable work and sizing the work so that they can deliver a valuable increment of Product each Sprint. Coming out of the refinement process, the team should size the highest ordered Product Backlog items so they can complete them within one Sprint, remove as many dependencies as possible, and order the work to maximize product value.
Higher ordered Product Backlogs item should contain a description, order, and estimate. Developers estimate the work. If an individual Product Backlog item is too large to complete within one Sprint, the entire team collaborates on how best to split it into smaller, valuable Product Backlog items. At the end of this process, the team should formulate each Product Backlog item to deliver a unit of value to the product. This means that stories are not split up in terms of how they are delivered (e.g., there are not separate “development” and “testing” stories), but rather, they are split into smaller deliverables.
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 who are practicing Scrum without formal knowledge about the framework and who want to expand their team’s productivity and practices.
If you are currently fulfilling 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 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.