6 ms·

The thing about JIRA hate (or love), is that it only has a little to do with the actual product. As the article says, crappy process will give you a crappy expe

The thing about JIRA hate (or love), is that it only has a little to do with the actual product. As the article says, crappy process will give you a crappy experience. But a crappy configuration will do just the same. If you're constantly hunting behind menus to get to stuff it's likely that they've enforced some process on to you but not properly reconfigured the screens or transitions so that you get what you need when you need it. It took a bit of trial and error but on my team we can work almost exclusively from our agile board and have transition screens configured that will collect the info we need when someone is moving things around on the board. Now, don't get me wrong- the UX needs a lot of work because it is so inconsistent, but I feel like almost every complaint I've ever heard about JIRA could be remedied by a better implementation. Maybe not solved completely, but remedied to a degree that it's not too bad.

albedoa 9y ago
> the UX needs a lot of work because it is so inconsistent > almost every complaint I've ever heard about JIRA could be remedied by a better implementation. Huh? You're replying to a complaint about the UX.
Domenic_S 9y ago
> every complaint I've ever heard about JIRA could be remedied by a better implementation Erm... what can't be fixed with better implementation? My big point of hate on JIRA is how it uses some mutant hybrid of markdown and wiki text, so going between JIRA and Github is a nightmare of context switching. Can that be fixed with a better implementation, of course it could, but the point is Atlassian doesn't seem to think about UX.
- manyxcxi 9y ago
  What I meant by implementation is that you can implement your company's processes via JIRA configurations, workflows, and occasionally plugins in such a way that the way your instance operates is almost unrecognizable from the way someone else's might. You can configure a nearly infinite number of input screens with all manner of standard and custom fields to be presented to users at any given point. The rules can be quite complex and handle forward and backward transitions. As a system administrator it can totally be overwhelming, but you are quite free to do most things. If you have a process that default JIRA configurations doesn't serve well and drives users into deep menus and weird contexts, you can very likely fix it, or at the very least make it more palatable with those customizations. For example, for a given project type, we don't just have To Do, In Progress, and Done. We have To Do, In Progress, In Review, and Done. When a dev moves from In Progress to In Review they are prompted to input a number of required fields so that QA can know how to test it, where to look for it, etc. If QA fails the review, they're prompted with a specific screen that brings forward the inputs they'd need to document why it failed. When they fail it, it automatically goes back to the dev that kicked it to review. When that dev kicks it back in to QA it's going to go back to the person that reviewed it the first time. This process, if done with no extra JIRA configuration would be a damn nightmare and it would break down fast. We spent the time to make it fast for everybody using it, and to make sure that they are presented with the things they'll need when they need them. If JIRA is new to a team I recommend they run it completely vanilla for a while and then come up with a list of things they'd need it to do or do differently to fit their meatspace processes and interactions. I'd also look at what you could do to make your existing processes more streamlined that might cut some of the complexity in the first place. Vanilla JIRA Agile is actually fairly simple and only more complicated than Trello because of the UI and various issue types. You'd be surprised how far it can take a team if you don't have some arcane internal requirements or unrealistic expectations of the software revolutionizing your team's performance. At my last company we quelled a near JIRA revolt (it was there before me) by literally just going to default JIRA Agile workflows. I do agree about the 'markdown' support in JIRA/Confluence. It would almost be better if they just didn't support anything than the way they support it. I've got a lot of gripes with JIRA around UI/UX issues, but the vast majority of hate I hear spewed at JIRA is usually because they had really crappy (or just complex) team processes implemented with crappy JIRA configurations and it made everyone's life hell. I'm not a JIRA apologist or anything, if there was something else out there that was better and had the same level of available integrations (Jenkins, Slack, support desks) I would cut over in a heartbeat. I just think it gets a worse rap than it deserves (not that it doesn't deserve some mind you). Confluence on the other hand, that deserves every complaint I've ever heard about it...
  - im_down_w_otp 9y ago
    I'm talking about both default JIRA workflows and customized ones. I've had to be both a consumer and a creator of processes managed with JIRA. It has no bearing on how objectively confusing and inefficient the UX is.
AznHisoka 9y ago
JIRA is all CRUD. So the UX is the product.

albedoa 9y ago

> the UX needs a lot of work because it is so inconsistent > almost every complaint I've ever heard about JIRA could be remedied by a better implementation. Huh? You're replying to a complaint about the UX.

Domenic_S 9y ago

> every complaint I've ever heard about JIRA could be remedied by a better implementation Erm... what can't be fixed with better implementation? My big point of hate on JIRA is how it uses some mutant hybrid of markdown and wiki text, so going between JIRA and Github is a nightmare of context switching. Can that be fixed with a better implementation, of course it could, but the point is Atlassian doesn't seem to think about UX.

manyxcxi 9y ago
What I meant by implementation is that you can implement your company's processes via JIRA configurations, workflows, and occasionally plugins in such a way that the way your instance operates is almost unrecognizable from the way someone else's might. You can configure a nearly infinite number of input screens with all manner of standard and custom fields to be presented to users at any given point. The rules can be quite complex and handle forward and backward transitions. As a system administrator it can totally be overwhelming, but you are quite free to do most things. If you have a process that default JIRA configurations doesn't serve well and drives users into deep menus and weird contexts, you can very likely fix it, or at the very least make it more palatable with those customizations. For example, for a given project type, we don't just have To Do, In Progress, and Done. We have To Do, In Progress, In Review, and Done. When a dev moves from In Progress to In Review they are prompted to input a number of required fields so that QA can know how to test it, where to look for it, etc. If QA fails the review, they're prompted with a specific screen that brings forward the inputs they'd need to document why it failed. When they fail it, it automatically goes back to the dev that kicked it to review. When that dev kicks it back in to QA it's going to go back to the person that reviewed it the first time. This process, if done with no extra JIRA configuration would be a damn nightmare and it would break down fast. We spent the time to make it fast for everybody using it, and to make sure that they are presented with the things they'll need when they need them. If JIRA is new to a team I recommend they run it completely vanilla for a while and then come up with a list of things they'd need it to do or do differently to fit their meatspace processes and interactions. I'd also look at what you could do to make your existing processes more streamlined that might cut some of the complexity in the first place. Vanilla JIRA Agile is actually fairly simple and only more complicated than Trello because of the UI and various issue types. You'd be surprised how far it can take a team if you don't have some arcane internal requirements or unrealistic expectations of the software revolutionizing your team's performance. At my last company we quelled a near JIRA revolt (it was there before me) by literally just going to default JIRA Agile workflows. I do agree about the 'markdown' support in JIRA/Confluence. It would almost be better if they just didn't support anything than the way they support it. I've got a lot of gripes with JIRA around UI/UX issues, but the vast majority of hate I hear spewed at JIRA is usually because they had really crappy (or just complex) team processes implemented with crappy JIRA configurations and it made everyone's life hell. I'm not a JIRA apologist or anything, if there was something else out there that was better and had the same level of available integrations (Jenkins, Slack, support desks) I would cut over in a heartbeat. I just think it gets a worse rap than it deserves (not that it doesn't deserve some mind you). Confluence on the other hand, that deserves every complaint I've ever heard about it...
- im_down_w_otp 9y ago
  I'm talking about both default JIRA workflows and customized ones. I've had to be both a consumer and a creator of processes managed with JIRA. It has no bearing on how objectively confusing and inefficient the UX is.

AznHisoka 9y ago

JIRA is all CRUD. So the UX is the product.