Neat. You made Trello.
- Crazy amounts of hotkeys. You can do everything in Kitemaker without using the mouse. It feels pretty awesome to move issues around the board, assign them, etc. all with hotkeys. Also like many modern products we have a command center (ctrl+K or cmd+K) where you can do everything.
- Our issue screen is quite a lot more powerful than Trello's card view. We've talked to many teams who use Trello and they rarely have much content in their cards. In our issue screen, you get a rich document part (feels quite like Notion, with a lot of things you can drop into the issue like images, Figma designs, etc.) and an activity part (with threaded comments, a history of what's happened with the issues, updates on relevant information from integrations, etc.)
- Better GitHub integration. Our issues actually have issue numbers, so you can do things like "Fix ABC-123" in your GitHub commits and our automation feature will move the issue around the board accordingly (you can set up different rules for if such a message appears in a PR, a commit in master...er main, etc.). We show any activity in GitHub related to the issue right in the issue's activity feed as well.
- Better slack integration. Mentioning issues in Slack automatically attaches the conversation to the issue and also provides useful info about the issue in Slack
- List view. You can see issues in a list instead of a board if that's your thing. Nice for use cases like backlog grooming.
And we're moving fast and adding more useful stuff all the time without becoming too complex or unpleasant to use.
So yes, we have a pretty board and pretty boards tend to look like Trello. But there's a lot more to it than that.
I tend to track my personal workload in a text file at a more granular level. When my team's project was approaching a deadline and a crunch and I needed to stay synchronized with the developers working closely with me, I transcribed this list to Trello. I showed it to the PM as a curiosity and the next day all of the cards had been printed out and affixed to the wall with masking tape. That's the type of environment a lot of us are working in.
Fundamentally JIRA is an over-grown bug tracker. A bug tracker should be designed, built, administered and used by programmers and only programmers. Project managers should not even have access to it, in my view, let alone try to use it to create reports or control the team.
Typical problem I face in my JIRA shop: there'll be no way to move a task straight from "to do" to "done". You have to move it to "in progress" then "in review" then "in qa" then "done", even if in fact, the ticket just tracked the need to do a quick code cleanup that happened to get done as part of some other task. There's no justification for this type of thing beyond over-empowered project managers.
I saw how that culture evolved over time as the company got bigger. It didn't start out that way. JIRA was once a bug tracker for us. It became a some sort of flowchart madhouse with horrifically convoluted processes around it. Partly yes, because the company felt a need to hire project managers, and partly because the tool existed and therefore there was something for them to fiddle with all day. If they didn't have the tools to create over-engineered processes, it would be less likely to occur.
At some level, yes, JIRA just enables problems, it doesn't directly create them. On another level, its whole structure encourages that way of thinking.
Yet you claim because YOU've seen it work, everyone else must be wrong?? ironic ?
Imagine having a guy in Dev that can fix your workflow so that "Start working" is not hidden in the dropdown menu.
That being said, despite that I personally don't love Jira I do think there are some cases where you need particularly complex workflows (e.g. compliance use cases) where Jira's complexity is fully justified.
And we know our tool is not for everyone. If your team is happy using Jira, power to you. But I think it really is important that the team is happy with it, not just the bosses.
What kind of organization doesn't have real OKR's or performance metrics? Do you draw a pretty picture with sunshine and rainbows and report that to investors?
I report actually meaningful numbers to my investors in terms of value delivered to users, not number of tickets churned through.