GitHub Projects Workflow Patterns

This skill provides proven workflow patterns for different team types and development methodologies using GitHub Projects V2.

Agile Scrum Workflow

Project Structure

Fields:

• Status: Backlog → Todo → In Progress → In Review → Done
• Priority: P0, P1, P2, P3
• Story Points: 1, 2, 3, 5, 8, 13
• Sprint: 2-week iterations
• Assignee: Team member

Views:

1. Sprint Board: Board view grouped by Status, filtered to current sprint
2. Sprint Backlog: Table view showing all current sprint items sorted by priority
3. Product Backlog: Table view of all Backlog items sorted by priority
4. Sprint Velocity: Custom view tracking completed points

Workflow Steps

1. Backlog Refinement (Weekly):

   • Review new items in Backlog
   • Assign Priority based on business value
   • Estimate Story Points for upcoming items
   • Add acceptance criteria in item body
   • Move refined items to top of Backlog

2. Sprint Planning (Every 2 weeks):

   • Review team velocity from last sprint
   • Select top-priority items from Backlog
   • Assign to current Sprint iteration
   • Move items from Backlog to Todo
   • Ensure total points ≤ team capacity

3. Daily Standup (Daily):

   • Review Sprint Board
   • Items "In Progress" are discussed
   • Blockers identified and marked P0/P1
   • Items "In Review" get review assignments

4. Development:

   • Pull item from Todo to In Progress
   • Self-assign the item
   • Create feature branch
   • Implement and test
   • Create PR linked to issue
   • Auto-move to In Review (via automation)

5. Code Review:

   • Team reviews items In Review
   • Approve or request changes
   • When PR merges → Auto-move to Done

6. Sprint Review (End of sprint):

   • Review all Done items
   • Demo completed features
   • Archive Done items
   • Celebrate wins

7. Sprint Retrospective (End of sprint):

   • Review sprint metrics
   • Discuss what went well/poorly
   • Create action items for improvements

Success Metrics

• Velocity: Average points completed per sprint
• Predictability: % variance from planned vs actual
• Cycle Time: Average time from Todo → Done
• Work in Progress: Should stay ≤ team size
• Sprint Completion: Aim for >80% of committed work

Kanban Continuous Flow

Project Structure

Fields:

• Status: Ready → In Progress → Review → Done
• Priority: Critical, High, Normal, Low
• Size: S, M, L, XL
• Type: Bug, Feature, Chore, Tech Debt
• SLA Days: Number (days until due)

Views:

1. Flow Board: Board grouped by Status with WIP limits
2. Blocked Items: Table filtered to items with "blocked" label
3. Priority Lane: Board grouped by Priority
4. Aging Report: Table sorted by days in status

Workflow Steps

1. Item Entry:

   • New items start in Ready
   • Assign Priority immediately
   • Assign Size estimate
   • Set Type category
   • Calculate SLA based on Priority

2. Pull System:

   • Team members pull from Ready when capacity available
   • WIP limits enforced per person (typically 2-3 items)
   • Highest priority items pulled first
   • Self-assign when pulling to In Progress

3. Work In Progress:

   • Focus on finishing items before starting new ones
   • Update item if blockers occur
   • Seek help if stuck >2 days

4. Review:

   • Items move to Review when PR opens
   • Automated PR → Review status transition
   • Reviews prioritized by age (oldest first)

5. Completion:

   • Merged PR auto-moves to Done
   • Done items archived after 7 days
   • Metrics tracked continuously

6. WIP Limit Management:

   • In Progress limit: [team size × 2]
   • Review limit: 5 items maximum
   • If limits exceeded, stop pulling new work

Success Metrics

• Throughput: Items completed per week
• Lead Time: Time from Ready → Done
• WIP: Average items in progress (lower is better)
• Flow Efficiency: Value-add time / total time
• Blocked Rate: % of time items are blocked

Bug Triage Workflow

Project Structure

Fields:

• Status: New → Triaged → In Progress → Fixed → Verified → Closed
• Severity: Critical, High, Medium, Low
• Component: Frontend, Backend, API, Database, Infrastructure
• Affected Users: Number
• Reported Date: Date
• Fix Version: Text

Views:

1. Triage Queue: Board showing New bugs by Severity
2. Active Bugs: Table of In Progress/Fixed bugs sorted by Severity
3. Component View: Board grouped by Component
4. Verification Queue: Table of Fixed bugs awaiting verification

Workflow Steps

1. Bug Reported:

   • User/QA creates issue with bug template
   • Auto-add to project with New status
   • Triage team notified

2. Triage (Daily):

   • Review all New bugs
   • Assign Severity based on impact:
     • Critical: Production down, data loss, security
     • High: Major feature broken, >100 users affected
     • Medium: Feature degraded, workaround exists
     • Low: Minor issue, cosmetic problem
   • Assign Component
   • Estimate Affected Users
   • Move to Triaged status
   • Assign to component owner if Critical/High

3. Development:

   • Developer pulls bug from Triaged
   • Move to In Progress
   • Investigate and fix
   • Create PR with "Fixes #[issue]" in description
   • Move to Fixed when PR merges

4. Verification:

   • QA/Reporter tests fix
   • If verified: Move to Verified, close issue
   • If not fixed: Move back to In Progress with notes

5. Closed:

   • Verified items move to Closed
   • Archive after 30 days
   • Track in Fix Version for release notes

Success Metrics

• Triage Time: Time from New → Triaged (target: <1 day)
• Time to Fix: Time from Triaged → Fixed by severity
• Bug Escape Rate: Bugs found in production vs QA
• Reopen Rate: % of bugs reopened after fix
• Critical SLA: 100% of Critical bugs fixed within SLA

Feature Development Roadmap

Project Structure

Fields:

• Status: Idea → Spec → Development → Beta → Launched → Retired
• Priority: Must Have, Should Have, Nice to Have
• Quarter: Q1 2025, Q2 2025, Q3 2025, Q4 2025
• Effort: 1 week, 2 weeks, 1 month, 3 months, 6 months
• Customer Impact: Number (customers requesting)
• Owner: Text (PM name)
• Launch Date: Date

Views:

1. Roadmap Timeline: Roadmap view by Launch Date
2. This Quarter: Table filtered to current quarter sorted by Priority
3. Ideas Board: Board of Idea status items grouped by Priority
4. Feature Status: Board grouped by Status

Workflow Steps

1. Idea Collection:

   • Create draft items in project
   • Status: Idea
   • Rough priority assignment
   • Track Customer Impact

2. Quarterly Planning:

   • Review all Ideas
   • Assign Priority: Must/Should/Nice to Have
   • Assign Quarter
   • Assign Owner (PM)
   • Top ideas move to Spec status

3. Specification:

   • Owner writes detailed spec
   • Define success metrics
   • Estimate Effort
   • Get stakeholder approval
   • Move to Development when eng committed

4. Development:

   • Link to engineering project/sprint
   • Track progress via linked issues
   • Status updates in weekly sync
   • Move to Beta when ready for testing

5. Beta Testing:

   • Limited rollout
   • Gather feedback
   • Fix critical issues
   • Refine based on learnings
   • Move to Launched when GA

6. Launch:

   • Full rollout
   • Marketing announcement
   • Track adoption metrics
   • Monitor for issues
   • Eventually move to Retired when deprecated

Success Metrics

• Delivery Accuracy: % of features launched on time
• Customer Satisfaction: NPS or CSAT per feature
• Adoption Rate: % of users using new feature
• Spec → Launch: Average time from commit to ship
• Roadmap Predictability: % of quarterly commitments met

Common Automation Patterns

Status Automation

When PR opens → Move item to "In Review"
When PR merges → Move item to "Done"
When issue closed → Move item to "Done"
When item added → Set default Status to "Backlog"

Priority Automation

When "critical" label added → Set Priority to P0
When "bug" label added → Set Priority to P1
When "enhancement" label added → Set Priority to P2

Archival Automation

When item in "Done" for 30 days → Archive
When item closed and verified → Archive after 7 days

Notification Automation

When P0 item added → Notify team on Slack
When item stuck in "In Review" >3 days → Notify assignee
When sprint ends → Generate velocity report

Best Practices Across All Workflows

1. Single Source of Truth: Use project as primary view, not issue lists
2. Consistent Field Usage: Standardize field names/values across projects
3. Regular Refinement: Weekly grooming prevents backlog chaos
4. Clear Definitions: Document what each status/priority means
5. Limit WIP: Focus on finishing over starting
6. Automate Transitions: Reduce manual status updates
7. Measure & Improve: Track metrics, iterate on process
8. Team Buy-in: Involve team in workflow design
9. Visual Management: Use boards for transparency
10. Archive Regularly: Keep active views clean and focused

Choosing the Right Workflow

Team Type	Recommended Workflow	Why
Product Dev Team	Agile Scrum	Predictable planning, clear sprints
Platform/DevOps	Kanban	Continuous flow, varied work types
Support/Ops	Bug Triage	Prioritize by severity, fast response
Product Management	Feature Roadmap	Long-term planning, stakeholder communication
OSS Maintainers	Kanban + Priority	Flexible, contributor-friendly
Startup	Kanban	Fast iteration, changing priorities

Hybrid Workflows

Many teams combine patterns:

• Scrum + Bug Triage: Separate projects for planned work vs bugs
• Kanban + Roadmap: Tactical execution + strategic planning
• Feature Roadmap → Scrum: PM roadmap feeds eng sprint planning

Remember: Workflows should serve the team, not constrain them. Start simple, iterate based on what works for your team's unique needs.