Platform
Targets the team set, measured honestly.
A target imposed from above gets gamed. A target a team agreed in a retro gets met, or gets changed in the next retro — both of which are useful. Working agreements let each team define its own thresholds, and Pacia reports the compliance rate with every miss listed so a retro has evidence rather than impressions.
- Review starts within 4 hours
- 78% of merged PRs
- PR under 400 lines changed
- 91%
- Required checks passing at merge
- 99%
- Correctly classified
- 84%
- Misses this sprint
- 12, all listed
What you can set and see
Per-stage time thresholds
An hour threshold on any cycle-time stage — most commonly "reviews should start within four hours" — with the hit rate colour-coded on the DORA page.
Pull request size limits
A size agreement with a drill-down into the pull requests that exceeded it. Large PRs are the most common root cause of slow review.
Required checks
Whether the checks the team agreed on were actually passing at merge, with the failures listed.
Classification agreements
Whether work is being labelled consistently enough for the investment and QA views to mean anything.
Compliance drill-downs
Every agreement has its own explore page listing the specific pull requests that missed. A compliance figure you cannot open is a figure nobody trusts.
Per-team configuration
Set in team settings by an admin or owner. A platform team and a customer-facing product team have genuinely different reasonable thresholds.
A target stays useful when the team can change it
Set the threshold together, measure it, open the misses, then decide in retro whether the process or the target should change.
A working agreement stays owned by the team
- 1Team agreesA useful threshold in retro
- 2Pacia measuresHit rate over real pull requests
- 3Misses openEvery exception listed with context
- 4Retro decidesChange the process or change the target
The loop matters more than the percentage. A target imposed once becomes a quota; a target reviewed against named work remains a working agreement.
Why this is the view teams actually adopt
The team owns the number
Agreements are configured per team rather than organisation-wide, and the intent is that the team chooses them. That is what separates an agreement from a quota.
Misses are listed, not just counted
Every compliance figure drills to the specific pull requests behind it. A retro discussion about twelve named PRs is productive; one about a percentage is not.
It reports on the team, never on a person
Compliance is a team measure. There is no per-developer compliance view, and there is no setting that produces one.
It shows up where the work is
Compliance rates render on the DORA page alongside the metrics they explain, rather than in a separate area nobody visits.
Common questions
What if a team keeps missing its own target?
Then either the process needs to change or the number does, and the compliance drill-down usually makes clear which. A target that is missed 70% of the time is information about the target, not only about the team.
Who can change an agreement?
Admins and owners, in that team’s settings. The expectation is that the change follows a team decision rather than replacing one.
Do agreements need Jira?
No. The time, size and check agreements all work from pull request data alone.