Tracking your time on Solo Projects

Time Tracking in Agile Teams
If you have a team focused on a single project for a period of time, often the actual time spent on each task isn't a terribly useful measure. Much more important is velocity in terms of story points as it gives you just enough information to estimate accurately. It even allows you to calculate profitability of a project based on what you're charging per story point and what it's costing you by using the loaded weekly team cost including overhead allocation divided by average velocity in story points. So, even if you're doing fixed bids projects you can manage them using just stories, story point estimates and velocity. This also removes all of the trust issues that come up when you start measuring numbers of billable hours per week for each team member, estimated vs actual hours on a per task basis, etc.

Solo Time Tracking
I'm finding that just doing story points and velocity isn't working for my needs. During the course of any given week I might write an article for a publication, work on a presentation, do some tasks to manage my hosting setup, add some features to my framework, fix a few bugs, spend time chatting with a reseller about a new potential project, write a couple of proposals and do some heads down coding on 3-5 projects. Many of the projects I work on run as little as 3-10 hours (others run 3-24 man months) and for many of the small projects, the cost of quoting them and answering questions after delivering the code is equal to or greater than the actual programming effort.

I find story point estimating to be a good fit for any of the larger projects (anything over about 2-3 man days), but with so many different projects on the go at one time, velocity gives me a general sense of how much work I'm getting done, but it doesn't give me any sense of the profitability of the individual projects (especially the small ones). I don't even know how much of my time I'm investing in marketing, sales and improving my systems vs. working on client projects. In practice I'm finding that lack of information a problem as it's stopping me from identifying what clients and project types are most profitable and whether any of them are unprofitable and need to be restructured, re-priced or dropped.

The Problems With Tracking
If you're using time tracking as a personal productivity measure, a lot of the trust issues with asking your team to track their time go away. However, there are still a number of issues with tracking time. The biggest issues I've run into in the past are making it quick and simple enough to do that I'll keep it up and providing enough useful information that I'll be motivated to keep measuring and reporting.

A Possible Approach
I've been thinking a lot about what I want out of my time tracking and how I can manage it most easily. There are a few things that I'd really like to have. Firstly, I'd like (where possible) to have a ballpark sense of the size of my backlog. I'm not talking about estimating six months of work down to the nearest hour, but I do need a sense of how quickly I can turn around any new project based on the estimated effort and while it's a good practice to keep the backlog as small as possible, I don't want to turn away projects unless I *know* I won't have the bandwidth to knock them out. This is made a little tougher by the fact that often I'll start on a project and then not hear back from a client for weeks so I can't really estimate when I'll be working on a given project, but I think by distinguishing between "ready to code" and "suspended" projects that will both give me a good sense of my active backlog and let me track and push suspended projects (which are essentially work in progress) to manage both time and cashflow.

I also *need* to know for the projects I work on whether or not they are profitable. If they aren't profitable I need to restructure, re-price or decline them. If they are, I may want to market them more aggressively. Similarly I'd like to have a better sense of which clients and resellers are most profitable so I can bear that in mind when working with them in the future. Given that the primary cost of most of the projects is my time, for fixed bid projects I need an estimated effort, actual time spent and the price I'm charging for the project. With that I can run all kinds of different stats to get a feel for how better to use my time to maximize revenues while still achieving my other personal goals.

Recording time
I'm not sure the best way to do this, but here's what I plan to try in the office tomorrow (may have to modify when I'm on the road during conference season). For *everything* I do I'll assign it to a project. If there isn't a project for a task I'll create one. These give me the buckets to track overall profitability. A project is defined as something that either generates revenue or that I'm willing to spend money on (so it has business value) and that will require some internal effort to implement (which along with any third party costs will make up the cost of the project). Each project will have a reseller, client, title, start date, acceptance date and a revenue (either what I'll be paid or what I'm willing to spend on it). Every time I change status of the project I'll record that on the back as that only takes a moment and could allow me to get really good visibility on what slows down some projects if I ever dropped the data into a database and ran some scripts against it.

Projects will be comprised of stories. For smaller projects (where the stories are estimated at under 5 hours) those stories will really just be tasks with estimated hours, start date, completed date and accepted date (often it takes a client a week or two to look at a project I've finished in a day so I want to capture that as completed but not-accepted projects have an implicit cost in terms of working capital and mindshare). For larger stories (anything over a half day estimated effort), they'll just have a ballpark estimate of 1/2, 1, 2 or 5 man days (anything bigger than 5 days is an epic and needs to be broken into smaller stories to estimate). Just before I start on the larger stories I'll break them down into tasks with an estimate of between 0.5 and 5 hours each and will track actual time, rolling up the estimated and actual hours onto the story card as the stories are completed. Each task will have a start and end date (but not accepted dates - clients accept stories - not tasks).

This sounds like quite a bit of messing around, but in practice here is how it'll work. I get a new email or call asking me to do something. I see whether there is a project it can be associate to. If not I'll create a project card on a large index card and put that onto my project board (a physical cork board) in the "ready to start" or "suspended" column. Then I'll create a story card for the project. Either an epic ("spec and build new system for xyz co") or (if I'll be starting on it shortly or if it's really easy to estimate), one or more story cards with estimated effort of 0.5-5 hours or of 0.5-5 days. I'll put that into the "ready to start" or "suspended" columns on my story board.

When I'm free to do some work, I'll look at my ready to start stories and select a story (informally - I'll see what heuristics emerge over time). I'l put a card into "working" (moving its project into the "in progress" category if it isn't already), work (if possible) until it's done and then move the story to "done" after tracking the time spent (to the nearest half hour). On getting approval from the client I'll the put it into accepted where I'll keep the story until the project is completed where I'll pull all of the cards for the project and roll up the numbers giving me all of the time tracking information I need.

I really don't know how this will work, but I have a feeling it should be a good fit as the extra work is very minimal and it'll give me a lot of really good insight for improving the business. I'll run it for a few weeks, refine it as necessary and then write up an experience report on the blog.

Anyone else who has to juggle lots and lots of projects and tasks during the week? How do you *know* which of your tasks are profitable and that you should focus on? Input appreciated!