Backlog Groups
Backlog groups (formerly called themes) are hierarchical functional groupings used to segment your backlog. They're typically used to represent functional components of your system. They can be used as filters during the planning and tracking process and to report on progress and plans from this higher-level perspective.
Who Uses Backlog Groups
- Product Owners: Organize backlog items by functional components and track progress at the component level.
- Scrum Masters: Use backlog groups to balance sprint planning across system areas and filter reports by component.
- Team Members: Assign stories to appropriate functional components and track progress within their area of focus.
- Portfolio Managers: Monitor component-level progress across multiple projects using hierarchical backlog group structures.
Permission Requirement
To view backlog groups, you must have Read access to the Product Planning area and select a specific project (backlog groups aren't visible when "All Projects" is selected). To create, edit, assign stories, close, or delete backlog groups, you must have Edit access to the Product Planning area. Moving backlog groups between projects in the hierarchy requires Edit access to both the source and target projects.
How Backlog Groups Work
The Backlog Groups page is located in the Product Planning section. This page is divided into two grids:
- Backlog Groups grid shows all the backlog groups in the selected project to which backlog items can be assigned.
- Backlog grid shows the stories that can be assigned to backlog groups.
Backlog groups have a hierarchical structure. You can create child backlog groups to roll sub-features up into larger groups for tracking purposes. Parent backlog groups display totals that include all of their backlog and the backlog of their children.
Key Benefits
- Visual progress tracking: Progress bars on the Backlog Groups grid give you a quick view of progress by showing the amount of estimate completed and remaining to be done.
- Detailed tracking: The Backlog grid shows the detailed progress of the backlog items related to each backlog group.
- Flexible organization: Use child backlog groups to roll sub-features up into larger groups for tracking purposes.
- Reporting and filtering: Backlog groups can be used as filters on many common reports such as Burndown, Velocity Trend, Cumulative Flow, Estimate Trend, and Test Run Trend.
Project Hierarchy and Scope
Your selection in the project or increment hierarchy determines what selections you'll be able to make when managing relationships. Only projects below your selection will be available.
When the All Projects level is available and selected in the Project Navigator tree, backlog groups aren't visible. Select a specific project to view and manage the backlog groups applicable to that project.
Use Cases
Product Owner Organizing Backlog by System Components
A product owner manages an e-commerce platform with multiple functional areas. They create backlog groups to represent major components: "Checkout & Payment", "Product Catalog", "User Accounts", and "Search & Discovery". Under "Checkout & Payment", they create child backlog groups for "Payment Processing", "Shopping Cart", and "Order Confirmation". They assign stories to appropriate backlog groups. The Backlog Groups grid displays progress bars showing that Checkout & Payment is 60% complete (40 of 65 story points done), while Product Catalog is only 25% complete. This visual tracking helps communicate component-level progress to stakeholders.
Scrum Master Using Backlog Groups for Sprint Planning
During sprint planning, a scrum master uses backlog groups to balance work across system areas. They filter the Product Backlog by backlog group "User Accounts" to view all account-related stories. The Backlog Groups grid shows User Accounts has 32 story points remaining with 18 already completed. They schedule 13 points of User Accounts stories for the upcoming sprint, ensuring the team makes progress on this component while balancing other priorities. After assigning stories, they switch the filter to "Search & Discovery" to identify additional sprint candidates from a different component.
Team Analyzing Progress with Backlog Group Reports
A development team uses backlog groups to filter their Burndown and Velocity Trend reports. They generate a Burndown report filtered by backlog group "Mobile App Features" to track progress on the mobile initiative specifically. The report shows the team has completed 85 of 120 story points for mobile features over the past four sprints, with 35 points remaining. They compare this to the "Web App Features" burndown showing 95 of 100 points complete. This component-level reporting helps the team understand whether they're making balanced progress across product areas.
Product Manager Creating Hierarchical Backlog Group Structure
A product manager sets up a hierarchical backlog group structure for a healthcare application. Top-level backlog groups represent major system areas: "Patient Management", "Clinical Workflows", and "Reporting & Analytics". Under "Patient Management", they create child groups: "Patient Registration", "Medical History", "Appointments", and "Billing". Under "Clinical Workflows", child groups include "Physician Notes", "Orders & Prescriptions", "Lab Results", and "Imaging". This multi-level structure allows progress tracking at both high level (Patient Management: 45% complete) and detailed level (Patient Registration: 80% complete, Billing: 20% complete).
Portfolio Manager Understanding Component Progress with Parent Rollup
A portfolio manager reviews an epic assigned to three teams working on different components. They open the Backlog Groups page to see component-level detail. The parent backlog group "Payment Modernization" shows 110 story points total (68 complete, 42 remaining). Child backlog groups reveal imbalanced progress: "Payment Gateway Integration" (30/30 points, 100% complete), "Fraud Detection" (18/40 points, 45% complete), and "Payment History UI" (20/40 points, 50% complete). This rolled-up view helps the portfolio manager identify that Fraud Detection and Payment History UI need additional focus or resources to complete the epic on schedule.
Frequently Asked Questions
What's the difference between backlog groups and portfolio items?
Backlog groups are horizontal functional slices used to organize stories by system component or feature area (e.g., "Search", "Authentication", "Reporting"). Portfolio items are vertical hierarchies representing business initiatives or deliverables (e.g., Epics, Features). A single epic might span multiple backlog groups. For example, an epic "Improve User Experience" could include stories in "Navigation" (backlog group), "Search" (backlog group), and "Settings" (backlog group). Use portfolio items to track business value delivery and backlog groups to track technical component progress.
Why can't I see backlog groups when "All Projects" is selected?
Backlog groups are project-specific assets. When "All Projects" is selected in the Project Navigator tree, Digital.ai Agility cannot display backlog groups because different projects have different backlog group structures. To view and manage backlog groups, select a specific project from the Project Navigator. The Backlog Groups page then displays all backlog groups defined for that project.
How do child backlog groups roll up into parent backlog groups?
When you create child backlog groups under a parent, the parent's totals automatically include all backlog assigned to its children. For example, if parent backlog group "User Management" has three children ("Login", "Registration", "Permissions"), and Login has 20 points assigned, Registration has 15 points, and Permissions has 10 points, the User Management parent displays 45 total points. The parent's progress bar reflects the aggregate completion of all child backlog groups plus any stories assigned directly to the parent. If the parent progress doesn't match expectations, verify that stories are properly assigned to child backlog groups and that all child groups are correctly nested under the parent.
Can I assign a story to multiple backlog groups?
No, each story can be assigned to only one backlog group. This constraint ensures clean reporting and prevents double-counting in progress calculations. If a story logically belongs to multiple components, choose the primary component or break the story into smaller stories assigned to different backlog groups. For cross-cutting concerns (security, logging), consider whether a dedicated backlog group makes sense or if these aspects should be captured as tasks within stories assigned to functional backlog groups.
How do backlog groups help with filtering and reporting?
Backlog groups act as powerful filters throughout Digital.ai Agility. In the Product Backlog, filter by backlog group to focus on stories for specific components. Many reports including Burndown, Velocity Trend, Cumulative Flow, Estimate Trend, and Test Run Trend support backlog group filtering. For example, generate a Velocity Trend report filtered by backlog group "API Services" to track velocity specifically for API-related work. This component-level reporting helps teams and stakeholders understand progress and velocity at a more granular level than project-wide metrics. Verify your current project selection in the Project Navigator if reports show unexpected results, as reports honor the global context filter.
What happened to themes and feature groups?
Yes, backlog groups were formerly called "themes" and "feature groups" in earlier versions of Digital.ai Agility. The functionality remains the same: hierarchical functional groupings used to segment your backlog. The terminology changed to "backlog groups" to clarify their purpose and avoid confusion with other planning concepts. If you see references to "themes" or "feature groups" in older documentation or exported data, they refer to what are now called backlog groups. All historical data and configurations automatically carry forward under the new naming.