Setting the Tone for Success
The age-old question that many present to me is pretty simple, “What is sprint planning?”
Yet, lurking behind that more profound inquiry lays another question, “Why is Sprint planning?”
Let me help shed some light on this. 🚀
Moment of Alignment
Sprint planning is, fundamentally, a time where we get together and chalk out what we will achieve in our upcoming sprint. It could be a two-week stint, three days, or any other duration. 🔄
The essence?
Planning the sprint (it’s as straightforward as it sounds!).
Yes, it’s about planning the sprint, and as I often chuckle, it “kind of makes sense.” 🚀
It’s All About Understanding
This isn’t just a ritual. It’s not about how long the meeting is. It’s about clarity. Whether it’s a quick 5-minute chat or an asynchronous check-in on Teams or Slack, the heart of the matter is understanding.
Do we all grasp where we’re headed?
Are we aligned on what needs to be done and how? This is the pivotal point of sprint planning.
Kanban vs. Scrum
I’ve heard the argument, “We do Kanban, so we don’t need Sprint planning.” 🤼
But when do you decide what to pull into the sprint?
That decision-making process is essentially sprint planning. The difference is, in Scrum, you’re actively involved. It’s about deciding which tasks from the ever-evolving product backlog will make the cut for the upcoming sprint.
Every sprint planning session allows for this evaluation and realignment.
Refinement and Selection
We’ve got refinement, which comes before sprint planning.
Sprint planning isn’t just about new features. , it’s about understanding “all that stuff that we would like the product to do”. It’s about live site incidents, technical debt, bugs, customer feedback, and other ongoing tasks. ✅
We can’t focus 100% on our sprint goal. We have to make room for unexpected events. Sprint planning provides that flexibility and ensures we don’t lose sight of our main objectives.
Balancing Commitment to Goals
Sprint goals are like mini-milestones. They give a clear picture of the tangible results we aim for in the immediate future. It creates a cadence of success, achievement, and motivation for the team. 🎯
Whether fulfilling a crucial customer request or adding a feature they’ve eagerly anticipated, sprint planning lays the foundation for these victories.
Scrum & Kanban
Whether you’re doing “little K kanban” or “big S Scrum,” we’re all fundamentally working towards the same idea.
While Scrum focuses on planning, Kanban emphasises delivery. Merge them, and you’ve got a powerful combo, ensuring both strategy and execution are top-notch!
It’s the best of both worlds. 🌎
For those passionate about delving deeper into the world of Scrum, Kanban, or even Agile practices, I’d be thrilled to share more insights.
Join me on my Agile and Scrum courses to journey into the world of efficient project management.
So the question is, what is Sprint planning? There’s a more important question there: why is Sprint planning? But what is Sprint planning? It’s a time where we get together and we plan what we’re going to do over the next, whatever Sprint length we have, over the next Sprint—two weeks, three weeks, four weeks, three days, whatever your Sprint length is.
We’re going to plan the Sprint, right? So Sprint planning is about planning the Sprint. Kind of makes sense. But it matters because it gives us that moment, that check-in, which could be short. It could be a tiny Sprint planning because everybody already knows where we’re going, already understands what we’re going to take on. We’re going to get in a room, five minutes later we’re out, we’re done. Or it could even be a check-in, an asynchronous check-in over Slack or Teams, right? Do we all understand where we’re going?
The point is the understanding. Do we all understand what we’re trying to achieve this Sprint? Do we all understand what’s involved in it, what direction we’re going, what needs to happen in order to get there? That’s the purpose of Sprint planning.
A lot of people come along and say, “Well, you know, we do Kanban, so we don’t do Sprint planning.” My question is, when do you decide what work you’re going to pull into the Sprint? How does that work get onto that list of things, that list of options, right? That the team is able to select from. That is, in effect, Sprint planning, whether you’re involved in it as the team or not, right? That is Sprint planning.
And wouldn’t it be better if you were involved in it? Effective Kanban teams are normally involved in it, right? They’ve got a say in what ends up on the options, what goes in there, what’s ready to pull into the Sprint. That’s Sprint planning, right? You’ve got refinement, which comes before Sprint planning, which is how—like building that list of options.
Then Sprint planning is really about just deciding what is the next list of options. From a Kanban perspective, from a Scrum perspective, the same thing is true. You have refinement, which is all the work that you do that’s not on the current, you know, adding features to the product. Then Sprint planning is about now we understand all of that stuff that we would like the product to do that it doesn’t do yet.
What are the things that we need to do in the next two weeks? We’re planning, right? In the next two-week iteration, or that we think we need in the next two-week iteration that we’re going to pull into the Sprint. And that might be, you know, here’s our Sprint goal, here’s what we’re going to try and achieve this Sprint. Like, this is the communication goal, the thing we’re going to commit to.
If you’re doing Scrum, you commit to the Sprint goal, right? But that might only be a small percentage of the work that you need to do in the Sprint because we’ve also got that, you know, we had some live site incidents and we’ve got a large refactoring exercise of our architecture that’s going on, and we’re doing a little bit of that every Sprint. So we’re spending 20 percent of our time every Sprint doing that.
We have some technical debt that we’re working through that we’ve discovered, and we’re going to spend 10 percent of our time on technical debt. We’ve got some bugs, some things that customers have reported, so we might have some things that they’ve reported, some defects, some bugs, actual errors in the product. We’re going to bring some of them into the Sprint every Sprint, right? Otherwise, you end up with a dumbass bug-fixing Sprint, right?
We’re going to do a little bit of everything all the time to maintain our product. Sprint planning is about deciding what all of those things are and what the percentages are that we think we’re going to be able to take on this Sprint. Right? So you don’t want your Sprint planning to say, “Oh, we’re going to spend 100 percent of our time on our Sprint.” That would be silly because what happens when something happens in the product, right? There’s a production incident. Well, now we’re screwed, right?
Or somebody comes running in from the business saying, “I know you’re working on all this stuff, but this has happened, and this is the most important thing to us right now.” If we don’t have some—what’s it called when you make it bigger than it is? Hyperbole, right? If we don’t get this done by Thursday, we’re all out of business and all out of a job, right? Do we just go, “No, I’m sorry, we’ve planned our Sprint, we can’t take that,” or do we create a system within which we can have those conversations?
We can see, “Well, yeah, that sounds really important, let’s bring that into the Sprint.” Or, you know, also a customer reports some little bugs, and the customer says, “Can you please get them fixed because they’re just annoying, and they’re annoying a bunch of our users?” Yeah, sure, let’s fix them, let’s bring them into the Sprint, let’s get them fixed.
How do you create that urban flow of the work that you’re doing while still maintaining direction and strategy, right? So you’ve got the product goal, which is your overall, what’s the next big thing we’re working on, but the Sprint goal is what’s the next little thing we’re working on, and that’s what we commit to, and that’s what we decide at Sprint planning.
So it creates that cadence of success, cadence of achievement, right? What are we trying to achieve this Sprint? Yeah, we’ve done these hundred little things, but also we did this, which the customer was really looking forward to, that we had conversations with the customer about, that we crafted into a Sprint goal. That’s one of the things that we do at Sprint planning.
I feel like, regardless of whether you’re doing a little Kanban or big Scrum, you’re really working towards the same idea and can use the same tools and techniques. There’s also big Kanban, the Kanban method, which has its own structure and process and rules. That’s its own thing.
But if you’re looking at Scrum and Kanban, you definitely want Scrum and Kanban. Scrum is about planning, which is why this starts with the Sprint planning. It’s all about planning. Kanban is about delivery. So bringing them both together, and you actually get the best of both worlds. You get that planning cadence, connecting with customers, understanding what we’re doing.
Sprint planning is the thing that sets the tone for the rest of the Sprint. Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else—Agile, Scrum, or DevOps—then please book a coffee with me through Naked Agility.
