In my last post, I talked about critical mechanics and how to use them to prioritize work. In this post I want to talk about an easy way to turn a critical mechanic into a task list using a very simple concept: the use case.

In my last post, I talked about critical mechanics and how to use them to prioritize work. In this post I want to talk about an easy way to turn a critical mechanic into a task list using a very simple concept: the use case.
One of the hardest aspects of managing game development is prioritization. And nowhere is prioritization more difficult than in the earliest days of a project. If you don’t know what your game is, how the hell are you supposed to prioritize the work? I’ve struggled with this problem in the past and eventually ended up stealing a solution from the start-up world in the form of something I like to call “critical mechanics.”
One of my favorite quotes revolves around planning. It came from Helmuth Von Moltke, a 19th century German Field Marshall: “No plan survives first contact with the enemy.”1. The implication here is simple enough: the plan that makes total sense on paper quickly falls apart when confronting the entropy of reality. And yet planning is essential for getting a team moving in the right direction. As Dwight Eisenhower said, “I have found that plans are useless but planning is everything.” And thus we arrive at what I like to call the paradox of planning: planning is the act of creating something that is simultaneously infinitely valuable and completely worthless.
In Part 1 and Part 2 of this series, I talked about the functional issues of scrum. In this post, I want to talk about the larger, economic problem with scrum. Namely, what was once an idea designed to support other industries has become an industry unto itself. And with that comes what economists would call a “conflict of interest.”
In the Part 1 of “The Fancy Mess of Scrum”, I talked about the flawed intuition behind sprints: how they batch work, obfuscate inefficiencies, and are superfluous in terms of extrinsic motivation. In this post I want to delve deeper into higher order negative externalities that sprints spawn – the consequences of the consequences.
Back in the heady days of 2010, I was a newly minted scrum master, fresh off my training seminar. I was excited by scrum’s potential, but I also took care to maintain some agnosticism. I always told people that scrum was the best production framework I’d seen, but that I would happily kick it to the curb as soon as I found something better. With several more years of experience under my belt, I’ve come to the conclusion that there are, in fact, better ways of managing development. And with that understanding came the further realization that I want to leave scrum behind.
GDC 2017 was my first GDC ever. So, I figured “Why not be an asshole about it?” and signed up to give two presentations. 6’ish months later I found myself at GDC, sweating bullets and shitting bricks. I should also mention that the longest presentation I’d ever given was about 10 minutes, and had signed up for a total of 90 minutes of speaking time. Anyhoo, both presentations went well and nobody died. And then, a month and half’ish later, my compiled speaker feedback arrived. It was largely positive. But, of course, there were a few people (4 in each session, based on the reviews) who took umbrage with ol’ Justy. And some of the negative comments bothered me. Not because people disagreed with me (that’s to be expected, after all) but because I couldn’t respond. But then I realized that not only could I respond (having a blog and[…]
1947. Japan, still reeling from the Second World War, lies in economic ruin. And a little company called Toyota finds itself in a highly undesirable strategic position. It’s headquartered in a nation in tatters, and competing with companies in the world’s newest economic super-power: ‘Merca. How could it possible compete against companies with such amazing access to capital, resources and cash-rich customers? Well, necessity, as they say, is the mother of invention. And the necessities of Toyota’s strategic realities gave birth to one of the most remarkable feats of management ever achieved: the Toyota Production System. Or, more generically, “lean” development.
This post is a bit of a capstone. It utilizes all of the tools to make video games scientifically that I covered in the Parts 1-6 of “Game Planning With Science”. Make sure you’ve reviewed those weighty tomes before digging in here. In this post, I’m going to walk you through how to utilize capacity charts, story points, user stories, variance, and the central limit theorem to forecast development time lines.
There’s a saying in data science: Garbage In, Garbage Out (or GIGO, if you prefer). The most advanced formulas and models won’t provide outputs worth a dead cat if you don’t have high quality inputs. When it comes to something as difficult and uncertain as feature planning and estimation, that’s quadruply so. In this post I’m going to walk you through the system I’ve used successfully, how it works, and why. And it’s all based on the counter part to the story points from Part 5, user stories.