There is no correct answer to this, the important thing is that you understand the options and the impact that they will have on the way you manage the project and how your team can record/report their work.
In terms of kanban board style management, to make the most efficient use of the tools, I define the work items like this:
User Stories / Requirements / Bugs / Issues represent work requests that have specifically defined deliverable outcomes. Importantly, these items could be delivered as a single unit. When we communicate the status of the item we talk simply about the stage it is in and when we can expect delivery.
- We generally would not discuss the finer implementation detail unless there have been impediments that need feedback from the user or PM
Often these requests are raised from outside of the development team and may be tracked in some form by external stakeholders.
Tasks are the lowest tracked unit of work that can be assigned, Tasks can only have a single owner, that is the person who is responsible for completing that task. Tasks do not have child work items, they can be related to other tasks but a Task is the lowest child in the overall hierarchy.
- This is an important concept for Kanban board management, it is counter-productive to allow tasks to have child tasks. If a task needs sub-tasks the this really means that it should have been broken up into more granular blocks of effort to begin with. It is hard to represent nested tasks in kanban, if allowed this re-introduces a complexity that kanban tries to remove.
So the impact on Bugs as tasks (child) or stories (parent) is that if it they are tasks, then they cannot be broken down into sub-tasks. If they are stories then they MUST be broken down into at least 1 task that can be assigned.
This means that the real question becomes:
Is it a Bug at all, or is it just another Task to an existing Story?
In kanban paradigms each board is designed for a specific audience and this is where the definition of a Bug is important, software projects generally have two main audience groups Developers and Stakeholders. User Stories represent the requirements or expectation from the stakeholders. You would traditionally have a kanban view of these expectations for this audience. The associated child tasks are for the developers. Bugs are traditionally very similar to User Stories in that they can be raised from stakeholders and will require developer effort (tasks) to investigate, resolve, test and deploy. To the Stakeholders, a Bug has a state and they want to know when it will be fixed, but the developers may need to break that bug up into multiple efforts that may need to be assigned to multiple individuals to complete.
In very small teams and startup scenarios, a basic agile process with one board might be enough to start, all stakeholders are also developers or many of the developers might be involved in both the design of the requirements and the implementation.
At this stage, especially if developers are raising the majority of the bugs, then it may be pragmatic to manage Bugs as tasks that are subordinate to User Stories instead of adding an additional layer. If your bugs never need child tasks or to be broken down to assign to multiple people, then this should work well.
But if your Bug is managed as a task, what is the value of this definition? If Bugs simply have a higher priority, then you don't need to reclassify the item at all, it is just a higher priority task.
To the developer, a dev task and a bug task are both tasks that need to be worked on, the only difference might be in the deployment and test cycle and ultimately the communication. This is perhaps the best argument for not treating bugs as tasks, it doesn't add anything to the process to do so.
As your product and ideas evolve to include stakeholders who do not need to be aware of the specific implementation and where the implementors do not need to be distracted with the broader roadmap, it becomes more practical to manage the backlog of user stories and the communication of their progress at a higher level, rather than communicating the progress of individual tasks.
At this stage Bugs are more likely to be raised from end users, PM or other non-developer stakeholders. Even if you don't provide direct visible access to a stakeholder view of the kanban board, it is still helpful to maintain one so that you can manage the communication. This is when it becomes advantageous to manage Bugs as requirements that have assignable tasks.
The definition of a Bug now has functional value in your management process and allows you to track the higher level communications and expectations separately to the lower-level implementation.
There is a clear distinction between the development effort and the original request, and we can break the effort down to be more manageable or to involve review, testing and deployment efforts as discretely assigned tasks.
Tools like Azure DevOps support this natural evolution of Software Development projects and the management of them through the transition from startup to growth by allowing you the flexibility to change if Bugs are represented as Requirements or Tasks on the boards, see Show bugs on backlogs and boards.
To complete the work item definition lists, these are the higher level items for managing the project:
Features represents high level functional groupings of work requests, how you group them usually has more meaning to the external stakeholders and aligns with the product as the user see's it rather than how the code is organised.
- It can be beneficial to structure your code to be aligned with the Features but Features are a management and planning concept, your code should be free to evolve without being bound to the exact same structure. Forcing the two to be in alignment is asking your POs and Customers to have too much knowledge about the technical implementation.
Fundamentally A Feature is much longer lived than its child work items (specific requests). Features are broad concepts that might never really finished. They are likely to evolve over time and they become headings or groupings in future release notes and roadmaps.
Epics represent the highest level of conceptual grouping, often tied to specific products or modules. Epics are almost never finished, though there are points where you might cease work on certain areas.