Photo by Lucas Rosin on Unsplash
It's 2020, and JIRA doesn't allow you to archive projects, nor to export them, nor having feature parity with his own on-premises version. It's pretty clear. I dislike the tool, but these are not the main reasons we should avoid using it.
I work at a software development agency that executes projects for clients, mostly in the healthcare industry. We use JIRA a lot, including reporting, sprint planning, backlog grooming, addons, plugins, etc., and it has served us well all these years. But as we grew as a team, and as we seek perfection in how we execute projects I realized that the mere nature of the tool, this is, being prepared to work on small, discrete pieces of information (call them tickets, stories, bugs, etc.) is the very thing that slows us down.
What's JIRA
When using a tool, it's essential to understand what it's optimized for. For me, JIRA is optimized for chunking features into smaller pieces, relating them together, and keeping a log of who did what when. This is great when you have something to chunk, but most often than not, there's nothing to chunk yet.
We use JIRA -or any similar software- before understanding what to do. I've seen projects without any documentation, but hundreds of tasks on a board. You may think it's not the tool's fault, but the leader's for adding such tasks before knowing what to build, I'll argue that those leaders were left with a tool that his sole input are tickets, so they figured their job was to feed it with lots of them.
What's the problem with it
The tools we use shape how we work, and it turns out that we don't need a ticketing system, or at least, we don't need it for starting a project. I'll argue that we don't even need it for executing it.
To develop better software aligned with our clients' and users' requirements, we must understand their needs and use tools that favor the narrative. A tool that puts everybody in context and describes intentions. We need software that's able to tell a story instead of dividing it.
I feel so much time is wasted in ticketing. Bookkeeping, triaging and answering questions that at the end, the team is left only with fragmented pieces of reality and, too often, contradictory ones.
Being required to write a story that provides context and communicates the intention for feature X is much harder than creating 20 tickets with incomplete and contradictory ideas, and then, leaving the engineers to figure out the rest. With luck, they will figure out before writing the code, most of the time not. But that's ok, we can always create more tickets now with a better understanding of the world.
What to do then
I prefer to specify context-aware features that tell a story and illustrates the intention instead of splitting a feature into multiple tasks early in the process.
It requires more dedication from product managers, more writing, and thinking profoundly and upfront about the problems that need to be solved. Engineers also dislike the idea of not having everything arranged in tickets, but rather a massive piece of text that describes the problem instead of the steps to solve it.
Why doing something that everyone thinks it's worst? Well...when choosing to tell instead of splitting the problem, we are creating a more cohesive story, that makes sense as a whole, and it challenges itself as well. All this doesn't happen with tickets, they are artificial boundaries.
How to do it
I'm starting to write long-form feature definitions in Notion -I'm also writing this post in Notion-. Being deliberately slow at writing them and letting the concepts sink for more than a couple of days before making it available to the team. I try to be very explicit about the context and what's the takeaway for the user.
Only after this exercise I chunk the work -or let the engineers chunk it themselves- with a Notion inline database inside the feature definition, so devs can move things around. Still, this database is always constrained to the main feature description, you cannot look at one without looking at the other.
So far it works for me, and for the handful of people trying it, but my goal is to be able to make the switch out of JIRA, most importantly, out of the ticketing mindset. Yes, I lose advanced reporting, and yes, it requires more discipline from everybody in the team, but the gains are higher. Product managers stop splitting things early on and default to telling a story, engineers, on the other hand, are tasked with understanding the story and only then break them as they see fit.
Hope you liked it, and please let's discuss 👇
Thanks to Gabo, Masse, Gustavo, and Fadi for reviewing the post and helping me organize these ideas.
Latest comments (3)
I totally agree with you on "The tools we use shape how we work" and I think tools like Notion let you cover not just the things that Jira does (maybe without the reporting stuff) but gives you a complete and totally related set of tools to tackle everything that we could need in a project and at least for me, if you have a lot of different tools for specific tasks each, I end up using the minimum mandatory ones and keep the others out.
I find it interesting that you mention Notion, a tool I like to use myself. But I have to disagree with you about Jira. I actually see it as a leadership problem. The people responsible for the project are just overstrained with the tool. But in connection with Confluence (another product from atlassian) it's great. I'm doing the same thing as you do in Notion, in Confluence. And then create the necessary Jira tasks out of Confluence. They work great together.
Thanks for the comment!
I've tried Confluence long time ago and my memory could fail, but I don't think it does as well as Notion in any of the competing features. Yes I can use them in tandem, but I still prefer the freedom I have from Notion (I think of it has a feature) instead of the questionable criteria Jira and Confluece take on managing projects and feature discovery.