Jira and Bitbucket both started for me at Halcyon, my first company. The team ran on Kanban boards inside Jira, with Bitbucket handling the repos. I was on that board though, not setting it up. Someone else had already configured the workflows, the permissions, the automation rules, long before I joined. I just worked inside it.
Bitbucket followed me into college too. During my capstone, a few years later, my team used it to manage our repos, until we ran into its member limit. Bitbucket capped how many people we could add, and once we hit that ceiling there wasn't much choice left. We moved everything to GitHub and stayed there.
Since then my daily toolkit has changed completely. At Cody, where I work now, the team uses Asana, but not the way Agile teams usually talk about it. There's no story points, no estimation ceremony. It's just timelines, how many hours a feature is expected to take, plus tracking who's assigned to what and whether it's finished. Linear and n8n round out the rest of what I actually touch day to day, along with TeamCity for anything JetBrains related.
So when I opened Jira again recently, mostly out of curiosity, it had been sitting untouched since around 2022 or 2023. And what I found had clearly grown up while I wasn't looking.
The automation side came easily. Assigning a ticket to someone on creation, setting up a rule that fires on a workflow trigger, none of it felt foreign. Underneath Atlassian's branding it's the same "when X happens, do Y" logic I already use every day in n8n or Zapier. Jira even buries an Incoming Webhook trigger inside its automation settings, one that accepts a POST from anywhere, Stripe included, and lets you read the payload through a smart value called {{webhookData}}. If you already know how to route a Stripe webhook into n8n and drop the result into Discord or Telegram, you already understand nine tenths of what Jira automation is doing. Just a different destination node wearing a different name.
Story points made me stop and actually think. I'd vaguely known the term for years without ever needing to use it, since nothing in my own experience worked that way. Turns out they aren't a project-level setting at all. They're a field on each individual issue, filled in during backlog refinement or sprint planning, before the work starts. They represent relative effort and uncertainty rather than hours, which is why teams lean on Fibonacci-style numbers like 1, 2, 3, 5, 8, 13 instead of something linear.
That led to a harder question. How do you actually know something is done? Jira doesn't answer that for you. Dragging a card into Done just flips a status field, it doesn't verify anything happened. If you want that verification to mean something, you add a review or QA column before Done so someone other than the person who did the work has to move it there, or you set up workflow validators that block the transition unless certain conditions are met. If someone marks something done that isn't, there's no special undo mechanism, you just drag it back to In Progress like any other status change.
The part I got wrong outright was Groups and Teams. I assumed Groups sat above Teams in some kind of hierarchy, since Groups are the thing that provisions permissions. It felt logical. It was also wrong. They're two separate systems running in parallel, not nested at all. Groups are managed by administrators and control real access: permission schemes, security levels, notification schemes. Teams can be created by anyone and mostly exist to make collaboration visible, showing who works with who across functions. Teams don't touch permissions at all right now, and you can't fold a Group into a Team either. They're just two different kinds of membership that happen to overlap on the same people.
Looking back at why I got that wrong, it's not really about Jira being confusing. Every time I've actually used these tools, it's been either as one member inside someone else's already-configured system at Halcyon, or completely solo. Personal projects, tinkering on my own, no second person on the other end of a permission scheme to expose whether my mental model held up. You can read about groups and teams and permission schemes as much as you want, but until you've had to configure access for an actual teammate who'd notice immediately if something was broken, that knowledge stays theoretical. That's the real reason a tool I've technically "used" before still left me guessing on the parts that only matter once other people are involved.