3 ms·

In my experience, Jira is the dog that begins to resemble its owner. If you are working in a toxic, dysfunctional organization, Jira will reflect that: - Giant

In my experience, Jira is the dog that begins to resemble its owner. If you are working in a toxic, dysfunctional organization, Jira will reflect that: - Giant forms with dozens upon dozens of nonsensical fields (preferably with abbreviations as names, like "IFE App.") half of which are required so you just stuff random words in them to make it shut up - Thousands of tickets that would probably take 30+ software devs 100+ years to implement - Can't find your project because your project's name is nonsense (also preferably with abbreviations) - Task descriptions have hundreds of words of nonsensical boilerplate but don't actually say anything at all - 50 different ways each to say "Finished", "Started" or "Abandoned" - Workflow state transitions reminiscient of the outdoor maze in The Shining (crazy man with axe optional)

alephxyz 4y ago
One I found particularly annoying was having too many hierarchical levels for taks. Something like : Client, Contract, Deliverable, Product, Release, Change Request, Requirement, Task, Sub-tasks
audunw 4y ago
> - Thousands of tickets that would probably take 30+ software devs 100+ years to implement I feel like the company I'm working for has a reasonable attitude towards Jira, and they recently just batch closed all tickets that were older than some date in many projects. So you'd have to actively re-open tickets you had created to keep them alive, if needed. Great decision IMO. It's an interesting exercise to be forced to deal with old tickets you've created. It gets you thinking.. "well, this thing should probably be done at some point, but then if it's actually important we'll probably think of it again and can re-create the ticket then". Might give you experience that encourages you to be careful when creating new tickets too.
- EnderWT 4y ago
  We've automated this in our propriety system. After an amount of time with no activity, change requests expire and someone can resubmit if they're still valid, otherwise they close after a number of days. They also get a notification in advance in case they want to investigate validity before expiration. Has worked well for us since our software is decades old and the number of change requests are substantial.
- quickthrower2 4y ago
  I worked somewhere where there were 500 backlog tickets that disappeared and reappeared depending on the ethos of the current team leader.
- d0mine 4y ago
  Closing issues without actually fixing them is depressing. It may be beneficial overall. There could be alternatives e.g., label such task as "fun" and hide them all the views by default, then allow developers to spent say 10% on any of "fun" task of their choosing (no expectations). It may help with burn-out for some devs and the issues that are worth fixing according to at least by some devs are getting closed eventually.

alephxyz 4y ago

One I found particularly annoying was having too many hierarchical levels for taks. Something like : Client, Contract, Deliverable, Product, Release, Change Request, Requirement, Task, Sub-tasks

audunw 4y ago

> - Thousands of tickets that would probably take 30+ software devs 100+ years to implement I feel like the company I'm working for has a reasonable attitude towards Jira, and they recently just batch closed all tickets that were older than some date in many projects. So you'd have to actively re-open tickets you had created to keep them alive, if needed. Great decision IMO. It's an interesting exercise to be forced to deal with old tickets you've created. It gets you thinking.. "well, this thing should probably be done at some point, but then if it's actually important we'll probably think of it again and can re-create the ticket then". Might give you experience that encourages you to be careful when creating new tickets too.

EnderWT 4y ago
We've automated this in our propriety system. After an amount of time with no activity, change requests expire and someone can resubmit if they're still valid, otherwise they close after a number of days. They also get a notification in advance in case they want to investigate validity before expiration. Has worked well for us since our software is decades old and the number of change requests are substantial.
quickthrower2 4y ago
I worked somewhere where there were 500 backlog tickets that disappeared and reappeared depending on the ethos of the current team leader.
d0mine 4y ago
Closing issues without actually fixing them is depressing. It may be beneficial overall. There could be alternatives e.g., label such task as "fun" and hide them all the views by default, then allow developers to spent say 10% on any of "fun" task of their choosing (no expectations). It may help with burn-out for some devs and the issues that are worth fixing according to at least by some devs are getting closed eventually.