> And so people take tickets, implement them as written, pass them off to whoever is next in the workflow, consider their job well done, even if working on scattered groups of them in parallel might be much more effective … and without ever considering the larger goal. “Implement the Upload button” says the ticket; so that is all that is done. The ticket does not explain that the larger goal of the Upload button is to let users back up their work.
Jira was designed for agile software development like Scrum, so you should write user stories, not mini specifications.
An upload button alone is no user story, a story might be "As a user, I want to be able to import the Excel reports that I get from company $XY, so that I don't have to manually enter the data, and save a lot of time that way", ideally including a reason why that data needs to be there.
That way, you get the context that the article is bemoaning the lack of, and the developer might even think "Hey, I know company $XY has an API for getting the report data, wouldn't it be even easier if we fetched it directly?"
And in a good agile process, you'd discuss this with the product owner, and rewrite the story to "As a user, I want data from $XY company in my system with minimal effort" or something like that.
No tool can substitute a good development process, and good communication between the involved parties.
That said, Jira does have it downsides, and not tracking dependencies very well is one of them.
And then there are things that can be downsides, but don't need to be. It's so flexible that many shops configure it to be pretty much unusable, but others create workflows that work very well.
Jira was designed for agile software development like Scrum, so you should write user stories, not mini specifications.
An upload button alone is no user story, a story might be "As a user, I want to be able to import the Excel reports that I get from company $XY, so that I don't have to manually enter the data, and save a lot of time that way", ideally including a reason why that data needs to be there.
That way, you get the context that the article is bemoaning the lack of, and the developer might even think "Hey, I know company $XY has an API for getting the report data, wouldn't it be even easier if we fetched it directly?"
And in a good agile process, you'd discuss this with the product owner, and rewrite the story to "As a user, I want data from $XY company in my system with minimal effort" or something like that.
No tool can substitute a good development process, and good communication between the involved parties.
That said, Jira does have it downsides, and not tracking dependencies very well is one of them.
And then there are things that can be downsides, but don't need to be. It's so flexible that many shops configure it to be pretty much unusable, but others create workflows that work very well.