Interpreting the Sprint Backlog
One of the most common inquiries I encounter is, “What is a Sprint Backlog?” 📝
The Scrum Guide offers a blueprint answer, but let’s break it down further into three pillars of three key elements.
The Sprint Backlog, in my words, is essentially three things tied together:
1. The Sprint Goal: A central objective that drives Sprint’s activities is to focus on what we’re trying to accomplish. 🎯
2. Selected Backlog Items: Handpicked tasks that are earmarked for execution. 📋
3. A Concrete Plan: A strategic roadmap detailing how to achieve these tasks. 📈
The Transparency Beacon
From my viewpoint, the Sprint Backlog symbolises our ’transparency of the present’. 💡
It’s our litmus test answering two pivotal questions: “What are we working on now?” and “Where do we stand in our march toward the Sprint and Product Goals?”
Balancing Priorities
Crucially, the Sprint Backlog isn’t solely tethered to the Sprint Goal. If it were, where would tasks like refactoring, architecture adjustments, or bug fixes fit? ⚖️
They, too, are indispensable, even if they aren’t directly linked to Sprint’s primary objective.
The key is to strike a balance: the Sprint Goal should cover a chunk of the Sprint Backlog but not the entirety. This ensures flexibility and prevents the dreaded ‘bug fixing sprint’.
Setting Teams Up for Success
The Sprint Goal shouldn’t be a herculean task. If a team consistently fails to meet its goals, it sows seeds of disillusionment and dampens morale. After all, teams thrive on victories, however small. Hence, ensure that your Sprint Goal is ambitious yet achievable. 🚀
Crafting the perfect Sprint Goal is an art.
Remember, it’s the beacon your stakeholders focus on, while other tasks represent the ongoing business rhythm. The versatility of the Sprint Backlog even permits the inclusion of fresh tasks during the Sprint, bolstering our ability to swiftly react to evolving business, customer, or market requisites.
We want to set our teams up for success, ensuring they can proudly say they’ve achieved their goals.
Staying Agile and Adaptable
The Sprint Backlog’s beauty lies in its flexibility. There’s room to bring in new work during the Sprint. This malleability means we can rapidly respond to our business, customers, or market’s evolving needs.
It’s all about staying Agile. 🔄
Closing Thoughts
Understanding the Sprint Backlog’s intrinsic nature is paramount as we venture through the Agile landscape. 🤔
It’s a powerful tool, and when used right, it can be the key to unlocking unparalleled productivity and success.
Embracing its nuances empowers teams to maintain an unwavering focus while still preserving the agility to pivot.
Equip yourself to navigate these Agile and Scrum intricacies with my comprehensive courses.
So the question is, what is a Sprint backlog? According to the Scrum Guide, a Sprint backlog is kind of three things together. The first is the Sprint goal. The second is the selected backlog items, and the third is a plan to complete them. Some kind of plan for those three together is the Sprint backlog.
My perspective is that the Sprint backlog is our transparency of the present. Right? It’s how do we know what we are working on just now? How do we know where we are in our progress towards our current Sprint goal and ultimately our overall product goal?
Um, so the Sprint backlog is made up of all of the things that we’re working on this Sprint, but it’s very important that the Sprint backlog isn’t 100% to do with the Sprint goal. If we always have our Sprint backlog must be 100% to do with our Sprint goal, then what do we do with all those other things that we need to do over time? Perhaps we’ve got some refactoring, perhaps we’ve got some architectural work we have to do, perhaps we’ve just got some bugs to fix. Do we have to have a bug fixing Sprint? Right? That’s where that dysfunction comes from.
So what you do instead is your Sprint goal encompasses some of your Sprint backlog. This is the thing that you commit to, the thing that you’re definitely, definitely going to try really hard to achieve. Right? Because that commitment, try really hard to achieve, that’s the thing you’re definitely, the thing you’ll talk to your customers about, talk to your stakeholders about, engage with them on that topic. And then there’s a bunch of other things that you’re going to bring into the Sprint that are perhaps nothing to do with the Sprint goal. You might have some refactoring work, you might have some technical debt you want to go fix.
Um, you might have, here’s some stuff that we haven’t automated in a while and we want to go back and fix that up. Perhaps you’ve got, oh, the build’s taking too long, and we really need to go re-engineer that thing so that it’s faster and our engineers know quicker that something’s wrong. That’s all work that needs to be done that doesn’t fit within a Sprint goal because a Sprint goal is always talking about what the customers need, what the stakeholders need, what are we trying to deliver for them.
The rest is business as usual, right? Stuff we have to do all the time, so that’s included in that story. So try and avoid having a Sprint goal that is so big that you can’t achieve it. Right? Any team that is working towards a Sprint goal and then they can’t achieve it is not going to be happy. Right? Hopefully, they’re not going to be happy. I’m not happy that I wasn’t able to achieve the thing that I committed to try and achieve to the customers. That wouldn’t make me happy.
What if the team are in the position of doing that Sprint after Sprint after Sprint? They’re not delivering because the Sprint goal is always too big. It’s complete these 10 things and you only get six of them done, so we failed. Or it’s do this big thing and we got 90% of the way, so we failed. Right? If we’re constantly failing, you’re going to have an unhappy, depressed team, and unhappy, depressed people don’t make good products. They don’t make good decisions. They tend to not give a crap about what it is you’re building anymore at some point, and we don’t want to go there.
So create, set them up for success by having a Sprint goal that has a narrower focus. Right? Not the whole Sprint, just part of the Sprint, so we know we can achieve it. And then add other things that are much more flexible. Right? Whether we do half the refactoring or all the refactoring is kind of irrelevant as long as we do some of it and make progress.
We’ve got that Sprint goal, and don’t be afraid to change what you’re working on during the Sprint. Right? You can accept new work into the Sprint. That’s the other reason you have that flexibility. Right? You have that Sprint goal that’s smaller, so you can bring other work into the Sprint. You can change what you’re working on, and we can respond to the needs of the business, the needs of the customer, the needs of the market much more quickly. That’s what a Sprint goal is.
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.
