Software image via Shutterstock
By Steve Poling (@stevepoling)
JIRA is a great tool to keep track of issues in a software project, be they requirements or bug-reports. You can create a JIRA issue, attach a description of what you want, and assign it to someone. Or to yourself. The tool generates charts and graphs that will impress your boss.
But there’s a problem I call JIRA-mandering and it’s as bad a thing as wickedly-drawn political districts.
The people who are defining a system under development, or reporting problems in an existing system may not have a clear notion of what they want or what’s wrong. This vagueness isn’t a bad thing because we need to capture issues and give them visibility. It’s better than nothing! But the vagueness can lead to JIRA-mandering as we learn what we want and as one thing leads to another.
Suppose you’ve got a vague requirement to publish something, but when you get into the implementation, you learn of constraints and considerations you were unaware of at the outset. It’s easy to tack these considerations onto the original JIRA issue.
Another possibility is that when you originally formulate a JIRA issue you want X and Y and Z. Only trouble is that at the time you didn’t realize that X and Y are as easy as getting milk and cigarettes from the corner store, while Z is like flying to the moon to get rocks. I can hear my boss saying, “I appreciate the milk and smokes, Steve, but you’re not closing the issue.”
Perhaps you’ve heard of SMART criteria (Specific, Measurable, Attainable, Relevant, and Timely). “Hey, boss, did you realize you were asking for the moon?” Or “Hey boss, what do you really need moonrocks for?”
I think JIRA issues should be as SMART as you know how to make them. And you’ve got to have an understanding with your stakeholders that JIRA issues are subject to change as we learn and work through what the software needs. I propose a continuous process of refining JIRA issues to make them SMARTer.
Whenever someone gives me work, we both want to know when it’ll be done. I know I’m done writing software when it passes an Acceptance Test. (Every test should have one reason to fail, but that’s another story.) Let’s suppose a stakeholder creates a JIRA-mandered issue and assigns it to you. The first thing you should do is determine what the Acceptance Test will be. It’s one of those good habits: start with the end in mind.
When you do this to a JIRA-mandered issue, you’ll discover that either you cannot articulate an Acceptance Test, or you’ll find you’re talking about a collection of tangentially-related tests. Most likely, it’ll be a mix of the two: a fog-ball nestled in amidst a number of better-understood, disparate matters.
If you can’t articulate an Acceptance Test for a JIRA issue, you’ve got to negotiate with your stakeholder. Try to get the issue split into parts that clearly identify the parts you understand and the rest. And I suppose that when you see parts of two different JIRA-mandered issues that naturally belong together, try to recombine them into their own JIRA issue.
Just as gerrymandering undermines the integrity of democratic governance, a haphazard coverage of the requirements and issues in a software system undermines visibility into its development or maintenance.
Steve Poling was born, raised and lives in West Michigan with his wife and kids. He uses his training in Applied Mathematics and Computer Science as a C++/C# poet by day while writing Subversive Fiction by night. Steve has an abiding interest in philosophy and potato cannons. He writes SF, crime fiction, an occasional fractured fairy tale, and steampunk. His current writing project is a steampunk novel, Steamship to Kashmir - provided he isn’t distracted by something new & shiny.