3 ms·
There's lots, but I think it comes down to two main things: It has bad defaults, and it can be customized to have really draconian workflow rules. If you confi
by gregmac 4y ago
There's lots, but I think it comes down to two main things: It has bad defaults, and it can be customized to have really draconian workflow rules.
If you configure it to be reasonable -- keep the workflows very simple with few to no validation rules -- it can be fine to use. The temptation seems to be locking down admin access to managers, and then the admins going crazy building workflows like "these 19 custom fields must be filled out to start" "items must go through a QA step" "QA users are the only people that can approve that step" and "PMs are the only ones that can close a ticket". This quickly gets out of hand and makes it horrible to use.
It also depends on the people using it -- garbage in garbage out, as they say. If people write good tickets (concise titles, format the body, remove irrelevant crap, and properly fill out meta fields like fixVersion) it is much more useful. JQL is awesome, and embedding tickets and JQL queries of tickets into Confluence is awesome (hint: easy way to make release notes) -- but both of these require non-garbage ticket content.