Diving Into Multiple Projects with Different Priorities

Today's blog is going to talk a bit about project management and how we're very soon stepping into the world of multiple projects (not necessarily multiple games, but multiple things between which we need to divide our attention). 

Early on in the company's existence, and up until this point, our development has been fairly linear. What I mean by that is that we were always prioritizing features and tasks that contributed directly to the betterment of Ultimate Chicken Horse, our first game. There was still prioritizing to do, of course, and making the decision to add online multiplayer about halfway through the development was a very big (and important) decision for the health of the game and company. 

As far as project management is concerned, this was a fairly simple task. Do stuff as well as possible, as quick as possible, without any real hard deadlines and always trying to make sure the next release has significant improvements (or bug fixes). What we did was we had a big backlog of features and improvements that we pulled from and put into our sprint, as we mentioned in a much earlier blog post. 

Now that we've started work on consoles, and we'll soon be thinking about a next game, we're going to have very different work to do and different tasks to prioritize. This is certainly more interesting and more fun, but also means that we can no longer stick with a single, static backlog and pull from the top of it without worry. The problem with simply having 3 backlogs, say, for UCH / Console / NewGame, is that nothing tells us what needs to happen first and when it needs to happen. How will we know to pull tasks from one backlog instead of the other if the priorities are all relative to other tasks within that backlog?

The solution that we've devised, which is probably standard for many people, is a milestone system that divides the backlog into key milestones. For example, the next milestone could be a new build for the PC version of the game with bug fixes and some new improvements, and the one after that could be console work and getting the game to be playable on them. Each of these backlogs will have tasks within them and will have a due date, and before each sprint, we'll look at how many tasks are left to determine how likely we are to finish before that milestone date. If we see that we have three weeks until the next milestone but we've done most of the tasks for it, we'll prioritize some tasks in the later milestone, or even some bigger tasks two milestones from now. 

So what does this do for us?

Project management is something we've obviously done and kept in mind, but as things ramp up and as we start working on several different things that have different requirements, we needed to find a solution to make sure that the work doesn't get messy. We're going to see how this new system works, and see how we feel about the process. Just figured we'd update you and maybe give some inspiration for your own projects... it's not always the most interesting thing, but project management can be an important ingredient to the success of a project!

As always, I'm curious to know what other people think of this and what processes you use for prioritizing across multiple projects and deadlines.