Feature, Story, Task, Bug
The last good thing that ever happened to my team was the day we stopped arguing about whether something was a Story or a Task.
I want to be honest about the conditions before that day. We had a backlog. We had a board with columns. We had labels. We had a tool — a very expensive tool that we had configured to within an inch of its life. And we had, every Tuesday afternoon, the same forty-minute argument.
It always started with the same word: story.
“This is a story.”
“It’s not a story, it’s a task.”
“It’s a task with a story attached.”
“Fine, it’s an epic.”
“It’s not an epic. It’s a vibe.”
Forty minutes. Every Tuesday. For a year.
The problem wasn’t the tool. The problem was that we had collected words — Feature, Story, Task, Bug, Epic, Initiative, Theme — and we had never agreed, out loud, on a whiteboard, in writing, what each of them actually meant. We had vocabulary without grammar.
So we agreed. Four words. Clear edges. And the meetings got shorter.
The Four Shapes
The terms are not exotic. They are also not interchangeable. Here is what we settled on, and what I would recommend to anyone:
A Feature is a capability the product gains. It is something you could brag about in a release note. “You can now leave product reviews.” It is big enough that the customer notices, small enough that it doesn’t span a year. A Feature is a noun phrase, and it usually has Stories underneath it.
A Story is a single slice of user-visible value. It has a hero — usually the customer, sometimes the sales rep, occasionally the internal admin. It fits in a sprint. It has acceptance criteria you could hand to QA. A Story is the unit of “we shipped something this week.”
A Task is the work itself. “Add the POST endpoint. Create the form component. Write the migration.” A Task lives under a Story. It is owned by one person and fits in less than a day. Tasks are the laundry of software — unglamorous, plentiful, and somebody still has to do them.
A Bug is a gap between what we said the software would do and what it does. It sits next to the other three, not inside them, because bugs grow wherever they want to grow. That is also why “it’s not a bug, it’s a feature” is funny — because the line between the two is real, and almost every developer has tried to walk across it at least once.
That is the whole vocabulary. Get them right, and most of your standup arguments stop happening.
Why the Hierarchy Matters
The hierarchy lets different people in the company read different layers while still looking at the same project.
The VP of Sales does not want to read Tasks. They want to know whether the Feature ships before the user conference. The product manager doesn’t want to triage every Task — they want to know which Stories landed and which are stuck. The engineer in standup does not want a Feature-level update — they want their own Tasks for the day, in priority order. The support agent filing a defect does not need to know whether the underlying capability is a Feature or a Story — they just need to file a Bug and trust it will route somewhere.
That is the part I underestimated for years. I used to think backlogs were a project-management problem. They are actually a translation problem. The Feature/Story/Task/Bug hierarchy is the dictionary the team shares so it can talk to itself across roles without the words drifting.
When the dictionary is missing, the Megastory shows up.
The Megastory and Other Monsters
Once you start watching for the anti-patterns, you can’t unsee them.
A Megastory is a “story” that is actually five stories in a trench coat. You’ll know it when you see it: it has six acceptance criteria, each one its own feature, and the team’s estimate is “well, between two and seven sprints depending.” A Megastory is what happens when nobody splits a Feature into proper Stories.
A Mystery Box is a Task whose description is the words “fix the thing.” Three days later, the person who picked it up cannot remember what the thing was, and the person who wrote it is on a beach in Croatia. A Mystery Box is a Task without the work a Task needs to actually be a Task.
A Ghost Bug can only be reproduced by one person, usually QA, usually at 4:55 on Friday. Ghost Bugs are an early warning that your test data, your environment, or your spec is unevenly distributed across the team. The fix is rarely the bug itself; the fix is closing the gap that let the bug live where nobody else could see it.
There are others — Schrödinger’s Story (both done and not done depending on who you ask), the Phantom Feature (a “feature” that is secretly a whole new product), the Russian Nesting Bug (you fix one and three appear). The pattern is the same across all of them. Each one is a category error: a piece of work being treated as the wrong shape, and the team paying for the mismatch.
One Question that Ends the Argument
If you take only one thing from any of this, consider this question. When the team starts to debate whether something is a Feature or a Story or a Task, ask:
“Does anyone outside engineering directly care about the outcome of this?”
If yes, and it spans multiple deliverables, it is a Feature.
If yes, and it is one deliverable, it is a Story.
If no, it is a Task.
If the answer is “they care because it’s broken right now,” it is a Bug.
That is the whole tree. It stops most arguments pretty quickly. The ones that don’t are usually a sign that you’re staring at a Megastory and you should split it before going any further.
I do not love rules of thumb, but I love this one. It costs nothing to ask, the team can answer it without leaving the room, and it produces a backlog that strangers can read. New hires read it on their first day and they actually understand the project. That alone has paid back the whiteboard session a hundred times over.
The Reframe
I am not saying backlogs are easy, but the hard part is the same everywhere in software: figuring out what to build and in what order.
The easy part, which is free and costs nothing but a shared agreement, is the part where everyone uses the same four words to mean the same four things.
- Get the hierarchy right and the meetings get shorter.
- Get the hierarchy right and your standup stops being an interpretation exercise.
- Get the hierarchy right and new hires can read your backlog and understand the project in a day instead of a week.
- Get the hierarchy right and the next hard conversation — about what to build next, about what to cut, about what to push back on with the customer — actually gets to happen.
Then put it on the wall.
