Teams and initiatives

Reports answer "how much, on what, by whom". Classification covers the what; teams and initiatives cover the whom and the towards which goal. They're independent groupings (a team slices effort by people, an initiative slices it by outcome) and most organisations use both.

Teams

A team is a named group of people, defined in EngLedger under Settings → Teams. Teams here are deliberately separate from anything in Jira or GitHub: your reporting structure rarely matches your Jira project layout, and this keeps the two decoupled.

Membership is dated. Each membership has a from-date and an optional to-date, so when a person moves between teams, their past effort stays with the team they were on when the work happened, and new effort follows them to the new team. Effort entries record the team at the time of the work: moving someone never rewrites history.

Teams appear as filters across reports: capitalisation, confidence, cost and person breakdowns can all be narrowed to a team.

Initiatives

An initiative groups tickets toward an outcome (a replatform, a compliance programme, a major feature) regardless of which project, team or quarter the tickets belong to. Each initiative can carry a budget, a target date, and a status (active, completed or delivered).

How tickets join an initiative

• Manually: add tickets or whole epics as items. An epic item counts as the epic and its child tickets: effort on any child rolls up to the initiative without adding each child individually.
• By rule: each initiative has its own rule engine that links matching tickets automatically, described next.

Initiative rules

Initiative rules use the same condition fields and operators as classification rules: labels, components, issue type, summary, assignee, sprint and so on; the rules reference lists them all. A rule matches when all of its conditions match, and only active rules evaluate.

The semantics differ from classification in one important way: classification picks a single winner per ticket, while initiative rules are additive membership. Every active rule links every ticket it matches: there is no first-match-wins, and one ticket can be linked into several initiatives by several rules.

Rules re-evaluate automatically after every ticket sync, so an initiative keyed on a label or component stays current without manual upkeep. Rules only ever add links:

• A ticket already in the initiative (from any source) is skipped: a rule never duplicates or overrides a manual item.
• A rule stops matching a ticket? Existing links stay. Removing a linked ticket is a manual action.
• Editing a rule's conditions relinks from scratch: the items that rule created are removed and the new conditions are evaluated against all tickets. Manually added items are never touched.
• Deleting a rule removes the items it created; duplicating one copies its conditions so you can tweak a variant safely.

Each rule tracks how many tickets it has matched and when it last matched, and a preview shows the match count and sample ticket keys before you save, worth checking, because a too-broad rule quietly inflates an initiative's cost. Initiative rules only decide membership. They never change how work is classified.

Cost splits

A ticket item carries a cost split percentage, so work shared between initiatives doesn't double-count. An item defaults to 100%, and rule-created links always start at 100%: splits are a manual judgement, adjusted per item afterwards. The split applies to everything the item brings in: an epic item at 40% contributes 40% of the effort on the epic and all its children.

Splits for the same ticket should sum to 100 across initiatives. EngLedger warns when they don't, but doesn't block: the warning surfaces on the item so you can rebalance.

Budgets and burn

An initiative's budget can be money, hours or both. Budget tracking is all-time: date filters on reports scope cost analysis, not budget consumption, because a budget belongs to the initiative, not to a reporting period.

Consumption is spend against budget, with three statuses: on track below the warning threshold (80% by default, configurable per initiative), at risk at or above it, and over budget at 100% or more.

Burn rate is average cost and hours per week over a configurable window: rolling 4 weeks (the default), rolling 8 weeks, since the first effort entry, or since the initiative was created. With a target date set, the projected total is current cost plus the weekly burn carried through to the target date. That projection is a straight-line extrapolation of recent pace, not a delivery forecast: a hiring round or a scope change breaks it, and it says nothing about whether the remaining work fits the remaining budget.

AI spend follows the same grouping

Initiatives roll up AI spend the same way they roll up labour: the same ticket set, the same epic expansion, the same cost splits. An epic item at 40% contributes 40% of the AI spend attributed to its tickets, exactly as it does for effort cost, so an initiative's labour and AI numbers are directly comparable. How sessions get attributed to tickets in the first place is covered in AI spend attribution.

Initiatives in reports

The Initiatives Report prices each initiative from the effort on its linked tickets (total cost, the capitalised share, and completion based on how many linked tickets have reached a done status) alongside the budget and burn figures above.

Choosing between them

Ask what the report reader wants to know. "What is the platform team costing us?" is a team question. "What has the migration cost so far, and will it fit the budget?" is an initiative question. Effort feeding both comes from the same ledger (see the effort model) and the ledger overview shows where each view fits.