If you are trying to create an estimate for a new project and are having a hard time, don’t lament your lack of historical data. The best thing you can do is to set up a system for tracking time on your projects. Today’s time log is tomorrow’s historical data. (When I say “you” I mean either you, singular, if you work alone or you, plural, to refer to your project team.) Do the best you can on this estimate, recognize that it’s probably a bunch of nonsense, and move forward.

Before you start working on the project you just (mis-)estimated, plan how you’re going to track time spent on it. This doesn’t mean you have to establish the Time Tracking Committee, hold a dozen meetings every day, and publish a seventy-page document describing how time will be tracked. Just pick a solution and spitball it past your team. Lightweight is best for a first pass, you’ll be able to get a feel for what works and what doesn’t in your situation.

Some things to keep in mind:

• You might work a nominal eight hour day, but you probably spend less than three actually working on your project. Meetings, support for previous projects, and the water cooler suck up a lot more time than you realize.
• Some meetings are directly project-related (design review, etc) and should probably be charged to the project. Oooh, I said “charged”. Don’t get too uptight about applying all of your time to one bucket or another. Keep it lightweight and easy to implement and you’ll increase the likelihood that you’ll be able to stick with it.
• Spreadsheets can be a convenient way to track time for individuals or small teams. If a team is going to use a spreadsheet-based solution, take a look at Google Docs and set up a shared spreadsheet.

At the end of the project, you can compare the actual results to the estimate you made. Disappointing, eh? Don’t worry, you’ll get better with practice and as you build a data collection.

See also Software Estimation: Demystifying the Black Art, by Steve McConnell. This book is an excellent resource.

What do you use to enter time / activity data into your tracking tool?

If you don’t use time tracking, is there a specific reason or is it just not something you’ve considered?

What if you could enter activity data through twitter or similar services?

Lastly, how much does the ability to (selectively?) share your activity data with others on related projects affect your choice of method?

Thanks for your response!

Two answers:

1. Because it feels like an extra step. If you want to change a behavior like time tracking, you have to make it automatic. Developers and other project members are already too busy, you can’t just ask them to add another step to their daily workflow unless the benefits are immediate and obvious. The benefits of time tracking are not immediate and obvious — it takes some time (granted a small amount of time) to reap the benefits of time tracking.
2. Second, they perceive a risk. Even if the software is free (they are providing a 30 day free download), there’s the risk that you spend an hour or two (or more) downloading and fiddling with the software only to discover that it won’t work in your environment for one reason or another.

To use concrete examples from my recent experience:

1. I’m developing in Python. I’ve used Pylint in the past and it has been helpful in pointing out bugs before I start testing. I want to use Pylint on my current project, but I keep skipping it because it feels like an extra step and I’m trying to get work done, not fiddle with extra tools. The solution is for me to integrate this tool into my workflow so that it is automatic and not an extra step. This is what I’ve done for the current iteration and I expect that it will stick.
2. I’ve recently been using more social media sites like twitter and I read about a toolbar for Firefox from Minggl. Sounded interesting and after I saw a few mentions of it I decided to give it a whirl. There should be a warning: “roadblocks ahead”.
   1. They make you register to download.
   2. The registration form does not allow periods or spaces in your last name, so it took a couple of tries to register. (This smacks of ethnocentrism! I am being oppressed because I have a period and a space in my last name!)
   3. It doesn’t work on linux… bummer.

   Contrast this with the experience of signing up for something like twitter or Mahalo Answers. You sign up (albeit with the gotcha of only allowing alphabetics in the name) and you start using it immediately.

1. Get the requirements right. It’s so often repeated that it’s almost a cliché to say that requirements errors will cost 10x or more to fix during coding or testing. But it’s true, so I can risk repeating it here. Spend a little more time getting the requirements right, and you’ll get every second back, with interest during the testing phase. The risk here is overanalysis, but if you tend to be the impatient type — jumping into design or coding with very thin requirements — then you’re unlikely to suffer paralysis.
2. Get the design right. It doesn’t have to be an elaborate 500 page document. One of the best designs for a complex system that I’ve ever seen was a state machine described in a two-page document with a big matrix on the first page. Remember, a written design is a communication tool. Just like the rest of your software, it can be the simplest thing that will work. Marker on a whiteboard works, if your team decides that is an effective way to communicate. An extra hour spent preparing and reviewing the design will save at least two hours in testing. Really. I’ve seen too many designs that were rushed (and clearly broken upon review) because of an unexplainable urgent desire to get a document into review so that coding can begin. The state machine I just mentioned went through probably 20 man-hours of reviews in maybe three passes, and we must have found at least 50 defects in it. Those defects took a few seconds each to fix (some may have taken a few minutes), but if there had been code and tests based
   on this broken design it would have taken hours to fix some of them.
3. Get the code right. I used an Extreme Programming mantra above (“the simplest thing that will work”), but I think XP overall often leads to bad practices — primarily an overemphasis on testing. I agree that automated regression tests are a valuable tool. However, it is important to recognize that testing has limits. It takes an immense effort to achieve full branch coverage, and even this can’t be considered “complete” testing. Testing must be used in conjunction with other tools: code review and static analysis are two such tools for removing defects from code. And before you’re at the point where code is ready for review or even the compiler, take the time to consult a reference when you’re unsure how to use an API. I don’t know how many bugs I’ve fixed (including some of my own!) that were a few lines down from a /*TBD: how is this supposed to work?*/ comment. Instead of putting in that comment, take the time to figure out how it is supposed to work.
4. Get the tests right. Ever waste time on a bogus bug report? Testers telling you a feature is broken when they’re just doing the wrong thing? It’s not their fault if you failed to communicate how the feature is supposed to work. In the same way your test team should be insisting on some written communication from you about the feature set, you should insist on some written communication from them about what they’re going to test. Again, this “test plan” doesn’t have to conform to an ISO/IEEE standard that requires it be 1200 pages long and six inches thick. Like with the design, a whiteboard works just fine. Whatever communication method you use, if it helps head off problems then it is working. If you’re finding too many problems late in the game, then maybe you need to have something a little more formal — try posting short documents to an internal wiki.
5. Are you keeping score? A little bit of measurement can do great things for you. I track time, lines of code, and defects. I was reviewing one of my designs this morning and this data helped me decide: (a) how many defects I should expect to find in my design and (b) how long it should take me to find those defects. All because I have historical data that tells me how many defects I find per hour of design review, and how many defects I make per hour while designing. I also know how much testing time this is likely to save… so I don’t feel any particular rush to start coding from a buggy design. I’d rather get the design right first.

As I mentioned above, the risk to getting into the habit of waiting is that you spend too much time analyzing the current phase and don’t just get on with it. But if you start from good requirements, it should be obvious when you’re done with design and coding. And if you’re keeping score, you’ll know how much time to devote to reviews to keep them efficient.

Here are eight reasons why you should use a time tracking tool:

1. Gather reliable data for future estimates. You can’t make accurate estimates without accurate historical data. If you try to create estimates using a simple count of days spent working on a project, you’ll be way off because so much time is lost to non-project activities (like supporting the last project you were on). A time tracking tool keeps an accurate record of how many hours you actually spent working on the project.
2. Eliminate time wasters. When you start tracking time, you’ll be surprised how little time you spend working on your current project. You can begin to pay attention to the low value activities that come up during the day. Awareness is the first step, then you can start to reduce or eliminate these time wasters so you can put more time into your bottom line.
3. Evaluate new practices. Without good time data you have no idea if the introduction of a new practice or process step is helping or hurting. For example, say you move to performing code reviews online instead of on paper. You may have a good idea of how much money this will save in terms of ink and paper, but you have no idea whether it is actually faster. (I’ll soon have a post on why defect tracking is important too — evaluating new practices is a key benefit there too.)
4. Find areas for improvement. When I first started tracking time I realized the vast amount of time I spent in unit testing — even worse, sometimes in system testing. I made a conscious effort to slow down when doing design work and it paid off. Hasty designs end up requiring a lot of rework during test. Your situation may be different, but you won’t know until you start tracking where in the lifecycle your time is consumed.
5. Improve reviews. An effective review finds more defects per hour than an ineffective review. You can’t tell the difference between effective and ineffective reviews without having the time component. This is sort of a subcategory of finding areas for improvement. For example, I know that my personal design review is about 4x more effective than unit testing, and slightly more effective than my personal code review. In a team context, knowing your team’s defect removal rate during inspections is an excellent way to justify the investment in review time to upper management. This is why a team-wide time tracking tool is important.
6. Evaluate new tools. Too often, the process of deciding whether a new tool is going to work is based on watching the salesman demonstrate the tool on the projector in a darkened room, and then some haggling by upper management. Sometimes you get a 30 day eval, but in terms of a test drive, this is really just a spin around the block to see if it “feels nice”. It’s much more useful to be able to know that a given tool actually increased productivity by 8% during the eval period. This also provides leverage during the aforementioned haggling when the vendor is claiming 77% productivity gains…
7. Know when to quit. Ever had your manager say, “Don’t spend more than an hour on it.”? Ever blown the afternoon after hearing such a request because you just couldn’t put it down?
8. Improve visibility. You can generate better upwards-facing status reports with a good time log. Remind your manager that the reason you missed the Friday deadline is because the VP of Engineering retasked you for all of Tuesday and Wednesday on his pet project. She can then show your status report to the VP as a reminder. (And oh, by the way, she can also show it to the VP of Marketing and CTO/Founder who’re screaming about the missed deadline. Yes, your organization is not the only dysfunctional group out there.)

For all the pointy haired bosses out there, here are a few reasons to not use time tracking to compare employees based on productivity.

1. It’s easy to game the system. You can enter fake data. This will, of course, screw up estimates and make it impossible to use the data for any kind of overall improvements. Developers need every assurance that the data will not be used for evil or they will see to it that the data is worthless.
2. Productivity varies by task. I’ve seen examples, on the same project, by the same person (me), where different tasks have enormously different productivity. Some problems are simply harder to solve. Sometimes you have to modify an existing bit of code: sometimes the existing code is easy to work with, sometimes it is a horrible mess. Sometimes you don’t even know what the problem is, and you have to do a bit of research just to figure out what needs to happen to get something to work.
3. People make varying contributions. I’ve known people who appear to work very slowly, producing very little every week. Sometimes (“The Slacker”) they’re not actually working, instead day trading or playing solitaire. Sometimes (“The Craftsman”) they are doing very solid work; you’ll never see a bug come out of system test for these guys. Some developers (“The Enabler”) don’t do lots of work of their own, but rather spend much of their time enabling others, or perhaps interacting with marketing, support, or testers; this is valuable time spent, they are keeping your team in the loop or solving customer problems. You can’t tell the difference with a time tracking tool, the slacker will simply enter fake data, and the enabler’s contributions don’t show up on paper.

If you’re trying to compare using time log data, then when lean times come you may end up firing the Enabler because the Slacker looks good. You’ll still have the Craftsman, but because he depended on the Enabler for answering questions, keeping Customer Support off his back, and keeping him in the loop about What Marketing Wants This Week, his productivity will drop dramatically.