Splitting one project into two boards without corrupting sprints

Two defects. First, the sub-filter narrows what the board displays; the underlying filter still returns all 6,200 issues, so anything consuming the filter - dashboards, subscriptions, JQL, the other board's sprint builder - still sees everything. That is why ALPHA's backlog is unfiltered. Second, BETA has no exclusion at all, so it can pull Alpha issues into its sprints, and one issue can sit in an ALPHA sprint and a BETA sprint simultaneously.

Fix:

• ALPHA filter: project = PLAT AND component = Alpha ORDER BY Rank
• BETA filter: project = PLAT AND (component != Alpha OR component IS EMPTY) ORDER BY Rank
• The IS EMPTY branch is essential: JQL != never matches empty values, so all 400 component-less issues would vanish from both boards.

Better long-term: scope on a single-select 'Team' field with a default value and a create-time validator, rather than components. Components allow multiple values per issue, so an issue tagged Alpha and Beta appears on both boards, and a select field cannot do that. If you keep components, add a validator enforcing exactly one.

Keep the sub-filter only if you deliberately want a shared filter for a combined dashboard, and document that it hides issues from the board but not from the filter.

Moving between scopes: reassigning an issue's component moves it off the old board but leaves it in the active sprint, which distorts that sprint's burndown. Remove it from the sprint first.

Order matters - each cause masks the next.

1. Estimation statistic. Board settings → Estimation. If it is Story Points but the Story Points field is not editable on the screens/field configuration for PLAT, nothing is estimated and the chart degrades to issue count. If it is Original Estimate and nobody logs work, the chart is noise. Set the statistic and make the field editable.
2. Sprint dates. A sprint without start and end dates produces a meaningless chart; velocity needs completed sprints, so a board that has never closed a sprint reports 0 by definition.
3. 'Done' recognition. Work burns down only when the issue's status maps to the rightmost column and that column is the Done column. With 7 statuses and 5 columns, a Closed status that is unmapped or mapped to a middle column means nothing ever completes - which also explains issues reappearing in the backlog the next morning.
4. Unmapped statuses. Any status with no column is invisible on the board but still belongs to the sprint, so counts never reconcile and issues appear to vanish on transition.
5. Scope change. Issues added after sprint start show as scope increase and can flatten the line even when work is completing.

Column rule: one column per distinct workflow meaning, and every status mapped exactly once - a board with an unmapped status is a configuration bug, not a style choice. Do not model Blocked as a column; use a flag or a separate field, because a column implies a position in the flow.

Finally: Cloud reports regenerate on a schedule, so verify a fix on the next day's chart, not thirty seconds later.

• Permissions, not configuration, is the usual cause. A gadget renders blank or with a padlock when the viewing user cannot see the filter or a project in its JQL, even if they can see the dashboard. Filters and dashboards have independent sharing; share the filter to the same group or project role as the dashboard.
• Ownership. A filter is owned by one person. If the owner leaves or loses access, every gadget and both boards break. Prefer a shared service account as owner and audit every filter referenced by a gadget or a board.
• Public sharing. 'Anyone on the internet' on the VANT-style filter is both a data-leak and an unreliable integration path - share with a named group instead, and never leave a public filter pointing at a restricted project.
• Gadget-by-gadget check. Some gadgets on that dashboard may point at the old project = PLAT filter while others already use the new board filters; a mixed dashboard looks like a permissions bug for exactly one audience.
• Add to your release routine: open the dashboard as a member of each audience role. Site admins see everything, so admin-view testing will never surface this class of fault.