Skip to main content

Defect Tracking and Reporting

Defects allow agile teams to plan and track fixes as separate assets within Agility. Teams can choose between two primary tracking approaches: planned and scheduled defects within sprints, or a continuous work queue.

Who tracks and reports on defects: Scrum masters monitor defect progress in sprints and generate reports for retrospectives and stakeholder updates. Product owners analyze defect trends to prioritize quality improvements and balance feature work with bug fixes. Team members track their assigned defects and update status as work progresses. QA engineers use defect reports to identify patterns and focus testing efforts on high-risk areas.

Permission requirement: Viewing defect reports requires project member access. Generating and customizing reports typically requires Team Member role or higher. Some advanced reports and dashboards may require Project Admin permissions to configure. Exporting reports may require specific export permissions. Scheduling defects in sprints requires Team Member role. Specific permissions depend on your organization's role configuration and report types.

Choose a Defect Tracking Approach​

Select the tracking method that best fits your team's workflow and defect volume. Both approaches are fully supported in Agility with no special setup required.

Method 1: Planned and Scheduled Defects​

Planning and scheduling defects is particularly helpful for large defects that require significant effort. Defects are treated like backlog items with respect to planning and scheduling, with size estimates factoring into the team's velocity. They can be broken down into tasks and tests to allocate work across multiple team members or identify required steps for larger efforts.

How it works:

  • Create and plan defects in the Product Planning area. Defects display in grid views and can be assigned to specific projects.
  • Review defects with the team during planning meetings.
  • Schedule defects in sprints or iterations alongside stories and other backlog items.
  • The Estimate attributed to defects rolls up in velocity calculations along with backlog item estimates.
  • Detail Estimate and remaining To Do for defects roll up into the sprint's totals.
  • Defects that are completed and approved should be closed to remove them from default tracking pages and indicate the work is complete.

Where to track:

  • Sprint or Iteration Tracking Pages: Monitor defects alongside other sprint work.
  • Team Scheduling Page: Plan defect capacity and assignments.
  • My Home Page: Team members view their assigned defects.

Best for:

  • Teams with large, complex defects requiring multi-day effort
  • Organizations tracking defect velocity and burndown alongside features
  • Teams that want defects included in sprint commitment and planning
  • Projects requiring detailed estimation and task breakdown for defects

Method 2: Defect Work Queue​

The work queue approach is easier to manage if you have lots of small defects. In this method, all defects are stored in a single prioritized list (the Backlog) and assigned directly to team members who work from top to bottom in priority order. New defects are added to the list, sorted by priority, and assigned to individual team members, but are not scheduled in a sprint or iteration.

How it works:

  • Create defects and add them to the Backlog without sprint assignment.
  • Sort defects by priority, defect type, or other criteria to establish work order.
  • Assign defects directly to team members.
  • Team members work on defects continuously, pulling the next highest-priority defect when capacity is available.
  • Teams typically don't define a size Estimate or Detail Estimate for defects in a work queue. Since these defects aren't contained within any sprints or iterations, they won't roll up into velocity calculations or sprint burndown.
  • Defects that are completed and approved should be closed to remove them from default tracking pages and indicate the work is complete.

Where to track:

  • My Home Page: Team members view and work on their assigned defects.
  • Product Backlog: Manage the queue, add new defects, and reprioritize.

Best for:

  • Teams with high volumes of small defects (bugs, minor issues)
  • Support or maintenance teams handling continuous defect inflow
  • Teams that prefer Kanban-style continuous flow over sprint planning
  • Organizations tracking defect throughput rather than velocity

Defect Reports​

Agility provides several built-in reports to help you track and analyze defect trends. Access these reports from the hamburger icon > Reports.

Sprint and Iteration Reports​

When tracking defects in sprints, use these reports to monitor progress:

  • Sprint Burndown: Shows remaining work (including defects) over the sprint timeline.
  • Sprint Dashboard: Displays sprint progress, including defect completion rates and status distribution.
  • Velocity Trend: Tracks team velocity over time, including defect estimates.
  • Cumulative Flow: Visualizes work in progress and completed, including defects by status.

Defect-Specific Reports​

Use Advanced Search and custom reports to analyze defect patterns:

  • Defects by Type: Filter defects by Defect Type to identify common issue categories.
  • Defects by Resolution: Analyze how defects are resolved (Fixed, Duplicate, Won't Fix) to understand team decisions.
  • Defects by Priority: Track critical vs. low-priority defect distribution.
  • Defect Age: Identify old, unresolved defects that may need attention or closure.
  • Found In vs. Fixed In: Compare defect discovery and resolution across releases or builds.

Team and Member Reports​

Track individual and team defect workload:

  • Member Actuals: View time spent on defects by team member.
  • Member Load Trend: Monitor defect assignments and capacity over time.
  • My Home: Personal dashboard showing assigned defects and status.

Best Practices for Defect Tracking​

  1. Choose one approach and be consistent: Mixing planned defects and work queue defects can confuse velocity tracking and reporting. Standardize your approach across the team.
  2. Close completed defects promptly: Closing defects removes them from active tracking pages and keeps reports accurate. Don't leave resolved defects open.
  3. Use appropriate estimation: For planned defects, estimate accurately to maintain velocity integrity. For work queue defects, estimation is optional.
  4. Define clear defect types: Use Defect Type consistently to enable meaningful reporting and trend analysis.
  5. Set priorities effectively: Ensure priority reflects business impact and urgency, not just severity. Align with your team's SLAs or support agreements.
  6. Review defect age regularly: Use reports to identify stale defects. Decide whether to prioritize, close, or delete them.
  7. Track resolution patterns: Monitor Defect Resolution data to identify trends (e.g., high duplicate rates may indicate communication gaps).
  8. Link defects to builds: Use Found In and Fixed In fields to track defect lifecycle across releases and enable root cause analysis.
  9. Monitor defect inflow: Track new defect creation rates to identify quality trends and adjust testing or development practices.
  10. Use filters and views: Create custom backlog views filtered by defect type, priority, or team to focus on relevant work.

Use Cases​

Development Team Using Planned Defects for Large Bug Fixes​

A development team encounters a critical performance defect affecting the checkout process. The issue requires database optimization, caching layer updates, and frontend changes, estimated at 13 story points. They create a defect in the Product Planning area, assign it to the Platform team, estimate it at 13 points, and schedule it for Sprint 23. During sprint planning, they break the defect into three tasks: database query optimization (5 hours), implement Redis caching (8 hours), and update UI loading states (3 hours). The defect's 13 points roll into Sprint 23's velocity, and the To Do hours appear in the sprint burndown chart. When completed, the team closes the defect, removing it from active tracking.

Support Team Managing High-Volume Defects with Work Queue​

A support team handles 50-80 small defects per sprint, mostly UI issues, configuration problems, and minor bugs requiring 1-4 hours each. They maintain a work queue in the Product Backlog filtered by Defect Type "Bug" and sorted by Priority. Defects are assigned directly to team members but not scheduled in specific sprints. Sarah pulls the top-priority defect (login button misalignment), fixes it in 2 hours, closes it, and moves to the next defect. The team tracks throughput (defects closed per week) rather than velocity. At standup, they review the queue's top 10 defects and reassign based on current workload, maintaining continuous flow without formal sprint planning.

Product Owner Deciding Between Tracking Approaches​

A product owner reviews their team's defect profile to choose the optimal tracking approach. They analyze the past quarter and find 70% of defects are small (1-3 hours), 20% are medium (half-day to full-day), and 10% are large (multi-day). They decide on a hybrid approach: large defects requiring 8+ hours are estimated, scheduled in sprints, and broken into tasks (planned approach). Small and medium defects go into a work queue where team members allocate 20% of their sprint capacity to continuous defect resolution. This balances velocity tracking integrity for significant defects with the efficiency of queue-based management for routine bugs.

A scrum master uses Velocity Trend and Sprint Burndown reports to analyze defect impact on team performance. They notice velocity dropped from 45 to 32 points in the last sprint. Reviewing the Sprint Dashboard, they see defects consumed 18 story points (compared to the usual 8-10 points). Using the Defects by Type report, they identify that "Production Issues" spiked due to a faulty release. They add this insight to the retrospective agenda, leading to the team implementing additional pre-release testing gates to reduce production defect volume in future sprints.

Team Lead Using Defect Age Report to Clear Backlog​

A team lead opens the Advanced Search and filters for defects older than 90 days with status "Open" or "In Progress". The report reveals 23 stale defects, many with outdated priorities or descriptions. They schedule a backlog grooming session to review each defect. Five defects are closed as "Won't Fix" (no longer relevant), seven are marked as duplicates of existing defects, six are reprioritized and moved to the active work queue, and five are closed because the features they referenced were removed. This cleanup reduces noise in defect tracking, allowing the team to focus on current, actionable defects.

Frequently Asked Questions​

How do defect estimates impact team velocity?​

Planned defects (scheduled in sprints):

  • Estimate values roll up into velocity calculations like story estimates
  • Example: 30 points of stories + 10 points of defects = 40 points velocity
  • Detail Estimate and To Do hours roll into sprint totals and burndown charts

Work queue defects (not scheduled in sprints):

  • Estimates do NOT affect velocity or burndown calculations
  • Teams track throughput metrics (defects closed per week) instead
  • Allows tracking feature velocity separately from continuous defect work

Best practice: Always estimate planned defects to maintain velocity integrity. Estimation is optional for work queue defects.

Can we mix planned defects and work queue defects?​

Yes, many teams use a hybrid approach with clear criteria:

  • Large, complex defects (8+ hours): Estimate and schedule in sprints
  • Small routine bugs (1-4 hours): Manage in continuous work queue

Define clear thresholds in your team's working agreement and apply consistently. This prevents confusion in velocity tracking and ensures the right defects are included in sprint commitments.

How do we keep defects from cluttering our backlog?​

Close defects promptly:

  • Closed defects disappear from default tracking pages and backlog views
  • Signals work is complete and removes noise from active planning

Review and clean stale defects:

  • Use Defect Age report to identify defects older than 60-90 days
  • Decide whether to prioritize, close, or delete them
  • Create custom backlog views filtered by "Status = Open" and "Priority = High or Critical"

Avoid leaving completed defects open - closing keeps your work list clean and reports accurate.

Why don't defects appear in my sprint reports or show wrong counts?​

Defects missing from sprint reports:

  • Defects only appear in sprint reports if scheduled in a sprint with estimates assigned
  • Work queue defects (assigned directly without sprint planning) won't appear
  • Use Defect Age reports and custom backlog views for work queue defects

Different defect counts across reports:

  • Reports vary based on date ranges (creation vs. close date)
  • Status filters (open only vs. including closed)
  • Sprint scope (specific sprint vs. all sprints)
  • Project hierarchy (child projects included or not)
  • To reconcile counts, check each report's filter criteria and date range settings