📜 See all articles: Sitemap
⬅️ Previous Article: Sprint Overview
➡️ Next Article: Sprint Planning
Estimating is the process of determining how long a task will take to finish. It can be paralyzing--especially in the early stages of development. I'm going to give you the tools to conquer that paralysis and figure out how long your game’s most daunting features will take to develop.
In agile (see: Sprint Overview), people estimate tasks using something called “story points” (I’ll just call them “points” from now on). That’s a fancy way of saying they assign a number to each task to indicate how long it will take.
They choose from the numbers that make up the start of fibonacci sequence. You can follow that link for a comprehensive overview, or just know that the numbers (points) we care about are 1, 2, 3, 5, 8, 13, and 21.* While the fibonacci sequence continues past 21 (indefinitely), in this system, we only care about numbers up to 21. The rest are too big, and we prefer small numbers--in this system, they're a show of precision and understanding. I'll dive deeper below.
Each task should have an assigned number of points. These points represent the time and effort it takes to complete a task. For example, it should take you roughly the same amount of time to complete four “2” tasks as it does to complete one “8” task.
Before applying the points system to game development, let’s simplify this system through the lens of a weekly to do list.
*To keep track of these numbers, remember that each one is the sum of the two preceding numbers. For example, 1 + 2 = 3, and 5 + 8 = 13. Each number is about 60% more than its predecessor.
An Example
We're all familiar with to-do lists. I’ve written out a to-do list and assigned a point value to each task below:
To-Do This Week
Call Aunt Sally on her birthday: 1
Order new dog food: 1
Hang wall art: 2
Plan big group dinner: 3
Hang new light fixture: 5
Find a new primary care doctor: 8
Build first sprint schedule: 13
But what exactly do the points mean, and how did I come up with each number? To come up with the numbers, I thought about each task's complexity and time commitment. Let’s look at each example:
1s: The first two tasks require no thought and little time. You call Aunt Sally when her birthday rolls around, and you head over to Chewy to order dog food. They’re nothing tasks.
2s: Hanging wall art is a little harder, but not much. You just have to find and measure the right spot.
3s: Planning a big group dinner has more complexity: consider allergies, group preferences, and recipe research.
5s: When hanging a light fixture, you may have to contend with electrical wiring, and you might find yourself needing to run out to the store to get necessary supplies. You don’t know exactly what will go into it, and you don’t know how to do it.
8s: Everyone has faced the annoyance of switching doctors: lots of research, insurance stuff, appointment scheduling, etc. A real hassle.
13s: And finally, building your first sprint schedule! What a doozy. Lots of cascading tasks: figuring out people’s availability, making sure your tasks are estimated, and choosing the right tasks to put into it. Definitely a 13.
You can see how, with each increasing number, the complexity surrounding a task increases. As tasks get larger, there’s more that can go wrong.
The fibonacci sequence is great for estimating, because the gap between numbers gets larger and larger as they increase. This widening gap creates room for the uncertainty that accompanies complex features. Complex features have more component parts, they require more research (which can often be its own task—see below), and they require more tweaking.
Back to Game Design
Now let’s take the same approach with game design tasks. Let’s say that you’re in the business of 3D modeling and animation. You have to size a few tasks: creating rocks that decorate the ground, making a signpost that says “No turning back,” and designing Charles, a dog that wanders around sniffing everything, and the player’s steadfast companion.
The rocks are simple, especially if you’ve made similar environmental ornamentations before. Maybe a 3? The signpost is a little harder, since you’ll want it to look weathered and stylish. A 5?
But Charles is way harder. He’ll accompany you all game, so he’d better be great. Lots of detail, and lots of animation. Honestly… that’s more than a 13.
Let’s talk about Charles.
Simplifying Tasks over 13
If your task is over 13 (21+), it’s time to break it down. As we get into larger numbers than 13, we create unwieldy tasks that we either don’t have a good sense for or that can be broken down into smaller pieces—typically both.
Over 13, and you need to do some prep work. Let’s quickly sketch out a crude list of steps for creating Charles.
Concept art
Initial, blocky rendering of Charles
Texturing (making your blocky dog look more lifelike)
Adding animations
Perhaps you have familiarity with with the first two steps, and you can say that both are 3s. You’re also comfortable with texturing but know it’ll take you a bit to get it right—maybe a 5-8. You’re still a junior when it comes to animations, and you want to account for several animation states, so you list them out and decide they’re collectively worth a 13.*
Your unwieldy dog has now turned into a more manageable task group of 24-27 points. You can see more clearly how you’ll create Charles from the ground up. And you’ve identified that the ambiguity stems from animation, isolating your unknowns to just the last step.
This breakdown was simple, because our 3D artist had past experience creating and animating 3D objects. But what if they didn’t?
*Even though we can work with 13s, challenge yourself to break them down further. Tasks are easier to manage, and sizing is more accurate, when they’re smaller.
Tackling Advanced Ambiguity
You’re going to end up with tasks you don’t know how to do—which means you’ll end up with tasks you don’t know how to size. If you asked me how long it’d take to knit a wool scarf, I’d have to say “I don’t know.” But as with Charles, I can break down the problem into digestible steps:
Research: research the steps to make a wool scarf.
Acquisition: acquire the materials to make the wool scarf.
Experimentation: complete enough of the wool scarf that I understand the task pattern.
Completion: based on how long step 3 took, estimate how long the full scarf will take.
The first task is the key: research. Let’s drill into it.
Research Spikes
Research is a pretty common requirement in software development, where you’re developing a lot of features for the first time. You can add a “research spike” to your sprint to represent the amount of time you’ll spend learning about a new topic. I typically think of research spikes as being between 2-5 points depending on the complexity of the subject.
2-5 points is a good amount of work, so what all goes into that? Well, since you started the research because a task was ambiguous, you should end the research with a clearly documented path forward.
We know there are three steps ahead of us: acquisition, experimentation, and completion. We can’t size completion yet, because it requires the knowledge that experimentation gives us. It’s blocked. But we can plan for and size acquisition and experimentation:
For acquisition, you can make a materials list and identify a good place to buy them. Then the whole task boils down to going to a store and making a purchase—quite easy, little thought.
For experimentation, you can read up on scarf knitting patterns, figure out how much you’ll need to make to really get a sense of it, find tutorial videos, and capture all of that in a short document. Then you just follow the instructions you laid out for yourself—again, little thought.
We’ve gone from:
Research: 3
Acquisition: ?
Experimentation: ?
Completion: ?
to:
Research: 3
Acquisition: 1
Experimentation: 3
Completion: ?
You do research spikes in order to lower the complexity and ambiguity of successive tasks. Let’s consider the scarf-making project without the research spike.
First we’ll have to size acquisition and experimentation, so let’s do that. I don’t have much info, so I’ll just give it my best guess:
Acquisition: 2
Experimentation: 5
Completion: ?
So let’s get started with acquisition. To buy materials, you need to find a yarn store, and you need to make a list of items to buy. But how do you know what to buy? You’ll first have to do some research into scarf making. And you’ll need to know what pattern you’re working with to figure out how much yarn you need. And since this is a new trade for you, that involves a lot of forum diving, YouTube videos, and Reddit threads.
Now let’s say you’ve spent half a day going down rabbit holes, and then you realize you haven’t made a single step towards the actual acquisition of materials. You’re demoralized, because you’ve made no physical progress. Per the task’s description, you’re no further than you were at the start of the day. And you’re starting to wonder if “2” was too ambitious a size.
Scarves aside, I think we can all relate to being demoralized when trying to make a complicated decision. When the path is uncertain, and you’ve already spent a lot of time thinking, you typically either enter an analysis paralysis spiral or get fed up, say “enough,” and force a decision.
You can stave off this morale degradation by respecting research. Respecting research means acknowledging it as an independent and important task—and one that predates any new venture. It means that you respect the journey of the decision making process, not just the act of decision making.
Morale seep is particularly toxic for startups. If you’re a solo dev, your morale is the key to working hard and staying focused on your game. If you’re leading a team, their morale is crucial to their continued involvement and investment in your game. You’re probably not paying people much at this stage (if at all), and so a large part of their diet is momentum and morale.
One more crucial reason to research: it improves sizing accuracy. By definition, research adds context to successive tasks, giving you a better idea of their scope. As you learn more about what’s to come, you gain an understanding of the component steps to each task, allowing you to better estimate how long they’ll take. This has the additional benefit of lowering the perceived complexity of successive tasks, which is another big win for morale.
Capacity
Let’s take a quick detour to introduce the concept of capacity. Capacity’s pretty straightforward: it’s the amount you can get done in a single sprint, measured in points.
For example, if I have a capacity of 30 points/sprint, I can only take on tasks that sum up to 30 points. Otherwise I’ll be overburdened.
I cannot exceed 30 points, but sometimes task availability necessitates that I take fewer than 30. If I have four 8s, two 5s, and one 2, I can’t hit 30 points on the nose. I have to settle for 29 or 28 (8 + 8 + 8 + 5 = 29; or 8 + 8 + 5 + 5 + 2 = 28).
True capacity is objective—hard to determine, but objective—but the points system is subjective. How do we make it more objective?
Converting Points to Time
Up to this point, we’ve been more or less estimating on vibes. That works just fine if you’re three months into a project and have done lots of trial and error. You’ll have seen 5s and 8s before, and you can compare a task to those predecessors and comfortably say “yeah, this is a 5.”
But if you’re just beginning, you have no data points. So start by thinking about points values in terms of time.
To accomplish this, set an arbitrary number as your sprint capacity, and work backwards. Let’s say I have an effective sprint capacity of 21 points. I might think about points this way:
21 points: a full sprint (two weeks).
13 points: a little over a week
8 points: 3-5 days
5 points: 2 days
3 points: 1 day
2 points: half a day
1 point: an hour
That allows me to pick up a meaty 13 point feature and a couple 3 pointers, or it allows me to pick up a balanced assortment of smaller tasks. Remember: I can’t go over 21.
If you start playing with this math, you’ll quickly find that you can pick up less than two weeks of work and still hit 21 points. That’s okay. The easiest way to mathematically underburden yourself is to pick up a bunch of small- or mid-sized features. But as any seasoned multitasker can tell you, switching from task to task costs you mental energy, so it’s good to have a bit of padding when you have a long list of small tasks.
If you don’t know how long something will take, look back at two of the scarf knitting steps: research and experimentation. Consider how much you can learn about a new subject in just one day of Googling, or one day of messing around in Godot. Research and experimentation are cornerstones of estimating, just like they’re cornerstones of development.
Final Thoughts
Estimation is hard, and you’ll often get it wrong. There’s a reason they call it estimating: it’s approximate.
Don’t beat yourself up if your estimates are wrong, but do make sure you’re learning from your mistakes. At the end of each sprint, you’ll either have leftover work or leftover time. Make a genuine effort to figure out which tasks you under/overestimated, figure out what went wrong, and make the necessary adjustments to upcoming features you’ve already sized.
Now that you know how to estimate tasks, it's time to figure out where you store them. Learn more at Backlog Management.
📜 See all articles: Sitemap
Comments