Thank you all for the detailed responses. Let me share a synthesized framework based on these practices that addresses the three key challenges: capturing approvals, reporting for audits, and balancing Scrum with formal reviews.
1. Capturing Approvals in Workflows and Fields
The most effective approach combines workflow states with structured custom fields:
Workflow Design:
Implement a three-stage workflow for requirements:
-
Draft: POs refine freely. No approval needed. Supports iterative refinement and backlog grooming without compliance overhead. This is where the Scrum flexibility lives.
-
Review: Requirement is complete and ready for approval. Triggers notification to compliance/approval team. Automated checks validate that required fields are populated (acceptance criteria, business justification, priority). Requirements stay in Review until approved.
-
Approved: Formal approval granted. Requirement is locked for major changes (description, acceptance criteria). Only Approved requirements can be pulled into sprints. This enforces the compliance gate.
Custom Fields for Audit Trail:
Add these fields to requirement issue types:
- Approval Status (Single Select): Pending, Approved, Rejected, Re-Approval Required
- Approved By (User Picker): Automatically populated during workflow transition
- Approval Date (Date): Automatically populated during workflow transition
- Approval Comments (Text Area): Approver’s notes or conditions
- Change Classification (Single Select): New Requirement, Major Change, Minor Change, Clarification
- Change Justification (Text Area): Required for Major Changes, explains why the change is necessary
- Last Substantive Change Date (Date): Updated via automation when key fields change
- Approval Version (Number): Increments each time requirement goes through re-approval
These fields provide structured data that’s easy to query and export for audits, while Jira’s native history provides the detailed change log.
Workflow Transition Logic:
Draft → Review transition:
- Validator: Acceptance Criteria field must not be empty
- Validator: Business Justification must not be empty
- Post Function: Set “Approval Status” to “Pending”
- Post Function: Send notification to approval group
Review → Approved transition:
- Condition: User must be in “Requirement Approvers” group
- Validator: “Approval Comments” must be populated
- Post Function: Set “Approval Status” to “Approved”
- Post Function: Set “Approved By” to current user
- Post Function: Set “Approval Date” to current date
- Post Function: Increment “Approval Version”
- Post Function: Create comment: “Requirement approved by [user] on [date]. Version [number].”
2. Reporting on Requirement Changes for Audits
Auditors need three types of reports:
A. Approval Status Report
JQL: `project = PROJ AND type = Requirement AND “Approval Status” = Approved AND “Approval Date” >= startOfMonth(-3) ORDER BY “Approval Date” DESC
Export fields: Key, Summary, Approval Date, Approved By, Approval Version, Change Classification
This shows all requirements approved in the audit period with approval metadata.
B. Change History Report
For each requirement, export Jira’s issue history filtered to show changes to critical fields:
- Description
- Acceptance Criteria
- Priority
- Status
Use the REST API or Jira’s native export with history. Script example for API approach:
GET /rest/api/2/issue/{issueKey}/changelog
Filter by: field in [description, acceptance_criteria, priority, status]
Group by: approval version
This provides the detailed “what changed” audit trail.
C. Compliance Exception Report
JQL: `project = PROJ AND type = Requirement AND status = Approved AND (“Approved By” is EMPTY OR “Approval Date” is EMPTY OR “Change Justification” is EMPTY)
This identifies requirements that bypassed proper approval process - your audit risk areas.
Dashboard for Continuous Monitoring:
Create a compliance dashboard with these gadgets:
- Pie chart: Requirements by Approval Status
- Filter results: Requirements pending approval > 3 days (SLA breach)
- Created vs Resolved: Requirement approval velocity trend
- Two-dimensional filter: Change Classification vs Status
3. Balancing Scrum with Formal Review Processes
The key tension is between Scrum’s embrace of change and compliance’s need for control. Here’s how to balance:
Principle 1: Gate at the Right Point
Don’t require approval for backlog items that aren’t ready for development. The Draft status gives POs and teams full flexibility for refinement. The approval gate only activates when a requirement is ready to be pulled into a sprint. This respects Scrum’s iterative nature while ensuring that committed work is properly reviewed.
Principle 2: Classify Changes by Impact
Not all changes are equal. Thomas’s approach of Major vs Minor classification is critical:
Major Changes (require re-approval):
- Changes to acceptance criteria that alter what “done” means
- Scope changes that affect effort estimates
- Priority changes for already-approved requirements
- Technical approach changes that affect architecture
Minor Changes (no re-approval needed):
- Clarifications that don’t change intent
- Formatting improvements
- Adding examples or additional context
- Correcting typos or grammar
Document these criteria clearly and train the team. When a Major Change is made to an Approved requirement, an automation rule moves it back to Review status and creates a Change Request issue (Rachel’s pattern). This triggers re-approval without losing the history.
Principle 3: Fast-Track Approvals
Daniel’s 24-hour SLA is essential. Compliance gates that take weeks kill agility. Implement:
- Daily approval review sessions (15 minutes)
- Batch notifications (daily digest, not per-issue)
- Clear approval criteria (not subjective judgment)
- Escalation path for urgent requirements
If your approval process is fast and predictable, teams adapt and it becomes part of their rhythm rather than a bottleneck.
Principle 4: Automate Audit Artifacts
Don’t make the team manually prepare audit reports. Use automation:
- Scheduled exports of approval data (weekly CSV to compliance folder)
- Automated dashboard updates (compliance dashboard refreshes nightly)
- Automated audit exception alerts (email when requirements bypass approval)
The team focuses on building software; automation focuses on compliance evidence.
Practical Implementation
Here’s a phased rollout:
Phase 1: Workflow and Fields (Week 1-2)
- Implement the three-stage workflow (Draft/Review/Approved)
- Add custom fields for approval tracking
- Configure workflow transitions with validators and post-functions
- Create the “Requirement Approvers” group and assign appropriate users
Phase 2: Automation (Week 3)
- Build automation rule: When Approved requirement’s Description or Acceptance Criteria changes, move to Review and set “Change Classification” to “Major Change”
- Build automation rule: Daily digest of pending approvals to approver group
- Build automation rule: Alert when requirement is in Review > 3 days
Phase 3: Reporting (Week 4)
- Create the three audit JQL queries and save as filters
- Build compliance dashboard
- Set up scheduled exports (weekly CSV of approved requirements)
- Document the audit reporting process
Phase 4: Team Training (Week 5)
- Train POs on Draft vs Review workflow
- Train approvers on approval criteria and SLA
- Train developers on pulling only Approved requirements into sprints
- Document Major vs Minor change classification
Phase 5: Process Validation (Week 6+)
- Weekly review of compliance dashboard
- Monthly audit dry-run using your new reports
- Gather feedback and refine
Addressing Your Specific Challenges
You mentioned that POs want to refine continuously (healthy) but compliance needs records. The solution is the Draft status - POs can refine in Draft as much as they want with zero compliance overhead. Only when they’re ready to commit to development does the requirement enter the formal approval process. This gives POs their flexibility while giving compliance their control point.
For reconstructing change history, the combination of structured approval fields (who/when) and Jira’s native history (what changed) provides complete audit trails without manual effort. The key is querying this data systematically rather than trying to reconstruct it during audits.
For not disrupting velocity, the fast approval SLA and the classification of changes (only Major changes need re-approval) means most day-to-day refinement doesn’t trigger compliance processes. Teams get used to the rhythm: refine in Draft, get approval before sprint commitment, proceed with confidence.
This framework has worked well in regulated industries (finance, healthcare, aerospace) where we’ve implemented it. The key success factor is treating compliance as a quality gate, not a roadblock - it happens at the right time, with clear criteria, and with fast turnaround.