I have the requirement to set up a shared issue-tracking spreadsheet on Google Docs and it occurs to me that I have been away from minimalist remote project management for long enough that I can’t rattle off the columns that should be included in such a spreadsheet. Further, it occurs to me that there is probably a lot of disagreement about exactly what would constitute the “perfect” minimalist issue tracker, so I thought I’d write up a quick blog post and work through what I’m including and why.
Obvious, I guess. What’s the short, descriptive handle for the item such that when someone says the words, everyone else knows what they’re referring to? But it gets deeper. Should the title refer to any of the following:
- What “done” means
- Who is responsible
- When it needs to get done
… for example, here’s a sample (bad title):
“AD domain account”.
Here’s one that incorporates the first item:
“Create AD domain user account on MYCORP for John Q. Smith”
Here’s one that incorporates the second item:
“Nancy to Create AD domain account”
Here’s one that incorporates the third item:
“Create AD domain account by Tue Sep 27 2011”
Which is right? Well, there is no “right”, per se. Which is best? I think that the first extension: “Create AD domain user account on MYCORP for John Q Smith” is better than the other two alternatives, both because (a) we can add “responsible” and “due by” as other columns in our issue tracker, but also because the definition of what “done” means is (for me) one of the most important things to focus and agree on.
Now, you’ll argue, and you’d be somewhat right, that we don’t know WHY we need to create the domain account for John Q. Smith, and without that we don’t really know if we’re done. What’s the utilitarian point of view? What needs to happen to make John Q. Smith happy?
You might change it thusly:
“Grant John Q. Smith read access to the \\MYCORP\MYSERVER\MyShare document folder”
This has the benefit of leaving the implementation decision open to Bill. Here I get a little uncomfortable. When we get down to the granular level of an issue tracker, shouldn’t we be concerned with HOW as well as WHAT and WHY? I revert back to my GTD training: what is the very next tangible step that needs to happen to move the issue along? If Bill is indecisive or unsure of whether he should create a new user account, or open up \MyShare for public read-only viewing, etc., then we get into the micro-delays that, cumulatively, mean death for the project.
But if we’re not “done” until John Q. Smith logs in and is able to read the documents, then where should we put that information? A separate column? Done When?
|Create AD domain user account on MYCORP for John Q. Smith||John can read documents in \\MYCORP\MYSERVER\MyShare|
This is pretty clear. I might like this.
Moving ahead. Do we need “Date Created” and “Date Completed”? I don’t think so. For one, I hate dates (don’t all developers!) and for another, to what use are you going to put this information? Your frequent review of the list will tell you, instinctively if nothing else, which items are stalled/stalling. And, in the real world, I don’t see dates being analyzed after the fact for improvement in a typically-sized agile software project.
So no dates.
Who’s Responsible? That might be a good one; not to allow the manager to hit that person over the head, but for that person to be able to quickly see what tasks she has and what tasks she can safely ignore. If you think that sounds ass backwards, you’re probably right; but it’s reality. I scan lists and ignore anything I can, to get to the heart of what I personally am on the hook for. When it’s unclear what’s mine and what’s not mine, I get antsy and anxious.
|Create AD domain user account on MYCORP for John Q. Smith||John can read documents in \\MYCORP\MYSERVER\MyShare||Nancy|
Finally (I think) – how do we know which issues are active and which are done? Further, are those the only two states of interest? What about “Not Started”, “In Progress”, “Blocked”, “Reopened”, or any of the other million oh-so-helpful statuses that PM tool makers have given us over the years?
Screw it. I’m thinking short and sweet. I don’t even want a column. Strikethrough is perfect – it’s visual, it’s obvious, and it still lets me read the underlying issue. Here’s a completed issue:
If you need to reopen it, remove the strikethrough.
Anything else? What about “Requested By” so that you can see who wanted each item? Meh. In a team environment, you should probably know that anyway, or be able to infer it, and what will you do with that info anyway? Bitch and moan because your issues are lagging, while Mike’s issues are getting closed out?
So I think I have the ultimate minimalist issue tracking template. What do you think?