🚀 I help Product Owners, Product Managers, Scrum Masters & Agile Coaches Grow w/ Classes, Courses, Books & Community. 📖 Author of the ”Scrum Anti-Patterns Guide;” 🏅Trainer at Scrum.org; ⬇️ Book a 1-on-1; talk chances!
#Jira — Love it, or hate it: What #antipatterns have you observed that make Jira unbearable? Jira has always been a divisive issue, particularly if you have to use Jira due to company policy. In my experience, Jira out-of-the-box without any modification or customization is a proper tool. If everyone can do anything, Jira is okay despite its origin as a ticket accounting app. The problems appear once you start submitting Jira to customization. When roles are assigned and become subject to permissions. Then, everything starts going south. My two worst Jira anti-patterns are as follows: (1) You strip the teams of admin rights and outsource all Jira configuration changes to a nearshore contractor, resulting in a 3-4 weeks lead time for even the most minor issues. (2) You install a Definition-of-Ready plug-in and use its Sprint reports to reprimand teams that accept Product Backlog items in the Sprint that are not fully “ready” for the sake of doing so. 👉 So, what Jira anti-patterns have you seen in practice? Please use the comments.
I wrote a post on the 7 Deadly Sins of Jira a while back, I’ll have to dig it out.
1) Task as placeholder 2) Story in backlog never reviewed/deleted 3) missing logged work
Auto-cloning tickets so that 1) dependencies are created without requiring any conversation with the other team, and 2) project managers can dictate a set of tasks before the work even starts.
A ticket cannot be owned by 2 people at the same time even when they work in pair
Good morning ... To your point of stripping admin rights from the team, I had a Jira request to set up a trigger and the ticket took 6 months to complete ... Another #antipattern is people avoiding Jira and coming directly to the team with requests, which makes the request "covert" or "Black Ops" work. Jira is seen as "overhead" or "paperwork". If you think "paperwork" is a waste of time, just skip the "paperwork" the next time you go to the bathroom! 😬 🤢
Breaking stories up into individual tasks and sub-tasks destroys the idea of the team moving the ball down the court to the basket together.
Love Jira! The main issue I see is a lack of understanding of what it is and how to use it across a business. Not so much an anti-pattern with the tool but it's people using different tools for the same thing with a lack of consistency, so... - Reporting is inconsistent - Data is inconsistent - Managing the delivery of your work becomes inconsistent across an org Any tool is only as powerful as you want it to be. Also it's not fantastic with Kanban...
"3-4 weeks lead time"? Lucky you! Last year I've asked for a custom field (team proposed to have DoD checklist just for the reference), and client Jira admins set 2030. as a due date 😄
1.) Everything is a project 2.) Epics act as a container 3.) No pull mentality 4.) Gazilion of buttons 5.) Slow and on, and on...
Subscribe to weekly newsletter for articles ✦ Coddiwompler
1y1. “Assigned to” - perpetuates push model 2. Story - implies all requirements must be written as user stories 3. Epics - not decomposition structure, but more theming and grouping 4.Tasks are over complicated, should be simpler 5. Burndown sucks 6. How sprints are set up and work 7. Concept of teams has to be hacked in 8. How wip limits work 9. Items cannot be owned by multiple people 10. Integration with confluence is horrible. 11. Releases are awkward to set up at first 12. Levels of decomposition out the box limited 13, API horrible and can see how the agile stuff is bolted functionality to bug tracking system 14. UI some good some awful 15. Promotes push not pull I'll stop for now