Friday, July 22, 2011


It feels so good to finish something. I commit the code, deploy the build, finish the test, whatever. Then I move on. Hooray!

Well, actually, first there's the bookkeeping to do. Bookkeeping is all the stuff outside the actual change that you have to do in order to inform the project that you're done. Typical bookkeeping includes one or more of:
  • marking a bug or story finished in a tracking system (paper or electronic). This could be moving an index card, or updating a status in Jira, or clicking the "deliver" button in Pivotal Tracker.
  • notifying the recipients of your work. This could be emailing or IMing the test team, or sending a notice to customers, or marking a bug as verified in a defect tracking system.
  • cleaning up the environment. This could be deleting a feature branch, reverting the database to clean out test data, or re-imaging the machine you were using as your victim (err.... test machine).
Some projects have more bookkeeping than others. After all, bookkeeping frequently leads to statistics that are interesting and potentially useful. Think of all the things we can track! We can track time spent and compare it to estimates, to help ourselves be more accurate. We can track how many issues are in the code versus the test infrastructure versus the configuration versus from merges and help ourselves not make the same mistakes. We can track who fixes what kind of bugs, or who does what kind of implementation tasks so we can balance better in the future. We can, we can, we can....

But all of that bookkeeping costs. It costs time for people to record the information. It costs time to set up the record tracking. It costs time for people to data mine the information and get value out of it. It costs in morale: when a team feels tracked and monitored they spend time, effort, and cycles gaming the system and worrying about looking good for the tracking, when they could be working to make the product better.

That's not to say there should be no bookkeeping. On the contrary, a team that doesn't monitor themselves a little bit has no ability to say they are improving, or to catch problems early.

Just make sure that when you add an element of bookkeeping to your process, that you know what value that element is going to provide. If you can't articulate the value and how you're going to get that value from that bookkeeping item, then you're not ready to start tracking it. And if that value is no longer there, stop the bookkeeping. Gather as much data as you can usefully use. No more, no less.


  1. I would really want to have a system where one update would be enough for communication, status update, task assignments etc. At least in most situations. To me it seems that updating in multiple places is what makes thing sometimes frustrating and error prone.

  2. Catherine, a test management tool would cut all the bookkeeping to a minimum.

    Any bug tracking system is good, as long as your team follows it.

    IF you want, you can read my post on this:

    All the best,

  3. Joel, that's true as long as what you're tracking is a test. Generally you need other tools for things like features, code coverage, etc.