Skip to main content

SDLC Lifecycle Golden Path

AI agents build governed. Humans ship trusted. Stories flow: CSV → JIRA → Confluence → sprint ceremonies → back to CSV.

At a Glance

Stories live in CSV (single source of truth). JIRA is a mirror for team tracking. Confluence is the stakeholder view. Three commands drive the entire cycle.

PhaseOwnerWhatCommand
Define StoriesManager writes, AI validatesAdd rows to stories.csv with INVEST quality gateManual edit
Push to JIRAproduct-owner agentCSV stories sync to JIRA SPM board/sync:jira-push
Sprint ExecutionTeam + ceremoniesDaily standups, sprint planning, DORA metrics/ceremony:standup
Pull from JIRAproduct-owner agentJIRA status changes sync back to CSV/sync:jira-pull
Publish to Confluencedocumentation agentStories become stakeholder-facing Confluence pages/documentation:confluence-publish

All sync commands default to preview mode. Add --execute to apply changes.


Overview

End-to-end flow from idea to sprint review with governed AI agents and 2-way Atlassian sync.


The Golden Prompt

"I want to [sync my stories to JIRA] to [ensure JIRA SPM matches CSV SSOT]. Read my folder. Ask me questions using AskUserQuestion before you start."

Customise the bracketed sections. The product-owner agent reads stories.csv, validates INVEST compliance, checks for existing rsid labels, and plans the sync before writing a single ticket.


Phase 1: Story Definition

Who: HITL writes. product-owner validates INVEST compliance.

What: INVEST stories in stories.csv with detail files in pm-stories/.

Why: CSV is the single source of truth. JIRA is a projection, not the owner.

What-if skip: Stories created directly in JIRA drift from CSV; CSV becomes stale; duplicate stories on re-import (anti-pattern: JIRA_DUPLICATE_IMPORT).

How

  1. Add a row to stories.csv with columns: id, title, persona, story, ac_ref, agent, sprint, points, status, kr_ref
  2. Create pm-stories/{prefix}/{id}.md with acceptance criteria, BDD scenarios (Given/When/Then), and tech notes
  3. Run INVEST gate: does a real persona request this? Is the outcome negotiable? Is it independent?

Quality Gate

  • id prefix matches component: CO-, FO-, TF-, AD-, XC-, SEC-, INV-, OPS-, CF-
  • AC reference present, KR mapping present, agent assigned
  • INVEST gate passed (not a task, chore, or tech-debt item — those go to TODO.md)

Phase 2: JIRA Sync (Push)

Who: product-owner agent executes. HITL reviews conflict report.

What: CSV rows pushed to JIRA SPM as Epics + Stories with ADF descriptions.

Why: JIRA is the team-visible board. CSV is the engineering SSOT. Both must agree.

What-if skip: Team sees stale JIRA, sprint planning uses wrong story set, CAB reviews incomplete.

How

/sync:jira-push --project SPM --execute

The command:

  1. Searches JIRA for rsid:{id} label before creating (idempotency guard)
  2. Converts pm-stories markdown to ADF using jira-adf-sync skill
  3. Sets component, label, epic link, story points, and sprint
  4. Reports created/updated/skipped counts with no artificial content truncation

Governance Gates

  • Coordination gate: Requires product-owner + cloud-architect approval before JIRA writes (prevents unauthorized changes)
  • Idempotency gate: Blocks sync unless rsid label guard is present (prevents duplicate ticket creation)
  • Evidence gate: Requires audit trail after sync completes (enables rollback if needed)

Quality Gate

  • rsid:{id} label on every ticket (idempotency key)
  • ADF description includes all ACs and BDD scenarios (no truncation)
  • jira_key + jira_url backfilled to CSV rows after sync

Phase 3: Sprint Execution

Who: observability-engineer runs ceremonies. Specialist agents execute stories.

What: Daily standups, sprint planning, sprint reviews, retrospectives with DORA metrics.

Why: Governed AI agents need ceremony data to measure delivery quality and improve.

What-if skip: No DORA baseline, no velocity data, no improvement signal for next sprint.

Commands

CeremonyCommandAgentCadence
Sprint Planning/ceremony:planproduct-ownerWeekly
Daily Standup/ceremony:standupobservability-engineerDaily
Sprint Review/ceremony:reviewobservability-engineerWeekly
Sprint Retro/ceremony:retroobservability-engineerWeekly
QBR/ceremony:qbrobservability-engineerQuarterly

DORA Metrics Tracked

MetricTargetMeasurement
Deployment FrequencyElite: ≥1/daygit log --since per sprint
Lead TimeElite: less than 1 dayStory creation → merge time
Change Failure RateElite: 0-5%Failed deploys / total deploys
MTTRElite: less than 1 hourIncident open → close time

Quality Gate

  • Standup evidence JSON written to framework/ceremonies/
  • DORA metrics updated in SQLite via collect-dora-session.sh
  • Retro action items assigned with owners and due dates

Phase 4: JIRA Sync (Pull)

Who: product-owner agent pulls. HITL resolves conflicts.

What: Status changes, comments, and resolution data pulled back from JIRA to CSV.

Why: Team may update JIRA directly during sprint execution. Pull keeps CSV current.

What-if skip: CSV status drifts from JIRA; sprint metrics computed from stale data.

How

/sync:jira-pull --project SPM --execute

The command:

  1. Fetches all stories via POST /rest/api/3/search/jql (not deprecated GET endpoint)
  2. Maps JIRA status → CSV status column
  3. Backfills jira_key and jira_url for any rows missing them
  4. Reports conflicts for HITL resolution (CSV-wins by default for content; JIRA-wins for status)

Quality Gate

  • stories.csv updated with current status after every sprint
  • No stories with in_progress status older than 2 sprints without HITL explanation
  • Conflict report reviewed by HITL before merge

Phase 5: Confluence Publishing

Who: technical-documentation-engineer publishes. HITL reviews page tree.

What: 53 SPM pages from pm-stories/ content, live JIRA macros, sprint velocity charts.

Why: Stakeholders need Confluence, not CSV. Confluence pages are the HITL-consumable artifact.

What-if skip: Documentation drifts from JIRA, stakeholders read stale pages, audit trail incomplete.

How

/documentation:confluence-publish --project SPM

The command:

  1. Searches by page title before creating (idempotency — anti-pattern: CONFLUENCE_DUPLICATE_PAGE prevented)
  2. Uses ?body-format=storage on all GET requests (body absent without this param)
  3. Embeds live JIRA macros for Sprint Velocity, Roadmap, and DORA
  4. Preserves hand-curated content sections (anti-pattern: HAND_CURATED_CONTENT_DESTRUCTION prevented)

Page Tree (SPM Space)

SPM Home
├── Product Vision & PR/FAQ
├── Sprint Plans
│ ├── Sprint N Plan
│ └── Sprint N Retro
├── Stories (by Epic)
│ ├── {prefix}: Epic Name
│ │ └── {id}: Story Title
└── Architecture Decisions (ADRs)

Quality Gate

  • 53 pages present in SPM space
  • No duplicate page titles
  • Live JIRA macros render (Sprint Velocity visible on Sprint Plan pages)
  • Hand-curated sections preserved across updates

Key Components

ComponentTypePurpose
stories.csvDataSingle source of truth for all user stories
pm-stories/DataDetailed acceptance criteria per story
/sync:jira-pushCommandCSV to JIRA sync (with duplicate prevention)
/sync:jira-pullCommandJIRA status back to CSV
/ceremony:standupCommandDaily standup with DORA metrics
/ceremony:planCommandSprint planning with capacity estimation
/ceremony:reviewCommandSprint review with completion evidence
/documentation:confluence-publishCommandStories to Confluence pages
product-ownerAgentStory validation and JIRA sync
observability-engineerAgentCeremonies and DORA metrics
atlassian-toolsMCP72 tools for JIRA + Confluence integration

What NOT to Do

MistakeImpactPrevention
Duplicate ticketsRun sync twice without idempotency guard → 134+ duplicatesAlways search for existing ticket by rsid label before creating
Uncontrolled sprint assignmentAgents move tickets without manager approval → unauthorized changesSprint assignment is manager-only; agents can only create or comment
Task storiesTech debt written as user stories → inflated backlog, missed KRsKeep stories in CSV only if a real persona would request it; use TODO.md for internal work

Last Updated: April 2026 | Status: Active | Maintenance: product-owner + technical-documentation-engineer