How to prepare Jira boards and filters
This guidance is designed to help you achieve an optimal product integration experience for your organization. Keep in mind that best practices may vary depending on scale.
How to review team boards and filters in Confluence
- Navigate to the PI Planning prep page and see which projects and primary boards your Scrum and Kanban teams work from.
- Every team should have a board.
- Every board needs a filter owner, ideally a scrum master, product owner, or team lead.
- Identify any teams that require new boards: You'll need access to each team board setting and you'll need the ability to modify their filters. If you don't have access, it's best to work with each board owner to make adjustments. You will also need project admin access to look up custom fields.
How to review team boards and filters in Jira
- Locate the first team’s agile board
- Select board settings and view the filter query
- Build filters around these best practices:
- Use a team-based field to build a filter query. We recommend using the team field designated for Jira Premium or Jira Advanced Roadmaps. Or, use a pre-existing custom field you created for team selection across your organization.
- Confirm that the same team field is included in all issue types in the project.
- Filters should not include or exclude specific statuses. For example, if an issue is canceled in a Sprint, you would not want to exclude that from Sprint reporting. That issue may also be reopened or moved to the backlog.
- The filter should not include or exclude specific users. Team members change over time. Hardcoding users in filters require ongoing maintenance, and may cause you to leave out necessary users.
- Avoid date ranges in your filter because they will not scale effectively. Date ranges can be used in PI plan filters.
- Remember to modify and save filter changes.
- Examples of filter queries with the recommended team field included in Jira Cloud and Advanced Roadmaps: and
- Confirm that the board filter viewers in the filter permissions include user groups that will view and participate in the program. Viewer permissions for the filter are inherited in the plan as part of the issue source configuration. It might be easier to add "my organization" as a viewer group:
- Confirm that the board administrators are up-to-date and included on the team page in Confluence. You will reference this when creating the PI plan permissions. Consider adding release train engineers as owners for boards in their ART:
- On the board configuration, Select add rank for each team board filter to allow for prioritization in the backlog view:
- Repeat the steps above for all remaining teams in the program.
- Create new boards for any missing teams in the program and update the Confluence page with new team board information.
The recommendations below are optional, but they will improve the overall experience for end-users and administrators and will enable the program to scale.
Recommended board configuration additions:
- Configure the same columns across boards in the program, mapping the workflow statuses to the same columns.
- Use similar quick filters, especially "any," to assist with PI planning or prioritization.
- For the upcoming PI, schedule all future sprints with a standardized naming convention and sprint timebox dates. For example, if the standard is PI#_Team_Sprint#, then the sprint name would be PI1_Bruins_Sprint 1.
Recommendations for project configuration and governance
- As you review the board filters, confirm in the permissions section of project settings that each user has the correct project permissions for their role.
- Product owners and other users responsible for assigning issues to a sprint need the schedule issues permission for projects in the board filter.
- Release train engineers and other users responsible for creating, starting, and ending sprints need the manage sprints permission for all projects in the board filter.
- Users who can move items into the sprint (schedule issues) and create, start, or end sprints (manage sprints) should be considered editors for the PI plan in Advanced Roadmaps.
- Changes to project configuration, such as workflows, issue types, and permissions, may impact the board filter and board configuration.
- If a new workflow is added, you should map any new statuses to columns in the board configuration
- If a new issue type is added, make sure that the board filter does not exclude the new issue type.
- If permissions change, ensure team members can still view and edit tickets on the board.
- Consider establishing a change advisory board or governance process to review configuration changes that may impact the project, board filter, or board settings. Impacts on the PI plan settings and issue sources should also be considered.
- Use company-managed projects for consistency across the program. Boards based on team-managed projects (cloud only) can be included in a plan, but we suggest you review team-specific configurations for any impacts on the plan.
- If new teams are added to the program or portfolio in the plan, start by creating their board filter and board in Jira and then add their team and board as an issue source in the plan.
- Verified inventory of teams and boards to be included in the PI plan
- Optimized board settings and filters
- Creation of new boards, if needed
- Standardization and governance for scale
Was this content helpful?
Connect, share, or get additional helpAtlassian Community