The bar

What Baro measures, and what it measures against.

Baro reads your Jira and tells you, in plain English, how your team is really delivering and whether a slip is a one-off or a pattern. Every team starts with a bar: Baro's reference for a good team, judged against your own numbers. This page shows each target, where it starts, and how every call is made, so you know where to raise the bar.

See the signals Starting bar

Your barFirst refreshStarting bar

2 of 4 measured areas at or above your bar

Delivery: cycle time and planned vs delivered at bar, review time not measured yet. Quality and practices: rework, thin acceptance criteria and work-type concentration below bar; rubber-stamp reviews, PRs linked and component concentration not measured yet.

At barBelow barYour barNo data yetOpen the demo

The Your Bar card from the Overview tab, on a demo team.

Signals

What Baro catches that Jira doesn't show you.

Each one is a sentence Baro writes from your numbers. "Too long" and "too many" come from what your own team finishes, never from a number you set.

JIRA

Shows you this sprint.

Burndown, velocity and the sprint report: one sprint at a time, with thresholds you set yourself.

BARO

Tells you whether it keeps happening.

Signals no Jira report shows, each judged against your own history, with nothing to configure.

On LiveWhat needs attention right now

Aging work

Not in Jira

"Two tickets are older than 85% of what this team ever finishes."

JIRADays in column, with no sense of what's normal for your team.

BAROYour own 85% line, redrawn on every sync. Nothing to set.

Compared with: Tickets your team finished in the last 90 days
Speaks up when: An open ticket is older than 85% of them

Boomerang tickets

Not in Jira

"PLT-355 is on its third sprint. PLT-371 was reopened after being closed."

JIRANo report puts carried, reopened and closed-late tickets together.

BAROOne list, with the reason on every row.

Compared with: The ticket's own sprint history
Speaks up when: It is on its third sprint, or came back within a week of being closed in a sprint's last days

Last-day status rush

Not in Jira

"Four tickets moved to In Progress on day 12 of 14."

JIRATime in status, with no link to when the sprint ends.

BAROSpots work that only started as the sprint was closing.

Compared with: This sprint's calendar
Speaks up when: Most of a ticket's in-progress time falls in the sprint's final fifth

On SprintWill we hit the sprint?

Going quiet

Not in Jira

"In progress, not blocked, and no update in longer than usual for this team."

JIRAThe burndown looks fine, because nobody raised a flag.

BAROFinds the silent ticket, measured against how often your team usually touches one.

Compared with: How often this team usually updates a ticket
Speaks up when: No status change, comment or other edit in longer than usual, while in progress and not blocked

Scope change, by kind

Not in Jira

"8 points added mid-sprint: 3 interrupts (3 bugs), 5 pulled from backlog. Re-estimated: +3 up, −2 down."

JIRAThe sprint report lists added and removed.

BAROSplits interrupts from backlog pulls, and shows re-estimates.

Compared with: What the team committed at sprint start
Speaks up when: Work is added after the start. Created and pulled in within two days counts as an interrupt

Blocked-risk trend

Not in Jira

"Blocked time is trending up: 12% in Sprint 23, vs a trailing average of 8%."

JIRAA Flagged filter shows what's blocked today.

BAROBlocked time as a share of working time, sprint over sprint.

Compared with: The trailing average of your previous sprints
Speaks up when: The latest sprint's blocked share of in-progress time moves away from that average. Needs a Blocked status and two finished sprints

Overview and trendsDoes it keep happening?

Delivery pattern, and why

Not in Jira

"This sprint is behind, and it has happened before. 2 of your last 6 sprints came in under plan. Work added after the sprint started shows up in most of them."

JIRAOne report per sprint, read one at a time.

BAROSays whether it is a one-off, worth watching or keeps happening, and names the common thread.

Compared with: Your last six finished sprints
Speaks up when: Sprints come in under 90% of plan: two of the last six is worth watching, three or more keeps happening. A cause is named when it shows up in most of them

Rework-adjusted velocity

Not in Jira

"13% of Sprint 23's delivered points were re-doing previously done work."

JIRAThe velocity chart counts re-done points as new work.

BAROVelocity with rework netted out, in the same points.

Compared with: The points the sprint delivered
Speaks up when: Some of them went to work already called done

Board trust

Not in Jira

"26% of your finished tickets skipped the board's normal path, so timing numbers are partly trusted."

JIRAReports show numbers, never how far to trust them.

BAROA badge on every number your board weakens.

Compared with: Your board's own workflow
Speaks up when: Finished tickets closed without ever being In Progress, in a single hop, or without a status change. Timing cards are marked Trusted, Partly trusted or Low

How it decides

Every call compares your team with itself.

There is no setting for "too long" or "too many". Each signal is a written rule that compares this ticket or this sprint with something your own team has already done. Same data in, same sentence out.

Your history is the yardstick

"Too long" is measured against tickets your team finished. "Keeps happening" is measured against your last six sprints.

Your sprint is the clock

Time rules use a share of the sprint, not a day count. A one-week and a four-week sprint get the same rule.

Too little data, no call

Under 3 finished sprints, Baro says there is not enough history to tell yet, and how many sprints it still needs. It never fills the gap with a guess.

Written by rules

Refresh twice, get the same answer. Every brief has a "How we decide" note, and each signal card above shows its rule.

One rule, worked through

Aging work, on a demo team

1Read the last 90 days. 58 tickets finished. Each one is timed from the day it first moved to In Progress to the day it was done.
2Find the usual. Half finished within 3 days. 85% finished within 7. Seven days is this team's line.
3Check what's open. Nine tickets are in progress. Two have been there longer than 7 days, so the Live card names those two.
4Move with the team. The line is redrawn on every sync. Speed up and it comes in. A team on 3-week tickets gets a different line, from the same rule.

Aging work · demo team

Half of your tickets finish within 3 days, 85% within 7.

Finished in the last 90 days, by days from start to done

Open right now, by age

Two tickets are older than 85% of what this team ever finishes.

Starting bar

Where a new team starts on Team health.

Six targets, so Team health has something to say on the first refresh. They are Baro's reference for a good team, not an industry standard, and they are the six Baro measures from Jira alone: the three faders without data on the card above (review time, rubber-stamp reviews, PRs linked to a ticket) need a code host and stay dark until one is connected. Change any of them on the Bar tab, and Baro labels the bar as yours.

TargetWhat it measuresStarts atWhere it comes from

Cycle time

Flow

How long a ticket takes from start to done. Where blocked time, waiting and rework hide.

8 days

lower is better

Baro's judgment

Rework rate

Flow

Share of status changes that move a ticket backward, such as QA back to In Progress.

10%

lower is better

Baro's judgment

Planned vs delivered

Delivery

Points delivered against points committed at sprint start. This is predictability.

80%

higher is better

Common practice

Work-type concentration

Silos

The largest share of one kind of work, such as bug fixes, done by a small part of the team. Shown as a shape, never a name.

65%

lower is better

Baro's judgment

Component concentration

Silos

The largest share of one Jira component's tickets done by a small part of the team. Shown as a shape, never a name.

50%

lower is better

Baro's judgment

Thin acceptance criteria

Refinement

Stories far thinner than your own stories of a similar size. They bounce back from QA and carry over.

15%

lower is better

Baro's judgment

How a verdict is reached

Within 10% of a target counts as at bar. The band is editable too, from 1% to 50%. Presets move every target at once: the starting bar, your last three sprints, or a 10% stretch.

No target on purpose

Throughput and review queue depend on team size. A good number for three people is a bad one for nine, so Baro compares them only with your own earlier periods.

Honest by default

When Baro can't be sure, it says so.

Baro read 14 months of Jira on its own and detected your story points field, blocked convention and done statuses.

It says what it worked out. Nothing to map. Settings exists to override, never to unlock.

Cycle time 4.1dPartly trusted

It marks a rough number. The badge sits on every timing card your board history weakens.

Not enough history to tell yet. 1 of the 3 finished sprints needed.

It leaves a gap instead of guessing. Trends fill in as sprints finish.

Changes to the bar

19 Oct 2026: Targets brought in line with the product's starting bar: cycle time 5 to 8 days, planned vs delivered 85% to 80%, work-type concentration 60% to 65%, thin acceptance criteria 20% to 15%. Component concentration added at 50%. Going quiet now compares with how often the team usually updates a ticket, and the delivery pattern has a "worth watching" step at two of six.
11 Oct 2026: Page published with five starting targets.

See where your team stands against its own history.

We're letting teams in a few at a time. Scrum teams first. Kanban teams get flow metrics. Works with Jira Cloud; Jira Server and Data Center aren't supported yet.