““I love it when a plan comes together”
-Hannibal Smith”
Think about a group of 100 Agile nerds. I identify myself as squarely in the “Agile Nerd” category, by the way. It’s a majestic crowd, isn’t it?
If you asked these 100 Agile nerds a seemingly simple question “What is Sprint Planning?” what sorts of answers do you think you’d get?
Many of them would give an answer that sounded something like this: “It’s a meeting where a Scrum team decides what work they think they can complete in the upcoming Sprint.” I would put myself in this crowd.
A few might push their Agile nerd glasses up their nose and in their best Steve Urkel voice reply: “According to the Scrum Guide, Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.”
Maybe you’d get some other more existential answers, who knows. I don’t actually know 100 Agile nerds to test this hypothesis. Okay, I might. But that’s not really the point.
I was faced with this question recently in preparing some materials for one of our Scrum Master Accelerator modules, and the answer I uncovered changed the way I think about Sprint Planning.
I was facilitating a conversation with about 10 Scrum Masters, and to frame up the conversation, I opened with that very question: What is Sprint Planning? I wanted to talk about inputs, outputs and deliverables.
To add some color (Hard Yards blue, of course), I asked the group to inspect this visual of the scrum workflow. I then asked them to place a blue light bulb next to any ceremony, role/accountability, or artifact that they thought might contribute ideas/input for the Sprint Planning event, which is highlighted in the top left of the workflow (above). I was hoping they would spot some additional chances for the team and stakeholders to influence the product backlog and Sprint Planning.
And like a busy Walgreens following a power outage, we almost ran out of light bulbs.
This was the result. And what followed was an incredibly rich discussion about how Sprint Planning is not an event, rather, it’s a mindset that is woven into the fabric of Scrum.
As empowered, self-organized teams, we are presented with near-constant opportunities to contribute to and influence the products that we work on. When we narrowly define Sprint Planning as an event, we run the risk of missing out on all those chances to connect with our Product Owners and, ultimately, our customers.
As one Scrum Master said, “even the Sprint Planning meeting itself contributes to Sprint Planning because it’s a chance for the team to think about the sequencing of the backlog and get a bigger picture view of the work.”
I started my own Agile journey in 2005 when I converted from a developer to a Scrum Master. I have been on and around Agile teams ever since, as Scrum Master, Product Owner, Coach, Trainer…etc. Until this week, I generally thought of Sprint Planning as a ceremony that belonged to the Product Owner. I recognized it wasn’t a stand-alone event.
Having been a Product Owner, I was familiar with the constant bombardment of inputs and ideas during the sprint cycle. I always perceived those as external influences. As much as we emphasize getting out and connecting with real customers, that doesn’t mean we should discount the opinions of the experts doing the work. Their expertise only multiplies when we include our development team during the requirements discovery process.
This exercise forced me to acknowledge the wealth of chances where internal influences can be exerted on Sprint Planning, and how as Scrum Masters if we are not fostering those connections we are doing a disservice to our teams. As an Agile Coach, I’m always looking to expand my thinking, and I now have a new way to think and talk about Sprint Planning.