When is a task done? Let’s Define the Finish!

I love this question! Thanks, Superball. I’m excited to get into this one. I’ve even got fun pictures for you! Let’s get started.

Why do you need to know what “done” is?

Well, if you don’t, a bunch of problems can arise. These include:

• people spending too long on tasks since they think an asset needs to be shippable quality now.
• frustrations on team due to mismatched expectations. For example, when someone thinks they did a task, but someone else thinks it needs something more or less.
• bad time estimations leading to inability to predict when you’ll finish.
• confusion as to what needs to be in the next milestone and the quality bar required

How do you know when something is done?

It depends on the phase & goals & how you’re building your game. For example in prototype phase you don’t want shippable assets since you’ll probably have to throw them out when you find out that part of the game isn’t fun.

What to do? Create a shared language with your team. Then you all understand what you are asking people to do and everyone knows what to expect. It also makes defining deliverables to stakeholders WAY easier!

What I like to use is what I call a Degree of done chart.

What is that? Well, I’m glad you asked!

I start at DD0 and go up to DD5. If that’s too many degrees, change for what works for your game. When you’re at DD0 you need a LOT of imagination to guess what the final version of the game will be like. At DD5 it’s right in front of your eyes and ready to ship.

Let’s take a look at this in a bit more detail.

• DD0: is a document, sketch, concept art or other statement of intent.
• DD1: is a prototype with basic functionality, greybox or similar.
• DD2: is the basic working version of your game. It has some refinement on DD1 by having more content and features. At this point you can have a pretty good idea of what the game will be.
• DD3: is alpha. It looks a lot like the final game and has all the features, but you’re missing content and has a bunch of bugs.
• DD4: is beta. It’s super close to the final game. All the content is in, but it probably needs some polish and bug fixing.
• DD5: is shippable. There aren’t any blocking bugs and you’re ready to send it out to the public!

Each discipline will have a slightly different definition for their degrees of done depending on their pipelines and processes. For example, DD2 for level design is about having good flow. Whereas DD2 for narrative means some complete conversations with others only partially done.

 

What you choose for your definitions of degree of done will depend on your game, how you’re going to build that game, and how you define your development phases. To build a degree of done chart, your entire team needs to get on board with it. One person can create the basic definitions. Or you could start with my example chart that you can find here. Then get discipline leads to edit and sign off what what the degrees mean for their discipline.

How do you use this chart?

1. 1. On Individual Tasks/Tickets
      • The simplest way to use degree of done is as a property on your tasks or tickets.
      • When creating the task you specify that it needs to be DD3, or 0 or whatever.
      • Not only will the person who is doing the task know what quality they should be aiming for.
        • They will also be able to create more accurate time estimates to predict when they’ll finish the work.
      • On top of this it also helps everyone know what to expect as a deliverable when the task is “done”.
   2. You can also use degree of done To define your big milestones, builds, or other deliverables
      • For example, for a mid-production phase milestone, you might specify a certain percentage of assets need to be DD3. Or that only risky features need to be DD2.
      • As another example, in your alpha build the overall degree of done for the game should be DD3. But some disciplines will be further ahead or behind than that. You can write this out explicitly and then you all know what you’re delivering. For example Narrative at DD4, SFX at DD2 and so on.
        • This can help massively not just for the team internally, but for stakeholders including publishers. If you give them your Degree of Done chart along with your list of what items will be at what degrees of done, then there won’t be any nasty surprises for anyone. And oh boy do we love reducing nasty surprises on both sides when we’re working with publishers!
   3. As a visual representation of how finished an entire level is.
      • It becomes a tracking language that you can use to have a clear understanding of what’s been done and how much work is remaining. Like a traffic light system, but will extra stops along the way. This will help you figure out when some disciplines are falling behind or other disciplines are going too fast. You’ll know the game is shippable when everything is purple!
      • 

Final Thoughts

And that’s it! Degree of Done charts go by many other names and have many other structures. But hopefully my structure gives you a good starting point to figure out what’s right for your team.

Once you’d created your structure, you and your team will be able to discuss milestones clearly, will know what quality bar they are reaching for right now and can iterate on work with confidence until you’re ready to ship.

That’s all for today! 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