Project planning with Pivotal Tracker

I've been using Pivotal Tracker for my own project and I recently helped a mate get set up so that they can plan their first release, an awesome-sounding old-school multiplayer deathmatch game. I gave them a bunch of advice about how to use it and realised that I could do with having the advice written down for reference myself. So here are some thoughts about how to plan and schedule those features.

Break down many-tasked features

Features with a heap of significant tasks attached are a planning "smell" (meaning the indication that something is wrong). Consider breaking them down to smaller chunks. This will help you to both get a grip on what actually needs doing and get an idea of how long it will take.

Pushing the estimate length limit

If you find yourself setting a lot of estimates at 3 (the default maximum in PT) and thinking "I wish I could set this to 4...", this is a sign your feature is too big.
[Update] Dan P points out that Pivotal Tracker's default estimate range of 0-3 abstract points is completely customisable. I'd still recommend sticking to the default while you get used to writing good features.

Use chores to represent decision points, learning activites and setup tasks

If you're creating a feature and there are big design questions or technological unknowns, break them out into their own items. You should consider making them chores instead of features as they don't represent actual functionality. Any significant setup task e.g. setting up test environments, should also be its own chore.

Prioritise risky features

Adding simple, easy-to-implement functionality is good, but make sure that if you have features planned that have lots of unknowns that you prioritize work on resolving these. This doesn't mean you have to complete the risky feature, just that you need to get confidence around what it will take to build it. You could spend some time sketching the design, do some (time-boxed) research on how others did it or build a small spike solution. The aim of this stuff is to get to the point where you can confidently describe what it will take to build it and a rough guess of how hard it is. 

Features in progress

You will have a bunch of stuff currently in progress when you start. If it's small enough to be one feature, just create the feature and mark it as started. If it's a "super-feature" (to coin a term), such as "Art Theme X" or "Capture The Flag Mode", break it down into its component parts and set their status individually to 'done', 'current' or 'unstarted'.

Handle known tasks consistently

The asset creation process is often able to be broken down into repeating features for each super-feature. So, when you're creating an art theme, there might be: 'Concept Art', 'Room Textures', 'Props' and 'Playtesting' for each one. Name them consistently: "Nightworld - Room Textures", "Zombietown - Room Textures", and add an "art" and a "theme" label to each feature. If all the features are consistent, you can start to predict how long it will take to create a new theme based on how long it took you to do the last few. This data will be invaluable when you sit down to schedule the next three months' worth of theme releases.

Write feature descriptions

Partly this is an aid in communication across the team, but mostly this is because it forces you to think through what the feature actually entails, what value it actually delivers and how the feature might actually be implemented. Think of it as a kind of ninja design. The uncomfortable feeling you get when writing a detailed description is the pain of design and decision-making. You have to figure this stuff out eventually, but by doing this thinking up-front and early you'll save yourself all sorts of pain.

Write good feature descriptions

"Features" are things that make your game better. That is, they deliver some kind of measurable value to the players of your game, your customers. Try and write every description as if you're justifying the work to someone that's bought your game. A (slightly verbose) template to get you in the spirit of it: "In order to , as a < gamer / server host / power user >, I should < be able to do X >. You don't have to stick with this template, it's just a tool to help you get in the habit of framing your features correctly. If it's not improving your users' lives, maybe it's a bug, or a chore?

Keep your estimating light

PT's estimate values are limited by default to 0..3 points. Of course you'll want these estimates to be consistent across your team, but they are rough-grained and abstract for a reason: they are estimates. By their nature they are educated guesses. Remember, the more process you add, the more non-work you're doing, and the less likely you'll be to do it. Ask yourself, how much value will you get with more detail, and is it worth the extra weight? Just start, and be prepared to improve the parts of your process that aren't working.

Further information or ideas

Pivotal uses Scrum/Kanban methodology pretty religiously. You don't need to get deep at all on process, but a little process can help. Some further links:

1. Explanation of Kanban management
2. Example of a typical workflow
3. Howto get started with Kanban
4. Lostgarden on how to use design logs to document your game's design - an alternative technique worth considering for iterative gameplay development

Let me know your thoughts in the comments.