Administration · 6 min read
Project settings
Categories, services, currency, review cadence, the stale threshold, score weights and the two approval policies.
Who can change these
Settings require the Jira administer projects permission for the project. If you can see the Settings tab but saving is refused, that is the check doing its job.
Every setting is per project. Two registers on the same Jira site can use different categories, currencies and approval policy, and changing one does not touch the other.
Categories
One per line. These populate the category dropdown on the form and the by category breakdown on the dashboard. The defaults are Process, Technology, People, Supplier, Documentation, Automation, Compliance and Customer experience.
Renaming or removing a category does not migrate existing records. An improvement already filed under a category you delete keeps that value, and will appear in the dashboard breakdown under a category no longer offered on the form. Reassign affected records before you remove a category, or leave it in place.
Fewer categories is usually better. Eight that everyone understands beats twenty that get picked at random, because the breakdown is only useful if the classification is consistent.
Services
One per line, naming the services this project improves. Populates the service field on the form. Leave it empty if your team does not think in terms of a service catalogue — nothing else depends on it.
Currency
An ISO 4217 code — GBP, EUR,
USD. Used to format every money figure on records, the dashboard and
the export.
It is a display setting only. Changing it does not convert existing figures: a forecast entered as 50,000 stays 50,000 and simply renders with a different symbol. Agree the currency before people start entering benefit cases.
Review cadence (days)
The default number of days between benefit reviews, applied to new improvements. 90 days out of the box.
It is a default, not a rule. Anyone can override it on an individual record, and clearing the field there means no periodic review at all rather than a fallback to this value.
Stale after (days)
How long an open improvement can go without being updated before it is flagged stale in the attention digest and on the dashboard. 30 days by default.
Tune it to how often you actually meet. A team reviewing monthly will find 30 days produces a useful nudge; one reviewing quarterly will find everything permanently stale and quickly learn to ignore the banner — which defeats the point.
Scoring weights
Three numbers driving the composite score. The defaults are value 0.5, effort 0.3, risk 0.2.
| Weight | What it rewards |
|---|---|
| Value | Forecast benefit against cost estimate. Raise it if your register should chase the biggest returns. |
| Effort | Smaller t-shirt sizes score higher. Raise it if you want quick wins to rise. |
| Risk | Driven by the record's priority field — Critical scores full marks, Low scores none. Raise it if urgency should outweigh return. |
The weights are normalised by their total, so they need not sum to 1. Entering 5 / 3 / 2 gives identical scores to 0.5 / 0.3 / 0.2. Use whichever is easier to discuss. Full arithmetic in Prioritising.
Changing the weights re-scores the whole register immediately, since the composite score is computed on read rather than stored. Expect the order of your backlog to move.
Policy
Two checkboxes, both on by default, and both enforced from Approved onwards — so they also gate the moves to In progress, Implemented, Verified and Closed. A field cannot be supplied to clear the gate and then removed.
Require an owner before an improvement can be approved
Stops work being approved with nobody accountable for it. Leave it on unless you have a deliberate reason — unowned open improvements are the most common thing to go quietly stale.
Require a benefit case before an improvement can be approved
Requires either a forecast figure or a written narrative. Turn it off if your team records improvements that are genuinely about compliance or risk and where a monetary figure would be invented rather than estimated — though the narrative field exists precisely for that case, so consider leaving it on and writing the case in words.
Turning a policy on does not retrospectively block existing records. It is checked when a transition is attempted, so improvements already past Approved stay where they are. They will hit the gate on their next move.
Saving
Save settings applies everything at once. The change takes effect immediately for everyone using that project's register.
Setting up a new project
A sensible order for a first configuration:
- Agree the categories with the people who will use the register, before anyone raises anything. Retrofitting a taxonomy is tedious.
- Set the currency before the first benefit case is entered.
- Set the stale threshold to match your review rhythm — roughly the gap between meetings.
- Leave both policies on to start with. Turning a gate off later is easier than explaining a register full of unowned improvements with no benefit case.
- Leave the weights alone until you have thirty or so records and can see whether the ranking matches your instinct.