A Guide to Defeating Scrum: Sprint Planning

You’re someone who wants this Scrum thing gone. It threatens your role and must be defeated. You’ve chosen to target Sprint Planning, the event where Scrum teams starting their Sprints with a clear plan for accomplishing their work. I’m here to give you the tools you needs to ensure Scrum teams start behind the 8 ball, detest and decry Sprint Planning, and eventually argue that, “Scrum just won’t work here.” This is the post you’ve been waiting for.

Refinement is Waste

Start by insisting that Product Backlog refinement mid-Sprint is waste. Developers just need to be told what to develop right? Getting everyone together to develop a shared understanding of the “what” and “why” and “for whom” we’re working towards seems unnecessary, yeah? I agree!

You need to convince your superior’s that you posses the vision for the project and that you’ve got the valuable talent of specifying the solution that those developers just need to code. This is important; if the execs get the idea that the Development teams can come up with better solutions than you’ve envisioned your role might be re-evaluated. It’s important that you continue to insist that the Dev teams accept your work items defined by specific implementation details and opinionated changes to the architecture.

Solemnity is Control

You should insist that Sprint Planning has to be an 8 hour block of time where everybody is involved in a conference call THE WHOLE TIMEIt’s crucial that you maintain control over the activities of the development team to ensure they don’t do anything unexpected. You should swat away comments about this meeting being boring. This is a solemn thing after all…planning our future work. Remind participants that their jobs depend on them forecasting with precision. After all, the sales department has already committed to this feature being delivered in the second quarter; this is no laughing matter. John Cleese gives an excellent guide for using solemnity as a tool to achieve the sort of control you need to protect. I recommend you follow his suggestions to the letter.

Doubt Creates Dominion

Do not allow the teams to have a clear context for the Sprint. This could open the door for them self-organizing to create a Sprint Goal with their Product Owner. The floodgates are officially open! Instead of committing to the backlog items they forecasted, they will instead have a Sprint Goal which allows them to negotiate based on what they discover during the Sprint! By allowing this, you release control over the individual work items you’ve worked hard to specify (in great detail) and allow the team to be flexible in how it meets the business need expressed by the the Scrum team’s Product Owner. Sure this might lead to less unnecessary software being built, better overall solutions, and greater team cohesion but that’s not a risk worth taking, right? It’s safer (for you at least) to claim the team isn’t ready to self-organize or that they can’t be trusted with important things like application design and architectural work.

Autonomy Unravels Dependance

Self-organization is a problem. It mean’s you must give up control and allow the creativity and conscience of those doing the work to determine the end result. Much of what you’ve built yourself up to be is threatened by this development. If such behavior becomes the norm, what place is there for you? When they eventually build complete cross-functionality, demonstrate they can build quality software product, and begin to crave autonomy, mastery and purpose in their daily work the wave of their creative power will completely overwhelm any argument that they should be managed traditionally. This even extends to needing a proxy to understand customer requirements or corporate initiatives. If you’ve reached this stage, things are grim indeed. Dust off the resume and start looking for an organization that values the sort of command structure where you are free to exert the kind of control you’re used to wielding.


Do whatever you can to eliminate the wherewithal of the team to vet Product Backlog items before Sprint Planning and insist that they adhere to your instruction during an all-day event at the beginning of a new Sprint. Convince the upper ups that the team’s need your vision and instruction to work efficiently. Stress the solemnity of status quo. Release context carefully, if at all. Keep them focused on the how you are giving them to accomplish. If they show signs of self-organizing, stop it in it’s tracks by any means necessary. So long as you can establish these dynamics, you’ll ensure you’re place in the organization as the essential planner the developers need in order to do their daily work.


Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.