How to Get Your Team to Consistently Finish Sprint Tasks

Sprints: love them or hate them, they’ve become an integral part of how we make games these days. But what happens when your team doesn’t finish what was in the sprint? This is a massive topic and I’ll do my scratch the surface and tackle some of the most common culprits. I’m going to try and go both broad and deep.

So buckle up!

First Thoughts

Oooh…. A mystery!! I love a good mystery. And this seems like a classic game development mystery. Albeit that you’re not trying to find out whodunnit, you’re trying to find out what’s going wrong with your processes. To be super clear: I don’t believe in blaming people for these sorts of problems. It’s likely something about your process and if you can get to the bottom of that, then everyone will be much happier.

What I find super fascinating is the second part about the buffers not changing the situation. If people don’t know about the buffers, then why are they now taking much longer to finish tasks? Super curious. I kinda have no idea why that would be. If they do know about the buffers, then it’s probably because people often try to fill up all available time, but then misjudge and actually go over.

Note: I’m going to focus on sprint deadlines which can be controlled by the team rather than milestone-deadlines which usually have external stakeholders which makes things more complicated. Also I’m barely going to scratch the surface of what could be going on and ways you can fix it. And even then, it’s going to be a long video. So let’s get into it!

Here are the most common categories of reasons that sprint deadlines are missed.

1. New tasks appear.
2. Individual tasks take longer than expected.
3. Team or team member issues.
4. Project management issues.

We’re going to look at each issue in detail and talk about what production can do in different cases. It’s likely that what’s going on is a combination of multiple components. So you’ll have to pick and choose what seems right for you and your team.

1. New tasks appearing

In this case, people technically could finish everything they commit to for a sprint. But new tasks pop up in the middle of the sprint, so suddenly the team can’t finish what they planned.

If this is happening you should look at what are the types of tasks popping up.

• Are they sub-tasks of the bigger tasks?
  • This might indicate that the tasks weren’t specced up well enough.
  • If you find this, stop work on the task and wait until it has been specced up better. That might involve creating a dedicated speccing task to predict those sub-tasks and understand the full scope better.
• Are the new tasks due to things external to the team popping up? Like demands from publishers, players, or high up stakeholders.
  • This can be super hard to manage and I can’t really go into depth on this in this short video.
  • I will say that creating a realistic risk register can really help here. A risk register aims to predict the unpredictable and create mitigation plans so that when the risk occurs you know exactly how to handle it.
    • Usually risk registers focus on big risks that affect major milestones. However, you could create micro risk registers that just look at what could come up in this sprint and what you’ll do if that does come up. That way you can allocate explicit buffer time to address those risks.
    • See my example risk register in Notion for more information about what risk registers are.

Once you know what type of tasks are popping up, you need to consider: Do these tasks actually need to be finished this sprint?

• If they don’t, then a better triage system is probably needed to push some tasks into future sprints.
  • That might mean all tasks go into a single bucket. Production triages them during the sprint. Others don’t see them unless finished with other work or it’s deemed high priority.
  • You could choose to shield the team from these tasks entirely so they don’t get distracted, but that can come across as being too controlling sometimes.
• If the new tasks do need to be done this sprint, then you could try and tackle it from two different directions:
  1. The basic option is: When setting up your sprints, don’t fill them up with all the known tasks. Leave 1 or more days to deal with these unknown tasks that pop up.
     • You can even explicitly schedule those random tasks. In your system you’d call them them “Random 1”, “Random 2”, etc.. Then during the sprint when something comes up put it in one of those slots, ie. “Random 2” turns into “Fix animation of Jane NPC”.
     • If you run out of slots, then learn from that and create more slots next time.
  2. Predicting risks better. Recognising when you’re doing risky tasks that might generate more new tasks.

2. Individual tasks take longer than expected.

This could be due to a few reasons.

Unpredictable new tasks.

• In this case all the tasks that are taking longer than expected are new tasks and you can’t predict how long they’ll take. Best way to handle this is to experiment more.
  • Try out different pipelines.
  • Try to break down tasks into small chunks that don’t take longer than 1 day.
  • Timebox first time tasks. That is say: in this sprint X hours will be spent on this task. If the task isn’t finished in that time, then at the next sprint planning discuss it and figure out how much time to allocate next sprint.
  • Consider if this task has any similarities to previous tasks.
• Use past history as soon as you’ve completed one task to know how long the next similar one will take. The first time you do something it will take a really long time as you figure out how to do the task. The second time you have already answered a bunch of questions so it’s quicker. Eventually you’ll have worked out a system for this type of task and will be able to accurately predict how long it takes.
• BUT… What if the majority of your tasks are new tasks? Then you’re probably not in production at all. You’re still figuring out what to do. And trying to predict what you’ll finish in a sprint is likely to always be wrong. I’ll discuss this a bit more later on.

Non-optimized asset creation pipelines.

• How are assets being created? Does everyone know all the steps? Follow through the entire process from idea through to in-game asset. Ask respective departments how they do their work.
  • As a producer you can do this on your own or it can be useful to do this as a team since another team might see something they can do to support another team better. For example: automation, doing an extra step that’s easy for them and hard for someone else.
• You’re looking for anything that can be done to speed up the process.

Tasks don’t have all information needed to complete them.

• This has already been partially covered, but here I’m talking about the case where some other department (like design) hasn’t provided all the information needed for someone to finish their task.
  • For example, the task is for an artist to draw concept art for a character, but they don’t know anything about the character.
• When this happens, people don’t know what it is they’re agreeing to finish within the sprint or they get part way through a sprint and suddenly are blocked and have to wait to hear from another department before they can continue.
• In this case, it’s important to make dependencies clear. The task shouldn’t be started until all relevant information has been gathered. You can create a different task for the other department to prep this task in the previous sprint. That is, you’ll create a waterfall system so that the spec is written fully before you even get to sprint planning for the main task.

People don’t know what done is. So they spend too long polishing the task.

• Are you creating final assets? Or is it just a sketch? There is a massive range of what done would be for those two tasks.
• Set expectations of what the degree of done looks like for this phase of development in general. Check out “When is a task done? Let’s Define the Finish!” (blog post, video, audio) for more information about how I like to set up this system.
• Many people don’t want to call it done when it’s not perfect. But telling people you’ll come back to it can help them get used to “unfinished” work.
• Ideally you’ll have time to come back to these assets later on to do another pass and eventually polish them.
• Sometimes when you come back to do polish after a break on those assets, you realise that many things are already good enough. So you don’t have to spend that time polishing them at all.

3. Team or team members are having issues

This is possibly one of the most complicated reasons and ways to solve this are super diverse and things can descend into the unhelpful blame game way too easily.

Team Size Unsuitable

• Do you have the right number of people on the team?
  • Too many could mean that there’s too much overhead and communication isn’t clear.
  • Too few might mean you’ll never finish what you want in a sprint since you don’t have the manhours.
• To fix this consider what each person’s role is on the team and how essential they are and how big their workload is.

Pipeline related

I’ve already mentioned pipelnes and finding out ways to optimise them. This point now is another facet of that and has two things of note.

• Is one person a bottleneck for a process or processes? If so, think about how you can support that person. Can you change the pipeline? Can you hire someone else to do the same work? Can you reduce how many assets use this pipeline?
• Another team pipeline issue could be whether people know who to send their tasks on to next. Are tasks getting stuck in limbo?
  • Make sure it’s clear what to do when they finish their part. One easy fix for this is to change your status names from what has just been done to listing what stage it’s ready for. For example, instead of “Art done” change it to “Ready for Animation”

Denial or Wishful thinking

This is where the team or individuals don’t recognise they they never finish everything they wanted to in a sprint. They aren’t facing the facts.

Get people to really think through exactly what they’re committing to. This might mean they need to do some planning and research before you get into sprint planning calls.

In most group settings, no one wants to say “I can’t finish that in a sprint” since seems like they’re not a team player. To counter this you’ll have to try and effect a cultural shift where it’s not just ok to say no, it’s necessary.

Team Apathy

Are you in a bad cycle? Have the team missed so many sprint deadlines that they just expect that and don’t even try anymore? Perhaps they think it doesn’t matter since unfinished tasks just go into the next sprint, what’s the big deal?

Well…. what is the big deal?

Why do you need to meet your sprint deadlines?

What are the consequences of not fitting everything into your sprints?

Try to make it real. I assume that eventually features or content will need to be cut unless you can increase your budget and timeline. You can make this super explicit by showing people your roadmaps. Show what’s at the end and explain how this specific feature or level that everyone loves will have to removed if you keep missing deadlines.

Team doesn’t like each other

• Are there simmering tensions? Open bickering in group meetings? Are some team members ignoring what other departments need or want?
• This could cause sooo many big issues that it’s impossible to go into them today.
• But if you can recognise that this is the problem it will get you to go down a route where you might need to bring in HR or support from elsewhere to help the team work together better.

Work cadence & preferences issues

What I mean by this is how people’s schedule and physical space can affect their work.

• How does each person on your team work most effectively? Likely it won’t be the same for everyone and you won’t be able to accommodate their needs.
  • Some people want to arrive early, some stay late.
  • Some want meetings broken up so they don’t rush from one to the next, others want them chunked so they get big open periods where they can just get work done.
  • Some people like background noise while working, others don’t.
  • And there are so many other factors here.
• Ask your team members individually (not in a group) how they like to work and how they would like you, the producer to support them.
• Then figure out what you can do to support this. Try not to always inconvenience the same people. This might mean you have a rotation of different styles or something.

Individual’s personal’s issues

If it’s an individual who’s the main problem: find out what’s happening with that specific person in a 1:1. What are they doing instead? What are their motivations?

• Be Jennuinely curious about what’s going on with them.
• Maybe they’ve been hiding a sickness, solo-parenting, or something else that’s external to the team.
• Maybe it is something in the team itself. Is it the type of tasks they’ve been given? Or maybe they feel like they’re not being listened to.

Finding out what’s happening for them will hopefully help you find a path forward to help and support them.

4. Project Management Issues

The final bucket of reasons why sprint deadlines are getting missed is somewhat just a catch-all for all for everything else.

Time prediction issues

There are many different ways to predict how long a task or group of tasks will take to finish. Whatever your system is, make sure you predict the time lost to meetings, illness, and more. Estimates of how much can be done can vary widely from 60-90% depending on the person and their role. It’s never 100% though. So if someone estimates that their tasks will take exactly the same number of days as are in the sprint, then it’s highly unlikely they’ll actually finish.

• You should be using past history to help gauge future sprints.
  • Regardless of how you estimate sprints, try to turn that into a single number that represents amount of time or work done for a sprint. Note that down.
  • At the end of the sprint, check back and figure out the single number of how much was actually finished.
  • Over time, this history will help each person understand when they’re being too ambitious.
  • NOTE: This should never be seen as a competition. How people make estimates is personal. So one person who finishes with a 20 score might have completed the same amount as someone who finishes with a 5.
    • Due to this try to keep the numbers private so they’re just for an individual to help them learn how they work and make estimates.
• Your goal as a producer is to use the new predictability to start loosely extrapolating what can fit into sprints and understanding you won’t make a deadline that’s over 2 months away.

Time predictions definitely get into that sticky second part of the original question about buffers. You could lie to your team about when something is due. But if they catch you out in that lie then they’ll never believe you and you’re just back to where you were.

Do use buffers for long term planning, but I’d be super cautious to use them in sprints. It’s better just to encourage people to put less into sprints or reduce sprint duration to help focus people.

Unrealistic milestone goals.

If you’re pushing to reach a big milestone, you can work backwards and figure out what needs to go in multiple sprints to be able to reach that milestone. But if your big milestone is too big and needs too much stuff, you’ll never be able to fit it into sprints. As a producer, don’t wishful thinking fill in what will happen in future sprints. Be realistic.

If your calculations show that you won’t meet the big deadline, call that out. Talk about ways to address that by either reducing scope or reducing polish or something else.

Bad sprint planning

• Who decides what is going into a sprint? How much can an individual push back on that?
  • Individuals should be empowered to say no, that can’t be finished this sprint.
• Is there enough time allocated to end of sprint routines? You can adjust the official duration of a sprint so that there is explicitly one full day for wrap up and start up tasks.
  • For example, if you have a two week or 10 day sprint, change it so that it’s 9 days. If everyone is in the same time zone, you could set sprints to finish Friday at lunch and the new sprint doesn’t start until next Monday at lunch.
  • With that extra time you do retrospectives to learn what went well in the last sprint. And then you do sprint planning by discipline so that each individual gets time to really look at what they’re committing to and agree to that.
  • You could also use that time for kickoff meetings for new features or content as well.
• Another way forward could be setting some tasks as “bonus” tasks for the sprint.
  • That is, you make the core tasks that someone needs to finish very, very small so they’re basically guaranteed to finish them. And then you have a few bonus tasks that might not be done.
  • In this case you have a predictable amount of tasks finished every sprint and it will help people feel that sense of accomplishment for doing everything on their task list.

Decision making issues

• If decisions are being made well, it can suck up team time in meetings, cause work to be blocked, and in really bad cases cause finished work to be thrown out.
• Are you meetings efficient? Are decisions getting made in a timely manner?
  • If not, look at improving your meetings. I’ve already done a post on that, check out “How to have Productive Meetings” (blog post, video, audio).
• Once a task is finished, is it actually finished? Or does it get re-opened later on and need to be re-done.
  • Setup an explicit review process at key stages in your pipeline. Allocate time for fixes after a review.

Upper management and creative director issues.

This is the case where there’s constant change of direction from up high. This could cause new high priority tasks to come in from out of the blue. I’ve discussed this in a separate post: “How to deal with an indecisive creative director” (blog post, video, audio)

Conclusions

Thanks for sticking with me so far. I promise we’re getting to the end.

One big question that I’ve not fully spoked about so far is: Are you actually not in production when you think you’re in production?

• In production you should have a well-oiled team that can pump out new content aka assets. In production you know what you’re creating and execute on the plan.
• In pre-production, you’re not really sure what you’re making and it’s the first time you’re trying to make it. You can’t predict things well and if you try to you’ll drive yourself a bit crazy if you’re not using timeboxing.
• You might need to take a step back and put back on a pre-production mindset.

Remember you want to get to the bottom of this juicy mystery.

• You might need to try a big reset or micro-management both to get to the bottom of what’s going on and then in trying to get things back on track.
• Importantly: You don’t have to solve this on your own! Have retrospectives to gather information from everyone. Get everyone invested in improving finishing what’s in a sprint. Make it personal pride, but without blame if there’s failure to meet the next sprint deadline..
• If a lot of different issues are coming up, focus on one thing at a time. Get that working and then move on to the next issue.

With support from your team and management, you can solve the mystery and create successful sprints!

Best of luck, Indie Producer

Remember: This is general advice and it might not be right for you and your team, even if you’re the one who wrote in the question! For me to help better, it needs to be a dialog between me, and you, and your entire team. You can hire me to consult for you —> jennsand.com .

If you have a question for me, just fill in my form over here: jennsand.com/askjenn/