Scenario: a SaaS team on GitHub and Jira

The most common EngLedger setup: a product team writing code in GitHub and tracking work in Jira. This walkthrough follows a fictional 12-person SaaS company from empty account to a report they'd stand behind. Each step links to the detailed guide rather than repeating it.

The goal

Jira knows what the team worked on; GitHub knows what they built. Neither knows what it cost. Connecting both gives EngLedger tickets and logged time from one side, commits and pull requests from the other, and the links between them, enough to build an effort ledger with real attribution.

1. Connect Jira first. Follow the Jira guide and select the engineering projects, the ones tickets and worklogs live in. Company-wide Jira instances accumulate HR and marketing projects; leaving those unselected keeps noise out of the ledger from day one.

2. Connect GitHub. Follow the GitHub guide and install the app on the product organisation. Deselect forks, archived experiments and mirror repositories: anything whose commits shouldn't count as product engineering effort.

3. Add people and let identities link. Add the twelve team members with their work emails. Most Jira and GitHub identities link themselves by email match; the stragglers (usually Git author emails from personal laptops) get linked by hand on the Identities page. Ten minutes now saves arguing about missing hours later. See people and identities.

4. Pick the effort method. In Settings, choose how effort is measured. A team that logs time in Jira consistently should use worklogs, actual logged hours. A team that doesn't (most SaaS teams) should use commit sessions, which estimate coding time from commit patterns. Be honest about which team you are; the effort model explains what each method can and can't claim.

5. Let ticket references do the linking. Commits and PRs that mention a Jira key (ENG-123 in the branch name, commit message or PR title) link to their tickets automatically. If your team doesn't reference tickets consistently, this is the highest-value habit to adopt: every link connects code activity to classified, reportable work.

6. Set classification rules. Start from the defaults (stories capitalisable, bugs and tasks not) and refine with rules on labels, components or issue types (see classification rules).

7. Read the first reports. After the first sync settles, start with three: the Cost Report for spend by month, the Capitalisation Effort Split for the cap/exp ratio, and the Confidence Report to see how much of the ledger rests on real rules versus fallbacks. If confidence is low, tighten rules before trusting the split.

What "good" looks like

After a fortnight of syncing: identities all linked, most commits linked to tickets, classification confidence mostly high, and the dashboard showing cost per month that finance can reconcile. From there, teams typically add teams and initiatives for structure, or continue to the R&D capitalisation workflow if the ledger feeds their accounts.

EngLedger's full integration list is on the integrations page.