Path B: Start from Jira / ADO / GitHub Issues
If your organisation's work starts in an issue tracker rather than in code, this path builds your capability model from the business structure you already have — then enriches it with repository data.
Why start from Jira? Business Analysts and Product Owners already maintain a structured view of your work in Jira or ADO. Projects, epics, and components often map directly to business capabilities. Starting here means the people closest to the business domain shape the model, and traceability is richer from day one because every capability links back to the tickets that drove it.
Step 1: Connect Your ALM Tool
Navigate to Settings > Integrations and connect your application lifecycle management tool.
| Tool | Connection method | What gets imported |
|---|---|---|
| Jira Cloud | OAuth 2.0 | Projects, epics, components, issue types, labels |
| Jira Data Center | OAuth 1.0a + API token | Projects, epics, components, issue types, labels |
| Azure DevOps | OAuth 2.0 | Projects, area paths, work item types, tags |
| GitHub Issues | Already connected | Repositories, labels, milestones, projects (v2) |
GitHub Issues — no extra setup
If you already connected the SGD GitHub App via Path A, GitHub Issues data is available automatically. You can skip straight to Step 2.
The platform reads your ALM structure in read-only mode. No tickets are modified.
Step 2: Map Projects to Capabilities
Once connected, the platform analyses your ALM structure and suggests a capability mapping.
| ALM structure | Suggested capability | Repos matched | Confidence |
|---|---|---|---|
| Jira Project: PAY (Payment Platform) | Payments | 4 repos | High |
| Jira Project: AUTH (Authentication) | Authentication | 3 repos | High |
| Jira Project: ONBOARD (Client Onboarding) | Client Management | 3 repos | Medium |
| ADO Area Path: Platform / Infra | Infrastructure | 2 repos | Medium |
| Jira Project: MISC (Miscellaneous) | Uncategorised | 5 repos | Low |
How mapping works:
- The platform reads your project keys, component names, and epic titles
- It matches them against repository names, topics, and README content
- Each suggestion includes a confidence score — High means strong naming and dependency alignment, Low means the platform is guessing
You review the mapping, drag repos between capabilities, rename anything that does not fit, and confirm.
Step 3: Connect Repos to Enrich
The real power comes from combining both data sources. Your ALM tool provides the business structure; your GitHub repositories provide the technical structure. The platform merges them into a single, enriched capability model.
What enrichment adds:
- Traceability links — Jira epics are linked to the repos that implement them, so every future PR traces back to a business requirement
- Health context — A capability with 4 repos where 3 are healthy and 1 is drifting is more actionable than 4 disconnected health scores
- Coverage gaps — The platform identifies Jira projects with no repos mapped (business capabilities with no code) and repos with no Jira project (code with no business context)
Step 4: Review, Confirm, Go
The final review screen shows your merged capability model with both business and technical data:
- Each capability shows its ALM source (Jira project, ADO area path) and its repo count
- Repos show their health scores and detected tech stacks
- Unmapped items are highlighted for your attention
Click Confirm Capability Model and governance activates — the same result as Path A, but with richer traceability from the start.
Both paths converge
It does not matter which path you choose — Path A (repos first) or Path B (issues first). Both produce the same capability model with the same governance features. The difference is where the initial structure comes from and how much traceability you get on day one.
Why start from Jira?
Three reasons to prefer this path:
BAs and POs work in Jira — The people who understand the business domain best already maintain a structured view of capabilities in their issue tracker. Starting there means the model reflects business reality, not just code organisation.
Existing structure is a good proxy — Jira projects and ADO area paths are not perfect capability models, but they are a much better starting point than repository names. The platform uses them as a scaffold and refines from there.
Traceability is richer from day one — When the capability model is linked to both Jira projects and GitHub repos, every PR automatically traces back through the full chain: ticket → spec → PR → check → deployment. With Path A you can add this later; with Path B you get it immediately.
What's next?
- Started from GitHub instead? See Path A: Start from GitHub Repos
- Understand the capability model See Your First Capability Model
- Ready to write a feature spec? See Writing Your First Feature Spec