What are 3 things you would recommend for a scrum team who are struggling to get work completed?

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.