Back in December of 2016, a flurry of hate seemed to erupt over JIRA that while I didn’t chime in on, I quite understood. Work at any software endeavor long enough, and someone (usually someone in a project management position) will suggest that there is a need for an issue tracking tool in order to “be more Agile.” Let’s be honest for a second, many of us hate the whole “let’s be agile” thing either because it reflects a serious misunderstanding of Agile or because it is a tossing out of a business-appropriated term that only means “let’s have scope creep without checks.” Usually, it is both. However, we need to really ask ourselves why organizations feel the need to have a JIRA-like tool in the first place. Many of them would rather just use a spreadsheet with dates and track metrics via Microsoft Project or some other tool.

In suggesting JIRA, project managers and business stakeholders are trying to meet development teams half-way to make sure we can deliver.  Sure, yes, they want some kinds of metric to measure progress, productivity, and seeing that their money is being spent well, but they want us to be successful as well. This is (most assuredly) not “Agile” concerns, but legitimate concerns nonetheless.

The real problem here is not with the tool, but how it is used. JIRA started off life as a simple issue tracker, not a way to spread knowledge of the complex interplay of metaphors, deas, goals, rules, priorities and a thousand other factors that go into developing software. Only when someone saw the opportunity to capitalize on the “Agile” and Scrum craze did they shoehorn Agile (specifically Kanban and Scrum) into the tool.

What is needed is a better way, using text analysis and natural language processing for us to take an idea or a notion and decompose it into actionable stories and tasks.