Reading Hundreds of Tickets at Once

I’m trying a relatively new thing these days: working through huge lists of open MongoDB JIRA tickets using a pencil and a big printout. This turns out to be a better way for me to handle this workload than sitting at a browser and doing it interactively. To explain this, I suppose I have to explain why I’m reading all these JIRA tickets.

I’m reading all these JIRA tickets because I don’t want to lose touch with the needs of MongoDB users, in spite of the ever increasing volume of related articles, blog posts, and yes, JIRA tickets. By reading all of these things, I am trying to keep an “on the ground” sense of use cases, issues, complaints, needs, and desires, which is invaluable in decision making. Knowing that this gestalt sense is honed and working well is crucial to my peace of mind. However, this sense is dampened and feels unfocused when the information comes through layers of delegation and summarizing.

Over the years I’ve developed a good ability for pattern recognition in the vast sea of open tickets. For example, while doing this very thing on a flight back from London recently, I saw that there were 10 open tickets related to one query parsing example that would be easy to fix in the new matcher. Reading all the tickets also prevents me from getting too distracted by new issues that attract attention, but aren’t as important as older issues.

So I read tons of JIRA tickets, and lately I’ve been using my favorite method so far: taking a giant printout of cases with me when I fly somewhere. My last batch was a single bucket of tickets, which printed out to 36 pages, containing about 600 tickets. I use a pencil, and mark tickets with which version to put them in, whether they are duplicates, if they should be closed, notes about implementation and what other tickets they might be related to. I generally mark about 20% of the cases in each pass.

During this process, I go into a bit of a zone, not the same as, but similar to, the zone I go into when coding. I’m not trying to triage particular cases or do meaningful work on an individual case, I’m trying to make mental links. So I move through the caseload quickly, keeping the overall view in memory, cross-referencing, looking for patterns. As I go, I’m building up a sense of areas that need more work, or where we can make headway quickly. This all-at-once method lets me observe patterns over time I might not otherwise notice. (If something comes up once every other week, it tends not to leave a dent in my thought process, but if it comes up once every other week for 4 years, that’s probably worth thinking about.)

Of course none of this works at all without 10gen’s amazing project managers that take these scribbles and do meaningful things with them.

So for those of you who use jira.mongodb.org, know that your tickets do actually all get read, and even if a ticket is really old, it doesn’t mean that we think it’s not important or that it’s being ignored.

In the end, this process gives me the confidence that when we have to rapidly shift plans, I can intuitively understand what the pros and cons will be. Given my role on the MongoDB project over the next few years, the ability to be agile will remain crucial.