Scrum includes three accountabilities, three artifacts, and five events that help guide how individuals work together within the organization. The framework’s regular feedback loops allow the Scrum Team to regularly inspect what they’re doing and improve how they work together. Continuous improvement is a Scrum cornerstone.
Scrum’s strength is that it makes difficulties visible faster so the team can address them. While the framework helps to resolve many things that might not be working optimally, it doesn’t eliminate every issue. Let’s look at three problems Scrum doesn’t solve.
Not enough items in the Product Backlog
Years ago, I worked with several new Scrum Teams supporting a single product. The teams had formed only a few months before. At one of the retrospective events, team members identified that they did not have enough items in the Product Backlog. To resolve this issue, they identified individuals who would work with the Product Owner during the next Sprint to break down larger Product Backlog items in specific system areas. While discussing the situation with the Scrum Master and others the day following the retrospective, one of the managers turned to me and asked, “Shouldn’t Scrum solve this?”.
The question didn’t surprise me because of a common myth that Scrum Teams don’t need business requirements— at all. Somehow, everything just falls into place on its own. That’s not how it works.
I get where the confusion comes from. Traditional approaches to software development typically call for a planning phase where a charter is created and an analysis phase where a requirements document—sometimes hundreds of pages long—is written to detail every facet of how the system should work.
Scrum Teams don’t work that way.
In Scrum, requirements emerge over time, and the team includes them in an emergent Product Backlog, which grows as they discover more information. The difference is that the Scrum Team isn’t producing reams of requirements documents in a futile effort to predict how everything will unfold. They are still, however, working on requirements.
Let’s go back to my original example. The Product Owner might struggle to have enough items in the Product Backlog in the early days of product development. They might misjudge how quickly the developers work, not gauge item size correctly, or have difficulty determining emerging requirements. The team can discuss the lack of items in the Sprint Retrospective and choose a path forward. Many teams find it helpful to have Developers work alongside the Product Owner to determine Product Backlog items, for example.
In contrast, I have worked with teams using a waterfall approach who have suffered in silence for weeks—or months—with poorly written documentation or a misunderstanding of the business needs. This should never happen on a Scrum Team because they would discuss any impediments at the Daily Scrum. More significant issues might get resolved at the monthly Sprint Retrospective.
So, Scrum doesn’t magically solve the issue of not having enough items in the Product Backlog, but it brings that problem to light quickly so that the team can address it together.
Poor stakeholder communication
During a recent Professional Scrum Product Owner class, a Product Owner working in health care revealed she was struggling to come up with a roadmap (or product forecast) that worked for her stakeholders. She thought it should have been resolved in the Sprint Review stating, “Given that the Sprint Review includes key stakeholders, should I need additional communication with them?”
I understand where she was coming from. A lot of communication takes place during the Sprint Review. This second-to-last event in the Sprint allows the Scrum Team and its stakeholders to inspect the outcome of the Sprint and determine future adaptations. During this event, the Scrum Team may review the Product or Sprint Goal, demonstrate working software, collect feedback, examine the Product Backlog, and forecast what the Scrum Team will work on next. The information exchanged during the Sprint Review allows stakeholders to understand what the Scrum Team is working on and to provide feedback on what they plan to work on next.
While the Sprint Review does provide a lot of information to stakeholders and reduces the need for other meetings, it might not replace the need for additional dialogue with internal or external stakeholders.
Internal stakeholders may benefit from reviewing the Roadmap, which shows the current projection of what the Scrum Team will work on next. External stakeholders may need to receive marketing or sales materials. Not everyone will be able to attend the Sprint Review, and the Product Owner may choose to limit attendance to improve the quality of discussion at the Sprint Review. Scrum doesn’t tell you how to communicate with your stakeholders. Although the Sprint Review is a valuable event for the Product Owner and stakeholders, it likely won’t eliminate the need for other communication.
Eliminating dependencies
Dependencies are bottlenecks where one piece of work cannot be completed unless another piece of work gets done first. They can slow progress significantly. Because Scrum Teams are cross-functional (meaning they contain all the skills necessary to deliver an increment of product each month), people sometimes think that any dependencies simply disappear. That’s not necessarily true.
Dependencies may exist within a Scrum Team or externally. If dependencies are internal, the Scrum Team might be able to plan for them during the Sprint Planning event. Or, the Product Owner may agree to order the Product Backlog to manage the dependencies better.
There may also be some external dependencies requiring work from another team or individual before the Scrum Team can complete its work. The Scrum Team can determine a process for managing occasional external dependencies via the Product Backlog order or by working to improve adjacent processes to the Scrum Team. If dependencies are frequent, it might be that the organization has defined the product too narrowly (e.g., breaking the product down into multiple smaller products).
If a team struggles with too many dependencies, they should discuss it in the Sprint Retrospective. The team might need leadership involvement to redefine the products in an organization to reduce dependencies and accelerate value delivery. For more information or to discuss this issue further, contact Rebel Scrum.
Conclusion
Scrum doesn’t solve everything for the team developing a product. Instead, the framework allows the team to recognize where the problems are early so they can strategize to resolve them before they snowball into more significant issues and delays. That is the beauty of the Scrum framework. It is not a set of work instructions; instead, the framework is a guide within which teams discover the complementary practices that work best for them in their context.
To learn more about Scrum, signup for the Applying Professional Scrum course. Applying Professional Scrum (APS) is for those new to Scrum or who need to learn more about Scrum roles, artifacts and events.
