If you're using scrum you should know that there is a clear difference between tasks and stories. A story is something that is valuable to user. A task is a step to produce that value to user.

So, how shall we define a bug?

Is it something we should just fix?


Is it something that will put more value to user?

  • 9
    A great, classical question that every Agile methodology does not really address.
    – ashes999
    Commented Mar 3, 2011 at 18:33
  • 1
    By a bug do you mean a problem existing in a shipped version, or do you mean mid-iteration feedback from test that a story is not done?
    – Nathan
    Commented Apr 6, 2016 at 1:05
  • If a story is not done, it's not merged yet, so there are no bugs. By a bug I mean something that you can't easily say what's the cause of wrong behavior and when it was introduced.
    – Vanuan
    Commented Apr 6, 2016 at 19:37
  • 1
    Nobody yet stated out the truth: Scrum doesn't know Stories, neither tasks. Both words are not contained in the official scrum guide! So everything that follows is opinion, not more.
    – Argeman
    Commented Oct 12, 2018 at 11:32

15 Answers 15


I use a modified version of Scrum with my teams in week long sprints. The product backlog is ordered from top to bottom in order of importance. The development team takes items off the top of the stack and works on them.

If the feature isn't done at the end of the week, we talk about what will be done at the end of the next sprint, and work continues on the incomplete items.

In Managing Bugs in Scrum, the author, Mark Summer, suggests treating bugs as the same as a partially implemented feature. If you really think about it, that's exactly what a bug is. It's a specific part of a feature that is not completely implemented.

I currently have a bug list and a feature list. I am considering merging them and treating the bugs as incomplete features, as suggested by the blog author. This will greatly simplify the challenges I face in prioritizing tasks, and it will make it easier for developers to pull tasks off the product backlog stack.


My recommendation to teams I'm coaching is to separate bugs to two kinds:

  • The bugs/defects that are due to a failure in CURRENT work (e.g. story from current sprint) - for those I recommend tracking them as tasks on that story, and as blockers to that story being DONE/Accepted.

  • Bugs/Defects that are detected but are understood to have been there for some time now, maybe even already there in production - for those, treat them as backlog items that you need to prioritize. Thats usually a Product Management/Ownership decision/policy. The end result CAN be that you will fix them right now, but it depends on the priority.

  • Some authors say you should treat all the bugs with the top priority as they block currently or previously introduced features. Commented May 17, 2011 at 20:32
  • @BartoszRakowski. I would agree but I believe it is a matter of triage. If your team accepts the quality with a few bugs then that is something they manage through that process. There may be a cost benefit to get the feature out with a a minor bug.
    – aqwert
    Commented Apr 5, 2016 at 20:03

The wonderful thing about agile is that we retired concepts such as the requirements baseline so for an agile team the difference between a bug and a story is not an argument worth having. Both represent "stuff" you need to.

If the bug is part of the work being done in an iteration/sprint and we want to fix it in that sprint/iteration then treat it like a task. Otherwise put it on the product backlog.

If the bug is on the product backlog then there is value in fixing it otherwise it should not be on the backlog. The bug should also be estimated otherwise you will have difficulties planning work and measuring.

There is one special case where new development exposes a latent bug so severe that it impacts the whole iteration and I don't think there is an easy answer to this one.


For me it depends on the size, severity and when it is found.

If it's found during testing of a planned feature, it goes back into development to be re-worked on, and discussed in the scrum.

If it's major, red alert, red-flag stuff then it probably needs it's own task to be inserted into the next sprint.

If during general testing a heap of smaller, ordinary priority bugs are found, I tend to make up cards that say "fix 5 outstanding bugs" (or whatever suitable number), assign it a small value and but it in the backlog with all the other tasks.

Don't get hung up on the terminology - just make sure they can be tracked, repaired and accounted for.


What's the difference between a story and a task? Or a story and an epic? Or, a bug and a story?

In my opinion, it's all work.

If a bug is found in a story we're working on in the current sprint, the story is moved back to the sprint ready queue and flows back through the process.

If it's something unrelated to the current sprint and gets prioritised by the PO, whether it's a bug with previously delivered work or something new, it's moved to the sprint ready queue and flows back through the process.


I agree with: - if part of work on current feature, treat it as part of the sprint and not a separate defect - if outside of the sprint (e.g. from production issue) then create a Bug item on the backlog.

Should you give them Story points:

  • Yes: means they are treated just like stories and help with the accuracy of your planning process. However, it also implies that they add business value and form part of your team velocity measure which they shouldn't

  • No: means that they are not treated as adding business value and punishes the velocity if you have a quality issue that needs addressing and falling velocity would be an indicator. It also means that you may find it hard to plan your releases against the rest of your backlog.


A bug is bug per se and should be treated as a task. I see no difference, you can have a sprint with tasks of bug fixing.

  • But shouldn't bugs appear in a backlog? Tasks and impediments should not.
    – Vanuan
    Commented Feb 25, 2011 at 22:59

For me the bug in implementation is usually a task.

As for bugs in design/architecture these are usually not so easily fixed and tend to end as a story.


Something that puts more value is a feature or a story. A bug is something wrong in a feature/story that has been completed.

  • 1
    So, is it a task? Or incomplete functionality?
    – Vanuan
    Commented Feb 25, 2011 at 23:13
  • Please be more specific "A bug is something wrong" yes we know, but Vanuan asked how to treat a bug in scrum. Commented Feb 26, 2011 at 21:20

To take a page from Notch, creator of MineCraft:

I've got a few plans and visions, but my only true design decision is to keep it fun and accessible. There's no design doc, but there are two lists; one for bugs, and one for features I want to add but think I might forget.[1]

His approach implies that, like others have said, both represent items of software that need to be delivered. That said, combining the lists like like jmort253 has suggested would help prioritizing the backlog.


With our team, we treat them as a hybrid item. The way we do Scrum, stories always get points, and tasks never do. Bugs don't get a story point value assigned by the team. HOWEVER, when we go to commit our Sprint backlogs, we need a way to estimate bugs, right? For purposes of planning and velocity, we ballpark every single bug at a 2-point story--while some are much larger and some much smaller, we find that this works out well for estimation purposes.


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:

  1. 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.

  2. 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.


A bug is an output of "Verification" and an input to "Project Planning" and "Requirements Development" (according to CMMI). Thus, in order to keep a transparent traceability between artifacts you should refer to your bugs when making changes to "stories" and planning new "tasks".

  • 2
    I'm not sure if I understand why reference to CMMI is apropos here. CMMI is one of the heavyweight approaches that inspired the Agile Manifesto.
    – Ken Clyne
    Commented May 18, 2011 at 2:34

A practice I've heard of is grouping a number of related bugs into a single product backlog item. This makes sense to me as there might be hundreds of bugs in a large system, and keeping track of all of them as separate product backlog items would incur a considerable amount of backlog grooming waste.

It is also easier to attribute end user value this way, and we also avoid estimations in fractions of a story point that otherwise would be inevitable for trivial bugs.

  • But can there be any trivial bugs? Although the fix might be 1 line of code, is deployment of the solution after that fix trivial? If it's an unfinished task or a poorly implemented one, then perhaps it is a continuation of an existing task, or a new one and not necessarily a bug. Commented Sep 25, 2023 at 5:32

So there's some ambiguity of terms here that I think we need to address first. Let's all make sure we agree what a "bug" is. I would consider a bug to be a problem in the software relative to what the product owner would like the software to do, that was not introduced during the current sprint.

With that definition of a bug, I think it somewhat clarifies how the bug should be treated. The software is behaving in a way the PO does not like, so while in one sense they may be putting in a bug fix request, in another sense, they are simply putting in a feature request. From that perspective, it seems pretty clear that bugs should be treated as stories and work as such.

Now from the trenches. In my experience, what we would more classically refer to as bugs (badly behaving software), have had higher variability in their actual size vs. estimated size than a 'standard' story. I don't think that's a compelling enough reason for bug fixes to NOT be treated as stories, but it is something that I've noticed. One technique I've used to overcome this is having the development team spend a few minutes before estimating to look into the bug. I encourage a lightweight review of the problem, and I think it has helped with the accuracy of the estimation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.