When it comes to successfully navigating the complexities of Agile and Scrum, there are a few key principles that I’ve found to be absolutely essential. Drawing from my experiences, I want to share three critical strategies that can help your team not only complete work within a Sprint but also enhance overall productivity and satisfaction.
1. Establish a Clear Definition of Done
First and foremost, having a Definition of Done is crucial. This isn’t just a box to tick; it’s a vital tool that clarifies what “done” actually means for your team. Without this, how can anyone know how much work they can realistically take on during a Sprint?
- What to Include: Your Definition of Done should encompass all the necessary criteria that must be met for a task to be considered complete. This could include:
- Code reviews
- Testing requirements
- Documentation updates
- Deployment processes
By having this clarity, every team member can align their efforts and understand the expectations, which ultimately leads to a smoother workflow.
2. Avoid Overcommitting
Next, let’s talk about the tendency to take on too much work. It’s a common pitfall that many teams fall into, believing they can fit a certain amount of work into a Sprint. However, this approach is fundamentally flawed.
- Reserve Time for Other Activities: It’s essential to account for various activities that need to be completed during a Sprint, such as:
- Paying back technical debt
- Addressing production issues
- Fixing bugs
- Implementing small customer-requested changes
By reserving time for these activities, you create a buffer that allows your team to handle unexpected challenges without derailing your Sprint goals.
3. Prioritise Refinement
Finally, let’s discuss the importance of refinement. Many teams mistakenly believe that Agile means they can forgo planning altogether. This couldn’t be further from the truth. In fact, you need to engage in more frequent and effective planning.
- What Refinement Involves: This process includes reviewing the product backlog and ensuring that upcoming tasks are appropriately sized and understood. Key activities include:
- Breaking down larger tasks
- Identifying dependencies
- Anticipating potential blockers
By looking ahead and addressing these elements, you can significantly reduce the risk of surprises during Sprint planning. For instance, if you discover that a firewall change requires a six-week lead time, you’ll want to address that well in advance rather than scrambling at the last minute.
Conclusion
In summary, if your team is struggling to complete work within a Sprint, consider these three strategies:
- Define what “done” means to ensure clarity and alignment.
- Avoid overcommitting by reserving time for essential activities.
- Prioritise refinement to anticipate and mitigate potential issues.
By implementing these practices, you’ll find that work fits more seamlessly into your Sprints, leading to a more productive and harmonious team environment.
If you found this post helpful, I encourage you to engage with me. I always welcome comments and discussions about Agile, Scrum, or DevOps. Feel free to book a coffee chat with me through Naked Agility. Let’s continue the conversation!
Number one, have a definition of done. That would be great, right? Know the amount of work you need to do in order to get to done. That’s part of the purpose of the definition of done. How do you know? How does every member of your team know when they’re thinking about how much work they can take on in a Sprint? What they actually need to do to get there, right? That’s your definition of done; it helps enable that.
So also, the second thing is probably stop taking on too much work. That’s always a good one. Most teams will take on the amount of work that they feel will fit in a Sprint, and that’s wrong, right? You shouldn’t take on the amount of work that should fit in a Sprint. You need to think first about how much time you need to reserve for other things, okay?
So there are a number of other things you need to reserve time for in the Sprint. One is how much time do you have to spend paying back technical debt? That’s one. Perhaps you’ve got some refactors or re-architectures to do. There’s work around that. Perhaps there’s been some production issues, and you want to go figure out and rework some of the way you’ve done things in order to make those production issues less likely. There’s a bunch of work. Perhaps there’s just some bugs you need to go fix. There’s things that customers have asked for or feedback that are small things. You’d never have a whole Sprint just on those things, but you’ve got a bunch of stuff there.
And then you need to think about how much work do you think is left in order to fulfil your Sprint backlog. This is your net new work that goes towards your Sprint goal that you’re going to do in the Sprint. So this is the high complexity work. Usually, fixing above can be really simple or it can be really hard, right? You don’t know, but all of net new functionality is generally really complex and very unknown. So you need to have enough space to take on a piece of work that might expand to fill that space, right?
And there’s one thing, which is the third thing that I’ve not talked about, and that’s refinement. How much time do you need to think about refinement that needs to be reserved? Because the third thing, refinement, you need to understand the future to some degree, right? A lot of folks talk about, “Oh, we’re doing agile; we don’t need to do planning anymore.” That’s crap. You need to do more planning and more often.
One of those things that we do, we call refinement, which is any work that you do as a team that is looking at the product backlog, not adding capability to your increment, right? So if you’re looking out into the future and you’re saying, “What are the things that are coming up in the backlog? Are they the right size? Maybe we need to break them down. Do they have dependencies that we need to plan for?” Right? If you get into Sprint planning and you realise that you need a firewall change that has a six-week lead time, you’re already screwed, right? That’s not happening this Sprint, even though that’s when it needs to happen because we’ve got this firewall change.
Whereas if we’re looking out six weeks into the future in our product backlog and anticipating, trying to anticipate as best we can, you’re never going to be perfect, but as best you can, what’s coming up that we need to deal with? Those dependencies, those different activities that we need to request stuff or do stuff, you know, could be servers, could be environments, could be all sorts of things that could get in the way. What do you need to know now? You can mitigate a lot of that by your Scrum Masters should be thinking about, “Well, why do we have to look out six weeks for firewall changes?” Well, it’s because this team over here takes six weeks to action a firewall change. Perhaps that’s something you want to go fix so you don’t have to look out so far on your product backlog, and you can bring that range in, right?
Because you want how far out you look to be minimal but sufficient, right? You’ve got that Goldilocks zone of how far do we need to look out, and you want it to be as short as possible. So any other activities you can do to make that shorter.
So those are the three things that a team who is struggling to get work completed in the Sprint needs to think about. You need to think about doing good refinement. If you understand things a little bit more, you’d be surprised how much more easily they fit in a Sprint. You need to not plan the whole Sprint; just plan the bit that you believe you can do and take into account those other activities that you need to do every Sprint. Don’t fill the whole thing; that’s mental.
And the other one was having a definition of done so that you understand the amount of work that is required to complete each thing. 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.