Guided setup

Guided setup picks a board, chooses the metrics and checks each rule against your last closed sprint before you save it. Five metrics read Jira alone; only the test pyramid needs a report source.

Start the tour

Without a team yet, choose Set up your first team. The first step, Choose your board, lists the Scrum boards you can see; name the team and choose Create team and start setup.

For an existing team, open the Team and admin tools menu (the gear in the dashboard header) and choose Start or resume setup. Progress is saved as you go; Finish later keeps it and Resume setup picks it up again.

The progress rail on the left shows the stages: Board and team, Choose metrics, Review rules, Report sources (only when the test pyramid is selected) and Dashboard. Stages you have already reviewed can be reopened from the rail.

On Choose your metrics, the list Select the metrics to review offers all six metrics. Review rules then walks through the selected Jira metrics one by one (“Metric 1 of 5”). Report sources is the test pyramid step.

The last stage, Review your setup, shows the latest available result of each selected metric with a Review … settings button. Open dashboard closes the tour.

Work categories step

The tour calls this step Sprint commitments. Its first question is How do you group your work? Tick one or two: Jira project, components, issue type or labels.

Each card shows what your team actually has: the board’s projects, and the labels, types and components of the last closed sprint with their counts. A card with nothing to offer says why. Skip: no categories keeps say/do without rows; with saved categories the button reads Skip: remove the saved categories.

Continue: pick categories opens Which … become rows? with the values. Jira projects and issue types the last sprint shows start ticked; labels and components start unticked, tick the ones that should be rows. With one pick you can rename a row if your team calls it something else.

With two picks, each row is a pair, such as Payments API · qa:automation, so an issue lands in at most one row; an issue that matches two rows stays unclassified. Tick Other to add a row per project (or per first pick) for issues with none of the ticked values of the second pick, such as Payments API · other. An Other row applies only when no other row matched.

The last closed sprint is checked on the right as you go: how many issues fall into your rows, a bar per row and the issues left outside. The line at the top always says what to do next.

Save and continue saves the rows and moves to the next rule once the check is in place. Write conditions yourself opens the condition editor for anything the choices cannot express.

Epic progress step

Which epics do you follow? One list with a search field, open from the start:

• On your board: open epics of the board’s projects.
• Other projects with issues on your board: epics of other projects that parent recent issues of the board’s projects, for scope shared with another team.
• Other epics you can see: appears while you type, searching every epic you can open by name or key.

Tick every epic your team works on; Show done adds finished epics. The dashboard tile counts the followed epics with saved progress as “in flight” and draws a bar for the first four.

Skip: no epics for now moves on without epics; when the team already follows epics the button reads Skip: stop following epics and turns them off. Continue: how to count opens the next question.

How do you count epic progress? One setting for all followed epics:

• What counts as done work? Issues (each issue counts once) or Story points (…) from the field your board estimates in; the issue count is shown too. Another numeric field sits under Another numeric field.
• Cancelled work leaves the scope: the resolutions that mean cancelled work.
• Count sub-tasks as separate work: when off, a story with sub-tasks counts once.

Save and check saves it on every followed epic, turns off epics you unticked, and reads each epic from Jira. Continue appears once every epic has been read. Epics are listed and read as you: what you cannot open is never shown or counted.

Defect leakage step

Which issues are defects? The issue types of the board’s projects, including types your Jira admins created (Production defect, Customer incident), with how many issues of each were created in the last 90 days (counted over the latest 100 when there are more). The same type name in several projects is one row.

Saved types start ticked; otherwise names that say bug, defect or incident are ticked and marked “suggested from the name, check it”. Sub-task types sit under Sub-task types.

Which bugs belong to a sprint? chooses between Bugs created during the sprint (recommended) and Only bugs added to the sprint. Continue: where bugs were found opens the next question.

How do you record where bugs were found? The team’s own environments, earliest first; the last one is leakage. Rename them the way the team does (Staging to Pre-prod), move them with ↑ and ↓, remove them or Add environment (up to six). Other teams keep their own list.

Recognise environments by fills in the conditions from what your latest bugs carry. The choices are Environment field or labels · recommended, Environment field, Labels env:* and Components. A choice replaces the saved conditions; Back to the saved environments undoes it.

A value goes to an environment only by a whole word or the environment’s own name: “prod-eu” is Production, while “Pre-prod” or “non-prod” stay Not classified unless an environment is called that.

Conditions shows and edits one environment’s conditions, with the values your latest bugs carry one click away. A line above shows how many of the latest bugs carry each kind of evidence.

The check on the right runs by itself on up to 100 latest bugs of the chosen types: how many have an environment, the leakage among them, a bar per environment and the first bugs no environment matched.

Save and continue saves the environments, then the team’s types, and turns collection on. Labels and components are read with their history; for the Environment field only the current value is read, and the dashboard marks that history as incomplete.

Reopened tasks step

The tour calls this step Reopened tasks; the dashboard section is called Reopen rate.

Does finished work come back? No, our workflow has no such status keeps the metric off; Skip Reopen and continue saves that and moves on, and it can be turned on later in Team settings.

Yes, we move it back to a status lists the statuses on your board under Statuses that mean work came back, column by column. Done statuses are left out: work that comes back leaves them. Statuses whose names say Reopened, Returned or Rework are ticked and marked “suggested from the name, check it”.

Which tasks count shows the issue types of the last closed sprint with how many it had; until you pick, every type except sub-tasks counts. Leave out moves made by Jira Automation · recommended is on by default.

The check on the right reads the status history of the last closed sprint’s issues (up to 100, as they are now) and counts each chosen issue once if it entered a chosen status during the sprint: “1 of 5 tasks came back (20%)”, with the issues that came back and how many times.

Save and continue saves the choices. No people are shown.

Requirement coverage step

Which finished work needs automated tests? The issue types your team finished in the last closed sprint, with counts (before a sprint closes, the standard issue types).

Which of them need tests? All of them, or only the ones marked with a label. Labels that say “no”, “not”, “skip” or “without” are not offered here; you can add your own label.

What should be excluded · optional leaves out work closed as Won’t Do or Duplicate, labelled for example no-automation (add your own label too), or in a project without tests; Done is not offered. Without saved settings the names that say dropped or “no tests” start ticked with “check it”. Continue: where your tests are opens the next question.

How do you track automated tests? Separate automation work linked to the story, A test sub-task inside the story, A label on the story itself, or We do not track tests in Jira, which keeps coverage off; the button then reads Skip coverage and continue.

For linked work and sub-tasks the step lists the issues linked to, or under, the stories finished in the last sprint. Tick the ones that are automation work and the step says the rule it worked out, for example “a story is covered when a linked issue from project AUTO is done”. It warns when that rule also matches something you left unticked.

The check on the right counts the last closed sprint exactly like the metric and names excluded work with the reason. Save and continue saves the settings. A saved rule the step cannot show stays as saved.

Test pyramid step

Where do your tests run? GitHub Actions, GitLab CI on gitlab.com, Both GitHub and GitLab, or Not now, which skips the pyramid; the other five metrics do not need it. With Not now the button reads Skip the pyramid and continue.

For GitHub, sign in once and tick the repositories the app can read. A repository missing from the list has to be added to the app on GitHub (Settings, Applications, Installed GitHub Apps, Configure; for an organization its Settings, GitHub Apps). GitLab uses its own sign-in and project choice under GitLab projects inside the step.

Read test reports saves the ticked repositories and reads the completed runs of the last 30 days on the default branch; the step updates by itself while it reads, and the button then reads Read test reports again.

On the right the step lists the latest report of each workflow with its test count, and how many runs still had their reports (GitHub deletes artifacts after the retention your workflow sets). When no run saved a JUnit report, it shows the upload step to add. Continue: sort your tests opens the next question.

What kind of tests are in each report? One row per report file with its test count; pick Unit, Integration, API, E2E or Leave out. A file, suite or folder named unit, integration, api or e2e starts with that layer and the note “Suggested from the name “…”. Check it.” Nothing else is picked for you, and a report without a pick stays Not sorted.

All tests in this repository are one kind gives the whole repository one layer. The step says the rule it wrote from your picks, for example “suites or folders named unit go to that layer, also in new report files”, and the pyramid on the right is counted from the same rule.

A saved rule stays as long as every shown report it sorts has that layer picked, so a folder or archive rule keeps sorting new files. Only a rule that disagrees with a pick is replaced, and the step says how many.

Older saved reports that keep totals only are counted separately until they are collected again. Save and continue saves the layer rules; unchanged picks keep the saved rules as they are.

Clear all rules

On any Jira rule step, Clear all rules asks “Clear all N rules now?”. Clear rules then removes the saved rules of every selected Jira metric at once; Cancel keeps them. Setup then starts again from the first rule, and each rule is checked again before you continue.

What clearing saves, per metric:

• Sprint commitments: no work categories.
• Epic progress: tracking is turned off for every tracked epic of the team.
• Defect leakage: defect tracking is turned off for the team. The team’s environments stay.
• Reopened tasks and Requirement coverage: empty, turned-off settings.

Clearing is a new settings version, not a deletion: closed sprints keep their numbers and their rules. Report sources and layer rules of the test pyramid are not changed.

A rule that could not be cleared, for example an epic you can no longer open or settings changed in another session, is listed with the reason; the other rules are still cleared.