Scrum Is Not a “Silver Bullet” or a Way to Get Developers to Work Faster

Simply “doing Scrum” will not fix your problems. People make Scrum effective; they develop creative solutions by making informed decisions based on empirical data. When people embody the Scrum values, the things that are holding them back become more visible. And when things are visible, there is a chance at improvement. Scrum done well is like a spotlight shining on your organization and the way you work—the good and the bad.

Using Scrum will likely create efficiencies in the development process, meaning some activities will take less time because of its emphasis on continuous improvement. But that misses the point of Scrum. Scrum’s focus is on frequent delivery of value. Scrum is about working differently so that valuable pieces of the product can be released more frequently.

Delivering more of the wrong stuff faster is not very effective. You must be effective in determining what is valuable. You must be effective in adapting to feedback, empirical measurements of real value, and changes in the market. You must be effective at getting to “Done.” Scrum helps you achieve this level of effectiveness.

When it comes to product delivery, we choose effective over efficient. Efficiency is a secondary benefit of Scrum, and Development Teams will determine where they have opportunities to improve efficiency in their own processes. The key is to apply the transparency obtained from having a “Done” Increment to validate the value. The ability to achieve a “Done” Increment and unlock the flow of value is a natural benefit of the framework.

The Product Owner’s Main Focus Is Not Documentation of Requirements

A Product Owner’s accountability focuses on maximizing the value of the product. This encompasses so much more than just writing requirements. A Product Owner works with stakeholders to understand their needs and set expectations. A Product Owner communicates the vision for a product in alignment with the business strategy and the organization’s mission. A Product Owner makes difficult decisions about competing priorities and desires. A Product Owner needs to understand users and how they are using the product.

While the Product Owner is accountable for what is in the Product Backlog and the order (prioritization) of those items, she is likely to delegate some (or most) of the details.

The Product Backlog Is Not an Agile Version of a Traditional Requirements Document

With Scrum, the organization focuses on delivering opportunistic pieces of valuable functionality.

The Product Backlog is a representation of product requirements and is open to change at all times, and it should evolve as the team learns more about the product through delivering Increments of the product. It should evolve as the team learns more about the users, as the team learns about changes in the market, and as business needs change. Even during a Sprint, the Product Backlog items may change as the team clarifies and confirms a common understanding through the process of building it.

The Product Backlog is not handed to a Scrum Team when they start an initiative. Likewise, it should not be treated as a contract that prevents collaborative negotiation and an openness to change.

The Product Backlog Is Not a List of All Requests

The Product Backlog provides transparency into what is planned in the product right now. The Product Owner is accountable for optimizing value, which is done through ordering of the Product Backlog. If the Product Backlog includes items that you don’t intend to implement because they have low value or are not in alignment with the direction of the product, then you are obscuring transparency.

Every request should not be added to the Product Backlog simply to make stakeholders feel good that their request has been captured. A Product Owner fulfills her accountability by making the tough decisions about what will be done in regard to the product. A Product Owner may choose to say, “not now.” If that item becomes relevant in the future, it will come up again and can be added to the Product Backlog at that time.

The Daily Scrum Is Not a Status Meeting

The Daily Scrum is a collaborative planning session to inspect progress toward the Sprint Goal and adapt the plan. It is not meant to account for how each person spent the previous workday. It is not meant to focus on individual status updates because that both loses sight of the Sprint Goal and inhibits the shared accountability of the Development Team to create a “Done” Increment.

The Daily Scrum is not meant to provide status updates to people outside the Development Team. Such a dynamic can cause a lack of transparency into progress and take away the emphasis on Development Team collaboration.

A Sprint Can Be Successful Even When All Planned Sprint Backlog Items Are Not Completed

Even within the shorter time frame of a Sprint, product delivery entails a great deal of complexity and unpredictability. The Sprint Backlog is not a promise to deliver a specific set of items within a specific timeframe. We recognize that we cannot perfectly plan, so we accept that ambiguity and make informed decisions to adapt our plan based on what we learn as the solution emerges. We use the Sprint Goal to provide focus and adapt the Sprint Backlog as we learn more.

A successful Sprint delivers a releasable product. A successful Sprint delivers value.

The Scrum Master Is Not Responsible for Tracking the Development Team’s Work

The Development Team is self-organizing, which means the team members are responsible for monitoring their own progress and adapting their plan. A Scrum Master may support a Development Team by teaching them techniques to work more effectively together and to increase the transparency of their progress and outcomes.

The Sprint Review Is Not an Acceptance Meeting

The releasable Increment is already created when the team gets to the Sprint Review. The Sprint Review is an opportunity to gather feedback and collaborate on what to do next, but it does not lead to an accept or reject decision.

If stakeholders are not happy with the product they see at the Sprint Review, the Product Owner still makes the decision about how to adapt the Product Backlog. If a Product Owner is not happy with the product she sees at the Sprint Review, she should consider how to work more collaboratively with the Development Team during the Sprint to get the product she wants.

It Does Not Take a Lot of Preparation to Start Sprinting

A Scrum Team can start a Sprint if it has a Product Owner with a product vision, a Development Team with all of the skills to create a “Done” Increment, and a Scrum Master. Product Backlog refinement happens along the way.

Of course, it is helpful to have some startup activities such as training and lightweight process definition (e.g., creating a definition of “Done”).

This is also probably a good time to clarify that there is no such thing as sprint 0, infrastructure sprints, or design sprints. The purpose of a Sprint is to produce a “Done” Increment. If you do not plan to produce a “Done” Increment, you are not doing a Sprint. Do whatever you feel is necessary to prepare to start (within reason—don’t get caught in analysis paralysis!). Just don’t call that preparation time sprint 0.