Tag Archives: basecamp

I’ve always been a fan of basecamp, and I’m pleased to say that we at WEIR+WONG are using it. It’s great for collaborative working, mainly because of it’s simplicity and the flexibility it offers. But you need to be disciplined, it’s easy to get mixed up with how to classify each type of target. What’s allowed for a milestone? what do you classify as a todo list? how complicated can a todo be? How can you use this in an agile way? So where does one start? Clearly, there’s a lot of ways to play this, so this is how I approach it.

Capture

what I find handy to start with is to just capture all your ideas on what objectives you’re trying to achieve, working as a team to create your initial list of todo items. Unordered. Unranked. This allows you to see the basic universe that your project exists in. This is akin to creating your product backlog, to borrow from Scrum a little. You’ll find that you get a whole bunch of what I term as tasks (single actions, such as “write strapline”) and projects (a set of related tasks, such as “create designs for pages”), at this stage, leave these as they are.

Prioritise

Before you try and set deadlines and milestones, you need to work out what’s really important for this project, you need to prioritise your list and for this, it’s vital that you have all project stakeholders present. I rank by business value and risk. High business value and high risk items should be tackled first, so an action, or rather mini-project like “prototype unused technology” would fit the bill here, whereas “Translate copy for phase 2″ would not. Next I would tackle the high value-low risk, then low value-low risk, and finally low value-high risk.

Projects vs. Actions

Using my 1 task = action and 2 tasks = project analogy, you can then start translating your prioritised list into todo lists (projects) and todos (actions).

Team estimates

As a team, you can then take your list and start working out key milestones by estimating how much work you can effectively achieve in each sprint, or, if you’re not using sprints, each set of deliverables. I’ve found that this can be one of the trickiest stages for those new to the idea of team estimates, so it’s often handy to time-box this kind of estimation activity to limit the amount of detail you go into. You can always come back and readjust your estimates once you’ve found your teams project velocity. It’s also a doddle to move any todo item around the page in basecamp, so it’s not like you’re over-investing your time in changing plans. Don’t forget, don’t get hung up in the detail here, your time is better spent doing work that’s of actual value, re-planning needs to happen later as more facts come to light, so no need to sweat that your estimates may be a little off.