On Writing Tickets (Part 1)

(Right-Sizing Tickets)

Spoiler alert: I’m going to tell you right up front what my conclusion is: Tickets should be large in scope. Also, tickets should be medium in scope. Finally, tickets should be very small in scope. Tickets, tickets, tickets! Tickets for everything!

Imagine a ticket with the instructions “create user login.” Cringing? Me too. But most of us are familiar with tickets of huge scope that lack any kind of breakdown.

Back in the day, way back long, long ago (maybe not that long ago) we sent emails. “Hey Matt,” the email might read, “don’t forget to add the flim-flam to the doohickey. But don’t do this until the thingamabob layer is complete.”

We had defect tracking systems, but generally these were utilized for one of two purposes: Customer reporting of software issues, or quality assurance reporting of pre-release defects. Requirements were implemented by way of tracing through a document and checking items off of a list.  One of the earlier products for requirements tracking and traceability was Rational DOORS. There were a number of other tools we used, none of which integrated very well. Later I was introduced to Rational ClearCase, Rational ClearQuest, Microsoft SourceSafe, Bugzilla, Trac, CVS,  BugTracker, Subversion, Redmine, Jira, Confluence, Team Foundation Server… And on and on.

An early entry in the Rational suite of products, it was a rather expensive program in the way of licensing. If my recollection is correct, it seems that licenses were based on user seats. When such a model exists, and if each seat is expensive, a company may tend to limit the number of product users on a team. The side effect of this approach (again, only if the pricing is high) is limited usage within a team.  I recall project managers working on Gant charts, hosting meetings in which all the developers sat around a table gazing at a projected screen being asked for status updates on each line item. Talk about a yawn fest! Whether it was DOORS, Microsoft Project, some other tool, or a long list of line items with names attached to a number of tasks, the status meetings were always the same.

Some reading the list of products I just threw out will recognize that it isn’t very sensible. Some of the items in the list are used for version control. Some for ticket management. Some for a bit of both. Some of the products are no longer in use. Some are very old, but still in use. (And some, such as Redmine, Jira, and Confluence, aren’t all that old.) This was a problem then (and for many, it remains a problem now): The solutions to our development needs were viewed as separate entities. In addition, we just didn’t seem able to settle on how to use these separate items (which in the past, didn’t integrate well, if at all) in a way that actually helped rather than hindered.

In the early days of my career I almost always had an email inbox full of hundreds of items, some flagged, some marked as unread (so I wouldn’t forget), and some in the trash folder—either placed there deliberately or by accident. My monitor was littered with yellow sticky notes. A pad of paper next to my keyboard was packed with doodles, stars, asterisks, double and triple-underlines. If something was REALLY important, I may have drawn a box around it. For the REALLY REALLY important items, I drew two boxes. And for the REALLY REALLY REALLY important ones… You get the picture.

What a nightmare!

And let’s not forget the weekly status reports! I’m getting flustered just thinking about them! Well-meaning managers asked for status reports every Friday afternoon. When Friday rolled around, I often found myself digging through emails and flipping the pages of my notebook in an attempt to recall what I had worked on. Who has time to fill in a status report in increments each day when distracted by getting actual work done?  I loathed these reports. And I say this without hesitation, as I know I am not alone.

Inevitably, some line item would appear on the list with my name next to it. “Matt,” the project manager asked, “how are you coming with the doodad that implements the whatchamacallit?”

The other day someone asked me this question: “What are your thoughts on the difference between task-oriented and linear oriented?” It was an open ended question, so I wasn’t sure if this question was with regard to software functionality or design and development in general. I’m still not sure what the question means, but I assume it has something to do with the difference between viewing processes as a long line of things to be done in a sequence (with gates between each) and doing things as standalone tasks. Of course, even if something is ‘task-oriented’ there are still dependencies—things that require linear completion. This is why we write tickets that allow us to create a hierarchy of dependencies.

“Uh…” It seemed to happen every time! I was caught off guard by some entirely surprising task. My face felt a little warm, as I struggled to recall just what the hell the project manager was talking about. “Are you talking about the gizmo that ties in with the canootinator?”

“No! Not that… You remember, I sent you an email about the whatchamacallit and the doodad last week. It’s in my sent items. I’ll pull it up right now. Sure, I felt stupid. Maybe I should have. The truth of the matter, however, is that reliance on ineffective communication mechanisms is what led to this (not just for me, but for others as well). Sidenote: Being a software developer requires that one feel stupid every so often. It’s part of it.

As I write this, these recollections seem like the distant past—but the reality is that it wasn’t all that long ago.

(DOORS lives on as an IBM product. I have not used it in years, so I cannot speak to its current state of being.)

We’ve come a long way since then. Mostly. Maybe. Not all of us.

The subject I wish to write about today is effective utilization of tickets. It doesn’t matter what your development process is. Agile, SCRM, Kanban, some iterative process. Whatever the design and development approach—it’s high time to scrap the emails, notebooks, and sticky pads. Need I even mention that it is time to abandon the weekly status reports? (I’m not talking about sprint planning or standups when I say this). I don’t care what the development approach happens to be. Whatever it is, granularity of tasks, detail, and communication remain absolutely necessary (and email does not qualify as effective communication).

Should someone—from your boss to your boss’s boss to a well-meaning coworker, come to the door of your office, cubicle, desk, or couch with the expectation that a conversation is locked in as a done deal upon leaving—shame on all involved!

The same goes for IM and text messages. None of the above forms of communication should ever be considered a final lock-in of a task. There is one and only one way that work items—any work item—should be recorded: The ticket management sytem.

There are many too choose from, some better than others. The poorly-named BugZilla is a fine choice, but Team Foundation Server, Jira, Redmine, and Trac are all great options. Redmine and Trac are entirely free, and they are great tools with plugins for everything under the sun. My personal preference is Redmine, but this could be a bias simply because I have used it so much.  Before I continue, let me make one thing clear: Let’s never again refer to a ticket management system as a ‘bug tracker.’ NAY! To call it a defect tracker leads us back to square one. A defect is a category of a ticket. It may be something of high priority—but all tickets should have an associated priority.

There are a few integrations that I consider absolutely necessary. To make a ticket management system effective, it must integrate with:

• The  CI (continuous integration) build

CI should integration with version control. It should pester the team when a build breaks. It should make it clear what changeset broke the build, and the changeset should point us to the ticket that was being worked on that prompted the changeset.

• Email

Wait—didn’t I just say we need to scrap email? I did. Email is a good prompt, however, for team members to see new and changed tickets. For a small team, I like to see all of those emails, even if the task is not related to me. It’s good to know what others are doing.

• Version Control

Changesets must be concise. As we check-in for commit stuff to our version control (by stuff I mean anything—not just code. That stuff could be configuration files, documents, spreadsheets, etc.).

• Existing workflow (and if we have to shoehorn the concept of tickets into the workflow, perhaps it is time to rethink things.)

I’ll keep this on-point, as much as I can, as I see a great deal over overlap among the necessities (and for this blog I’ll be writing separate posts (lest my faithful readers become distracted while reading too many words).