Roles: How Your Team Uses SGD
SGD adds a governance layer to your existing delivery process. It does not replace your roles or ceremonies — it gives each role better tools, better context, and better evidence.
Framework-agnostic
This page uses Scrum terminology because it is the most widely understood, but the same principles apply to Kanban, SAFe, the Spotify model, or any other delivery framework. See SGD & Your Delivery Framework for specific mappings.
Product Owner
The Product Owner is the primary owner of the capability model and the feature spec registry. SGD gives POs visibility into whether what was specified is what was built — and whether it is delivering value.
Key responsibilities in SGD:
- Own the capability model — Approve structural changes (new capabilities, merges, splits). The model reflects the business view of the product, and the PO is the voice of the business.
- Approve feature specs — Review and approve specs before they become governing documents. Once approved, the spec drives PR checks and AI context.
- Track coherence and ROI — Use the ROI dashboard to monitor whether governance is reducing rework, improving coherence, and accelerating delivery.
Key touchpoints:
| Touchpoint | Frequency | What the PO does |
|---|---|---|
| Capability model | Monthly review | Confirm model reflects current product direction |
| Feature spec registry | Per feature | Review and approve specs |
| ROI dashboard | Sprint review | Present coherence trends, rework reduction, time-to-first-PR |
| Coherence alerts | As needed | Investigate capabilities with declining scores |
Scrum Master
The Scrum Master monitors how the team adopts SGD and whether governance is helping or hindering delivery. SGD provides the metrics to make this visible.
Key responsibilities in SGD:
- Monitor adoption — Track how consistently the team references specs in PRs, how often governance checks pass on first submission, and whether AI context files are being maintained.
- Reduce governance overhead — If governance checks are failing too often or slowing delivery, work with the team to adjust rules, improve specs, or update design system constraints.
- Sprint-over-sprint improvement — Use the ROI dashboard to show trends: is rework going down? Is coherence going up? Are specs getting more useful?
Key touchpoints:
| Touchpoint | Frequency | What the SM does |
|---|---|---|
| ROI dashboard | Every sprint | Track adoption metrics and improvement trends |
| Governance check results | Daily standups | Surface recurring failures and friction points |
| Team retrospectives | Per sprint | Discuss governance overhead and adjust rules |
| Onboarding | New team members | Walk through SGD workflow and role-specific touchpoints |
Development Team
The development team interacts with SGD daily — through specs, PR checks, and AI context. Different roles within the team have different touchpoints.
Analysis-focused members (Business Analysts, Domain Experts)
BAs and domain experts are the primary authors of feature specs. They translate business requirements into structured specifications that developers and AI agents can act on.
What changes with SGD:
- Write feature specs using the structured format (business intent, acceptance criteria in Gherkin, edge cases). The spec becomes the governing document, not a throwaway Confluence page.
- Map Jira epics to capabilities — When new epics are created, link them to the right capability in the model. This drives traceability.
- Review AI-generated code — When AI agents produce code, BAs can verify that acceptance criteria are met by reading the governance check results, without needing to read the code itself.
Key touchpoints:
| Touchpoint | What they do |
|---|---|
| Feature spec registry | Author and maintain specs |
| Capability model | Map new work to capabilities |
| ALM integration (Jira / ADO) | Link tickets to specs |
| Governance check results | Verify acceptance criteria are addressed in PRs |
Engineering-focused members (Developers, Architects)
Developers and architects interact with SGD through code — reading specs for context, using AI tools with SGD-generated context, and resolving governance check feedback on PRs.
What changes with SGD:
- Read specs before coding — The feature spec is the source of truth. It contains the API contract, data model, edge cases, and testing strategy. AI tools receive this context automatically.
- Use CLAUDE.md and MCP context — When working in a governed repo, AI coding tools receive capability context, active specs, ADRs, and design constraints automatically. The developer does not need to manually brief the AI.
- Respond to PR governance checks — Governance checks appear as GitHub status checks. Green means the PR aligns with the spec and design system. Red means something needs attention — the check explains what.
- Maintain the DAG — The Dependency Acyclic Graph tracks which repos depend on which. Developers update it when dependencies change, and the platform uses it for impact analysis.
Key touchpoints:
| Touchpoint | What they do |
|---|---|
| PR checks | Resolve governance feedback on pull requests |
| CLAUDE.md | AI context file — maintained by platform, read by AI tools |
| MCP server | Live context API for AI tools (specs, ADRs, coherence) |
| DAG manifest | Declare and update inter-repo dependencies |
| Design system | Follow naming, structure, and dependency rules |
Quality-focused members (Testers, QA Engineers)
QA benefits from a fundamental shift: the Gherkin acceptance criteria in the feature spec are the test specification. There is no separate test plan to write and keep in sync — the spec is the plan.
What changes with SGD:
- Gherkin criteria are the test spec — Acceptance criteria are written in Given/When/Then format directly in the feature spec. These are not aspirational — they are what the governance checks verify.
- Auto-generated test skeletons — The platform can generate test file scaffolds from the Gherkin criteria, giving QA a head start on test implementation.
- Production feedback loop — When deployed features fail or generate incidents, the platform links back to the spec and identifies which acceptance criteria may need tightening. This closes the loop between testing and production reality.
Key touchpoints:
| Touchpoint | What they do |
|---|---|
| Acceptance criteria | Source of truth for test cases — authored in specs |
| Test generation | Use platform-generated test skeletons as starting points |
| Governance check results | Verify that PR checks validated the right criteria |
| Production feedback | Review incident-to-spec links and update criteria |
How Roles Interact Through SGD
The delivery flow through SGD touches each role at specific points:
The key insight is that SGD does not add new ceremonies or meetings. It adds automated checkpoints within the workflow your team already follows. The governance check is the new artefact — everything else is existing work done slightly more deliberately.
What's next?
- See how governance checks work in practice See PR Checks
- Understand the full governance model See The Six Governance Layers
- Map SGD to your specific framework See SGD & Your Delivery Framework