Populate your issue tracker at scale

Sometimes when working on a project at work, we find out about a pile of features or changes needed. This can happen at the beginning of a project, at the start of the major initiative, after deploying a project (which triggers much user feedback), etc. Sometimes we have so much to absorb and divvy up into issue tracker items, that the logistics of doing so are painful.

Just thinking through and writing down 50-100 issues (or more!) is too tedious for one person to get through quickly. To divide up this work (of describing a bunch of issues in enough depth someone could work on them), I’ve come up with the following approach.

First, I jot down a list of all the areas of the system where there are new issues to enter. This forms an outline of areas that have issues, I don’t even attempt to make an entry for every likely issue.

Second, I record one or more videos, showing the screen of the system I want to add issues for, alternating back and forth with code. As I go, I describe each problem/opportunity/fix, that should become an issue. Depending on whether the new issues are closely related to existing ones, sometimes this includes bringing up the issue tracker (Jira, etc) also, talking through existing items about work remaining on them.  Sometimes something that first seems like a new issue, is really just a refinement of the success criteria of an already known issue.

Having spent potentially quite a while just describing issues (there have been times when this goes on for over an hour), I hand over the recording(s) to a relatively new person on the team, who will go through and translate this rapid-fire description into a set of items. Typically it’s fastest for the person to do that not by directly entering the items, but by just typing the candidate issues into a document. (If the list is big enough, it can pay off to have a transcriber handle the first pass – turn the words from the video/audio, into text.)

Finally, that initial rough list of candidate issue, goes to the project leader(s) of the project in question, to clean up, refine, review, approve. Then someone copies the approved text into the issue tracker.

Admittedly this is not a complex process, hardly worthy of a blog post. But someone once asked me how we successfully enter so much detail into so many items on complex projects – and here is the answer. Entering all that really does pay off. It is much more plausible to delegate work if you have described it as thoroughly as you can.