📝 Templates & Checklists

# PRD: [Feature Name] **Version**: 1.0 **Created**: [Date] **Author**: [Product Owner Name] **Status**: Draft | Review | Approved --- ## 1. Executive Summary [1-2 sentence overview of what this feature does and why it matters] ## 2. Objective **Problem Statement**: What problem are we solving? **Goal**: What measurable outcome are we trying to achieve? **Success Metrics**: - [ ] Metric 1: [description] - Target: [value] - [ ] Metric 2: [description] - Target: [value] ## 3. Background [Business context, why this is important now, related initiatives] ## 4. Business Benefits - **Benefit 1**: [description and expected impact] - **Benefit 2**: [description and expected impact] - **User Benefit**: [how this improves user experience] ## 5. Use Cases ### Use Case 1: [Primary Use Case Name] - **Actor**: [User role, e.g., HR Administrator] - **Precondition**: [Initial state before action] - **Trigger**: [What initiates this flow] - **Basic Flow**: 1. [Step 1] 2. [Step 2] 3. [Step 3] - **Postcondition**: [Expected outcome] - **Exception Flows**: - [What happens if X goes wrong] ### Use Case 2: [Secondary Use Case Name] [Same structure as above] ## 6. User Stories and Acceptance Criteria ### Story 1: [Story Title] **As a** [role], **I want** [capability], **so that** [benefit]. **Acceptance Criteria**: - [ ] **Given** [context], **when** [action], **then** [result] - [ ] **Given** [context], **when** [action], **then** [result] - [ ] **Given** [context], **when** [action], **then** [result] **Priority**: Must Have | Should Have | Nice to Have **Size**: S | M | L | XL ### Story 2: [Story Title] [Same structure as above] ## 7. Design References - Figma: [Link to designs] - Prototype: [Link to interactive prototype] - Design System Components: [List of components used] ## 8. Technical Considerations [Notes from Technical Lead on implementation approach, architecture impacts] ## 9. Dependencies - **Internal**: [Other features, modules, or teams this depends on] - **External**: [Third-party APIs, services, or integrations] - **Blockers**: [What must be completed before this can start] ## 10. Out of Scope [Explicitly list what is NOT included to prevent scope creep] - [Item 1] - [Item 2] ## 11. Open Questions | Question | Owner | Due Date | Resolution | |----------|-------|----------|------------| | [Question 1] | [Name] | [Date] | [Answer when resolved] | ## 12. Sign-off | Role | Name | Date | Signature | |------|------|------|-----------| | Functional Lead | | | | | Technical Lead | | | | | Product Owner | | | |

# Root Cause Analysis: [Bug Title] **Bug ID**: [GitHub Issue # from SEQ Bug Tracker] **Severity**: P0-PAYROLL | P0 | P1 **Date of Incident**: [Date] **Date of RCA**: [Date] **Facilitator**: [Tech Lead Name] **Attendees**: [List all attendees] --- ## 1. Incident Summary **What happened**: [Brief description of the bug and its impact] **Affected Clients**: [Client names or count] **Business Impact**: [Revenue impact, client escalation, SLA breach, etc.] ## 2. Timeline | Time | Event | |------|-------| | [Date/Time] | Code containing bug deployed to production | | [Date/Time] | First client report received | | [Date/Time] | Issue acknowledged by support | | [Date/Time] | Escalated to Tech Lead | | [Date/Time] | Developer assigned | | [Date/Time] | Root cause identified | | [Date/Time] | Fix deployed to staging | | [Date/Time] | Fix deployed to production | | [Date/Time] | Confirmed resolved | **Time to Detection**: [X hours from deploy to report] **Time to Resolution**: [X hours from report to fix deployed] ## 3. Root Cause Analysis (5 Whys) **1. Why did the bug occur?** → [Direct technical cause, e.g., "Null pointer exception when X was empty"] **2. Why was this code written this way?** → [e.g., "Edge case was not considered in requirements"] **3. Why wasn't it caught in development?** → [e.g., "No unit test for empty state"] **4. Why wasn't it caught in code review?** → [e.g., "Reviewer unfamiliar with this module"] **5. Why wasn't it caught in QA testing?** → [e.g., "Test case didn't cover this specific scenario"] **ROOT CAUSE**: [Summary of the fundamental issue] ## 4. Contributing Factors ### Technical Factors - [ ] Complex code / technical debt - [ ] Insufficient validation - [ ] Missing error handling - [ ] Legacy system limitations - Other: [describe] ### Process Factors - [ ] Rushed development (time pressure) - [ ] Inadequate requirements/acceptance criteria - [ ] Incomplete testing - [ ] Insufficient code review - Other: [describe] ### Human Factors - [ ] Knowledge gap - [ ] Communication breakdown - [ ] Fatigue / overwork - Other: [describe] ## 5. Corrective Actions ### Immediate (Completed) | Action | Owner | Status | |--------|-------|--------| | [What was done to fix this bug] | [Name] | ✅ Done | ### Short-term (This Sprint) | Action | Owner | Due Date | Status | |--------|-------|----------|--------| | [e.g., Add unit test for edge case] | [Name] | [Date] | ⏳ In Progress | | [e.g., Update acceptance criteria template] | [Name] | [Date] | ☐ Pending | ### Long-term (Next Quarter) | Action | Owner | Due Date | Status | |--------|-------|----------|--------| | [e.g., Refactor module to reduce complexity] | [Name] | [Date] | ☐ Pending | | [e.g., Add automated regression for this flow] | [Name] | [Date] | ☐ Pending | ## 6. Lessons Learned 1. [Key takeaway for the team] 2. [What we'll do differently] 3. [Knowledge to share broadly] ## 7. Follow-up Schedule - [ ] Review short-term actions: [Date] - [ ] Verify long-term actions completed: [Date] - [ ] Share learnings with broader team: [Date] --- **RCA Completed By**: [Name] **Reviewed By**: [Tech Lead Name]

# User Story: [Short Descriptive Title] **Story ID**: [GitHub Issue # from feature project] **Epic**: [Parent Epic Name] **Sprint**: [Target Sprint] **Points**: [Estimate] **Priority**: Must Have | Should Have | Nice to Have --- ## Story Statement **As a** [user role/persona], **I want** [capability/feature], **So that** [business value/benefit]. ## Description [Additional context, background, or clarification that helps the developer understand the story] ## Acceptance Criteria ### Scenario 1: [Happy Path] **Given** [initial context/state] **When** [action performed] **Then** [expected outcome] ### Scenario 2: [Validation/Error] **Given** [initial context/state] **When** [invalid action or edge case] **Then** [expected error handling] ### Scenario 3: [Edge Case] **Given** [unusual but valid context] **When** [action performed] **Then** [expected outcome] ## UI/UX Requirements - Design Link: [Figma URL] - States to implement: Default, Hover, Active, Disabled, Loading, Error, Empty - Responsive breakpoints: Desktop (1200px+), Tablet (768px), Mobile (375px) ## Technical Notes [Any technical considerations, API endpoints, data models, etc.] ## Dependencies - [ ] [Dependency 1 - e.g., API endpoint available] - [ ] [Dependency 2 - e.g., Design completed] ## Out of Scope - [Explicitly excluded items] ## Test Cases (for QA) 1. [ ] [Test case description] 2. [ ] [Test case description] 3. [ ] [Test case description] --- **Author**: [Name] **Reviewed By**: [Tech Lead/PO]

# Bug Report: [Short Descriptive Title] **Bug ID**: [GitHub Issue # from SEQ Bug Tracker] **Reported By**: [Support Engineer Name] **Reported Date**: [Date/Time] **Client(s) Affected**: [Client name(s)] --- ## Severity Classification - [ ] P0-PAYROLL - Time-critical payroll, cutoff < 12 hours - [ ] P1-PAYROLL - Payroll bug, cutoff 12-48 hours away - [ ] P0 - System down, data loss, security breach - [ ] P1 - Core feature broken, multiple clients - [ ] P2 - Feature degraded, workaround exists - [ ] P3 - Minor issue, cosmetic **Payroll Cutoff (if applicable)**: [Date/Time] ## Bug Description **What is happening**: [Clear description of the issue] **What should happen**: [Expected behavior] ## Steps to Reproduce 1. [Step 1] 2. [Step 2] 3. [Step 3] 4. [Observe: describe what goes wrong] ## Environment - **Environment**: Production | UAT | Staging - **Browser**: [Chrome 120, Safari 17, etc.] - **OS**: [Windows 11, macOS 14, iOS 17, etc.] - **User Role**: [Admin, Employee, Manager, etc.] - **Specific Client Config**: [Any relevant client settings] ## Evidence - Screenshot(s): [Attach or link] - Video: [Link if available] - Error message: [Exact text] - Console errors: [If available] ## Client Communication **Client Urgency Level**: Low | Medium | High | Critical **Client Workaround**: [Describe any temporary workaround] **Client Expecting Update By**: [Date/Time] ## Additional Context [Any other relevant information] --- **For Tech Lead (Classification)**: - Confirmed Severity: [P0-PAYROLL / P0 / P1 / P2 / P3] - Assigned To: [Developer Name] - Target Resolution: [Date/Time] --- **Resolution**: - Fix Description: [What was done to fix] - Deployed To Production: [Date/Time] - Verified By: [QA Engineer Name]

## Is This Story Ready for Sprint Planning? - [ ] PRD approved with objectives and use cases documented - [ ] User story follows standard format (As a... I want... So that...) - [ ] Acceptance criteria are specific and testable - [ ] UX/UI designs are complete and reviewed - [ ] Dependencies are identified and resolved (or plan in place) - [ ] Story is sized (≤ 8 points, split if larger) - [ ] Technical approach discussed with Tech Lead - [ ] No open blocking questions

## Is This Story Done? ### Code Quality - [ ] Code complete per acceptance criteria - [ ] Code follows team coding standards - [ ] Code reviewed and approved (≥1 reviewer) - [ ] No linting errors or warnings - [ ] No security vulnerabilities introduced ### Testing - [ ] Unit tests written and passing - [ ] Integration tests passing (if applicable) - [ ] QA tested and approved - [ ] Edge cases and error scenarios tested - [ ] Cross-browser testing complete (if UI) ### Documentation - [ ] Code comments for complex logic - [ ] API documentation updated (if applicable) - [ ] Release notes entry drafted ### Deployment - [ ] Deployed to staging environment - [ ] Smoke tested in staging - [ ] Feature flag configured (if applicable) - [ ] Ready for UAT regression

## 24 Hours Before Production Deployment ### Sign-offs - [ ] QA sign-off received and documented - [ ] Product Owner approval (for features) - [ ] Tech Lead approval ### Documentation - [ ] Release notes drafted and reviewed - [ ] Known issues documented - [ ] Client communication prepared (if needed) ### Technical Readiness - [ ] Database backup plan confirmed - [ ] Rollback plan prepared and reviewed - [ ] Rollback tested in staging - [ ] Monitoring dashboards ready - [ ] Alert thresholds configured ### Team Readiness - [ ] Team availability confirmed for deployment window - [ ] On-call engineer identified - [ ] Support team briefed on changes - [ ] Escalation contacts confirmed

## Immediately After Production Deployment (2-hour window) ### Smoke Testing (within 15 minutes) - [ ] Application loads without errors - [ ] Login functionality works - [ ] Core feature spot-checked - [ ] New feature verified (if applicable) ### Monitoring (2 hours) - [ ] Error logs reviewed - no new errors - [ ] Performance metrics stable - [ ] No spike in support tickets - [ ] API response times normal - [ ] Database performance normal ### Communication - [ ] Deployment confirmed in team channel - [ ] Release notes published - [ ] Stakeholders notified (if applicable) ### Documentation - [ ] Deployment logged in release history - [ ] Any issues noted for follow-up ### Escalation Triggers If any of these occur, escalate immediately: - [ ] Error rate > 1% increase - [ ] Response time > 50% slower - [ ] Critical feature not working - [ ] Client reports issue

## Code Review Checklist ### Functionality - [ ] Code does what the ticket describes - [ ] Edge cases are handled - [ ] Error handling is appropriate - [ ] No obvious bugs ### Code Quality - [ ] Code is readable and well-organized - [ ] Variable/function names are descriptive - [ ] No unnecessary complexity - [ ] No code duplication (DRY) - [ ] Functions are single-purpose ### Security - [ ] No hardcoded secrets or credentials - [ ] Input validation present - [ ] No SQL injection vulnerabilities - [ ] Authentication/authorization correct ### Testing - [ ] Unit tests added for new code - [ ] Tests are meaningful (not just coverage) - [ ] Existing tests still pass ### Performance - [ ] No N+1 query issues - [ ] No unnecessary database calls - [ ] Large data sets considered ### Domain-Specific (for payroll/billing) - [ ] Calculations verified - [ ] Domain expert review completed - [ ] Audit logging in place

## Production Rollback Procedure ### When to Rollback Rollback immediately if: - [ ] System completely down - [ ] Core feature broken for all users - [ ] Data corruption detected - [ ] Security breach identified Consider fix-forward instead if: - [ ] Single feature broken, workaround exists - [ ] Issue affects small subset of users - [ ] Fix is simple and quick (<30 min) --- ### Rollback Steps #### Step 1: Confirm Decision (5 min) - [ ] Tech Lead confirms rollback is necessary - [ ] Notify team in #incidents channel - [ ] Document current error/issue #### Step 2: Execute Rollback (10-15 min) ``` # Option A: Revert to previous Docker image kubectl rollout undo deployment/[app-name] -n production # Option B: Deploy specific previous version kubectl set image deployment/[app-name] app=[image:previous-tag] -n production # Option C: Git revert and redeploy git revert [commit-hash] git push origin production # Wait for CI/CD pipeline ``` #### Step 3: Database Rollback (if applicable) - [ ] Execute rollback migration script - [ ] Verify data integrity - [ ] Test affected queries #### Step 4: Verify Rollback (10 min) - [ ] Application loads correctly - [ ] Login works - [ ] Previously broken feature works - [ ] Error logs clear - [ ] Performance metrics normal #### Step 5: Post-Rollback - [ ] Update #incidents with confirmation - [ ] Notify affected clients - [ ] Begin investigation of root cause - [ ] Schedule RCA meeting --- ### Rollback Contacts | Role | Name | Phone | Slack | |------|------|-------|-------| | DevOps Lead | [Name] | [Number] | @handle | | Tech Lead | [Name] | [Number] | @handle | | DB Admin | [Name] | [Number] | @handle | --- ### Post-Rollback Investigation 1. Why did this happen? 2. Why wasn't it caught in testing? 3. What needs to change before redeploying? [Schedule RCA within 24-48 hours]

## Sprint [X] Planning - [Date] **Duration**: 2-4 hours **Attendees**: [List] ### 1. Review Sprint Goal (10 min) - What is our objective for this sprint? - What value are we delivering? ### 2. Capacity Check (10 min) | Team Member | Available Days | Notes (PTO, etc.) | |-------------|----------------|-------------------| | [Name] | [X] | | **Total Team Capacity**: [X] points ### 3. Backlog Review (1-2 hours) For each story: - [ ] PO presents story and acceptance criteria - [ ] Team discusses technical approach - [ ] Team estimates (planning poker) - [ ] Team commits or defers ### 4. Sprint Backlog (30 min) | Story | Points | Assignee | |-------|--------|----------| | | | | **Total Committed**: [X] points ### 5. Confirm Sprint Goal "By the end of this sprint, we will have..." ### 6. Action Items - [ ] [Action item from discussion]

## Sprint [X] Retrospective - [Date] **Duration**: 1 hour **Facilitator**: [Scrum Master] **Attendees**: [Team] --- ### What Went Well ✅ [List positives - celebrate wins] 1. 2. 3. ### What Needs Improvement ⚠️ [List pain points - no blame, just facts] 1. 2. 3. ### Action Items for Next Sprint 🎯 | Action | Owner | Due | |--------|-------|-----| | | | | | | | | ### Review Previous Action Items | Action | Status | Notes | |--------|--------|-------| | [From last retro] | ✅/⏳/❌ | | --- ### Team Happiness Score How are we feeling? (1-5): [Average: X] ### Notes [Any other discussion points]