Agile Delivery

Agile Delivery

How the CSU SG Dev Crew plans, tracks, and delivers work. This page defines the collaboration model between Business Analysts (BAs) and Developers, and how we use GitHub as the single source of truth for requirements and delivery tracking.

---

Purpose

Standardize how BAs and Developers collaborate using GitHub as the single source of truth for requirements, delivery tracking, and implementation.

The goals are to:

• Reduce requirement gaps and duplicated tracking
• Create traceability from customer request → implementation → deployment
• Keep the process lightweight and practical

---

Roles & Responsibilities

Business Analyst (BA)

Focus: WHAT the system should do and WHY the feature is needed.

• Gather customer requirements
• Create and maintain GitHub Issues
• Define business requirements and acceptance criteria
• Clarify functional behaviour with developers and stakeholders
• Prioritize with customer / project leads

CSA / Developer

Focus: HOW the system will be implemented.

• Technical design and implementation
• Break work into technical tasks where needed
• Estimation and effort sizing
• Code changes, testing, and pull requests
• Update implementation status on the board

---

GitHub Core Components

1. GitHub Issues

Every feature, bug, enhancement, or task is tracked as a GitHub Issue.

Recommended issue types:

• User Story — new functionality from a user perspective
• Bug — defect in existing functionality
• Enhancement — improvement to existing functionality

Templates for these live in .github/ISSUE_TEMPLATE/ and appear automatically when you click New Issue.

2. GitHub Project Board

Status	Description
Backlog	Item has not been started
Refinement / Ready	Needs further clarification before starting — finalize acceptance criteria, confirm dependencies
In Progress	Actively being worked on
In Review	PR raised, awaiting review / QA
Done	Completed and merged

3. Labels

Apply labels consistently so issues can be filtered and reported on.

Recommended labels:

• Area: frontend, backend, api
• Type: bug, enhancement
• Priority: high-priority

---

Best Practices

Keep Requirements Lightweight

Avoid long requirement documents. Each issue should have:

• Clear acceptance criteria
• Concrete examples
• Screenshots / mockups where useful
• Small, iterative stories

One Requirement = One Issue

Do not bundle multiple requirements into a single issue. Smaller, focused issues are easier to estimate, review, and ship.

Maintain a Single Source of Truth

Requirements and status updates stay inside GitHub.

Avoid:

• Separate Excel trackers
• Multiple disconnected task lists
• Requirement duplication across platforms

Additional supporting files (customer-facing deliverables, consolidation of data, etc.) belong in the shared SharePoint folder:

WS09 – Pro Code Agent (SharePoint)

---

Annex — Recommended User Story Issue Template

Title format

[User Story] <short, action-oriented summary>

Example: [User Story] Upload Accommodation Requests

Body

## Business Requirement
Describe the business need or problem statement.

## User Story
As a <user>,
I want to <action>,
So that <business outcome>.

## Acceptance Criteria
- [ ] User can upload CSV file
- [ ] Invalid rows are rejected
- [ ] Validation errors are shown clearly

## Notes / Screenshots
Attach supporting screenshots, links, or examples.

## Priority
High / Medium / Low

## Dependencies
List any dependencies if applicable.