--- title: "Bug Tracking Project Template | Orangescrum" description: "The Bug Tracking template starts a project on a board with a four stage defect workflow. See exactly what it sets up, the statuses QA teams add." canonical: https://www.orangescrum.com/project-templates/bug-tracking --- # Bug Tracking Project Template | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Project templates](/project-templates) / Bug Tracking Project template # Bug Tracking Template: A Board _Built for Defects_ Four stages out of the box, and a separate defect workflow you can point at your own status list. Most QA teams add three or four statuses in the first fortnight, and this page tells you which ones. Available in[Cloud](/pricing "Cloud - included")[Self-Hosted](/self-hosted "Self-Hosted - included")Open Source [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=template_bug-tracking)[Book a Demo](https://calendly.com/orangescrum) Bug and issue tracking is in Cloud and Self-Hosted · Unlimited users on every plan ## What the Bug Tracking template sets up Choosing Bug Tracking starts the project on a board with the Bug Tracking Workflow, which is four statuses: Backlog, Ready, In Progress, and Done. Work is grouped into task groups. It is important to be accurate about what it does not do: it does not switch on a separate defect module, and it does not enable sprints or epics. Orangescrum does hold defects as their own work item type with their own status workflow, and a project has a defect workflow setting separate from its task workflow, but you choose that yourself rather than inheriting it from the template. The board ## The four stages _it starts with_ Deliberately short. It is a queue you can start using in the first minute, and the statuses a QA team really needs are the ones you add after a week of real traffic. 01 Backlog Reported, not yet triaged. Nobody has decided whether it is real or how serious it is. 02 Ready Triaged, severity agreed, owner assigned. Waiting to be picked up. 03 In Progress Somebody is investigating or fixing it right now. 04 Done Fixed and verified. The queue no longer holds it. Add your own statuses from the board or the status workflow page. The four most teams add are Cannot Reproduce, Duplicate, Awaiting Information, and Ready to Retest. On day one ## What you get _on day one_ Enough structure to start logging defects immediately, and no structure you have to unpick later. A board as the landing page The right first screen for a live queue, because you want to see where things are stuck at a glance. A four stage defect workflow Backlog, Ready, In Progress, Done. Short enough that nobody has to be taught it before the first bug goes in. Drag and drop triage Move a card from Backlog to Ready and the status changes. Triage becomes a fifteen minute pass rather than a meeting. Task types and labels Classify by component, environment, or severity, and filter the board by them. A separate defect workflow setting A project has its own defect status workflow, chosen independently of the task workflow. The template does not set it, but it is there when you want defects to move through different stages from tasks. Room to add the awkward outcomes Cannot Reproduce, Duplicate, and Deferred are real outcomes, and they need statuses or they clog the queue as pretend open work. Who it is for ## Who _picks this one_ QA teams The main case. A queue that shows you what is untriaged, what is being fixed, and what is waiting to be retested. [Learn more →](/bug-and-issue-tracking) Support engineers Customer reported problems that turn out to be product defects, escalated from a ticket and linked back to it. [Learn more →](/ticketing-software) Teams running incidents The same board shape works for live incidents, with the incident statuses on top. [Learn more →](/use-cases/incident-management) First week setup ## What to configure _after a week of real bugs_ Do not configure this on day one. Log real defects for a week, then add exactly the statuses and fields you found yourself wanting. Statuses to addUsually 4 - Cannot Reproduce, so failed investigations leave the queue honestly - Duplicate, linked to the original rather than silently closed - Awaiting Information, for bugs blocked on the reporter - Ready to Retest, so QA can find what is waiting on them Fields to addCustom fields - Environment, so you can filter production from staging - Affected version, so you know what shipped broken - Severity, as a field rather than a label people forget - Detection method, if you want to know how bugs are found Rules to write downOne wiki page - What critical, high, medium and low actually mean - Who runs the daily triage pass, and when - The rule for closing: retested, not merely fixed - When a bug becomes a won't fix, and who decides The built in templates set structure rather than content, so none of this arrives ready made. Once your defect project works properly, save it as your own template so the next one starts the same way. The problem ## What this template _fixes_ Bugs in three places ✓ One queue, on a board, with a status on every item. No visible triage stage ✓ Backlog and Ready are separate, so the untriaged queue is a filter away. Defects sit in the wrong workflow ✓ A defect workflow set separately from the task workflow. How to start ## Start a project _from this template_ Five minutes to create, and then leave it alone for a week. 1. 1Create a project and choose Bug TrackingThe project opens on a board with the four stage defect workflow already in place. 2. 2Invite QA, developers, and supportSupport are the people who find most of the bugs that matter. Unlimited users on every plan means they belong in the project. 3. 3Log real bugs for a weekResist configuring anything. You will learn more from a week of real traffic than from an afternoon of planning. 4. 4Add the statuses you actually missedUsually Cannot Reproduce, Duplicate, Awaiting Information, and Ready to Retest. Add them from the board. 5. 5Add the fields you kept asking forEnvironment and affected version, as custom fields so you can filter and report on them. 6. 6Write the severity definitionsFour sentences on a wiki page, linked from the project. This is what stops everything being marked critical. 7. 7Set up a daily triage passTwo people, fifteen minutes, filtered to the Backlog status. Daily beats fortnightly by a wide margin. 8. 8Set the defect workflow if you need oneIf defects should move through different stages from ordinary tasks, point the project's defect workflow at its own status list. Pairs with ## The features _this template leans on_ Custom fields are on the Pro plan and above, and in Self-Hosted. Advanced search is Self-Hosted. [Bug and issue trackingDefects alongside the delivery work](/bug-and-issue-tracking)[Custom status workflowThe statuses you add in week two](/custom-status-workflow)[Custom fieldsEnvironment and version as real data](/custom-fields)[Test case managementClose a defect against a passing test](/test-case-management)[Bug triage use caseThe full triage workflow, step by step](/use-cases/bug-triage)[Advanced reportingResolution time and where bugs come from](/advanced-reporting) Frequently asked questions ## Bug Tracking template _FAQ_ What statuses does the Bug Tracking template create? Four: Backlog, Ready, In Progress, and Done. This is the Bug Tracking Workflow. Most QA teams then add Cannot Reproduce, Duplicate, Awaiting Information, and Ready to Retest once they have seen a week of real defects. Does this template switch on a separate bug module? No, and it is worth being precise about that. It starts the project on a board with a defect oriented status workflow. Orangescrum does track defects as their own work item type, and a project has a defect status workflow separate from its task workflow, but you set that yourself rather than inheriting it from the template. Should I configure the statuses before I start? No. Log real bugs for a week first. Teams that design the workflow up front consistently build stages nobody uses and miss the ones they needed. Can defects follow a different workflow from tasks? Yes. A project has a defect status workflow that is chosen separately from its task workflow, so bugs can move through Cannot Reproduce and Ready to Retest while ordinary tasks stay on a simpler flow. How do I stop everything being marked critical? Write down what each severity level means, in four plain sentences, and link it from the project. Severity inflation is nearly always a definition problem rather than a discipline problem. Which plan do I need? Bug and issue tracking is in the Cloud and Self-Hosted editions. Custom fields, which is how you capture environment and version properly, are on the Cloud Pro plan and above and in Self-Hosted. Can I link a defect to the test case that found it? Yes. Test case management lets you raise a defect from a failed test and link them, so a defect is closed against a passing test rather than a developer's word. Can support tickets become defects? Yes. A customer ticket that turns out to be a product defect can be raised as a defect and linked back to the ticket, so support can see the fix progress without chasing engineering. ## Get your defect queue on one board Four stages to start, the rest added when you know what you need. [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=template_bug-tracking_cta)[Book a Demo](https://calendly.com/orangescrum) ## Other project templates [Agile Scrum templateWhere the fixes get scheduled](/project-templates/agile-scrum)[Task Tracking templateTwo statuses, for simpler queues](/project-templates/task-tracking)[Kanban templateA generic board to shape yourself](/project-templates/kanban)[Procurement templateAnother request driven queue](/project-templates/procurement) [See all project templates →](/project-templates)