335 lines
10 KiB
Markdown
335 lines
10 KiB
Markdown
---
|
||
name: project-workflow-patterns
|
||
description: Common GitHub Projects workflow patterns and best practices for team collaboration. Use when designing workflows, setting up new projects, or optimizing existing processes.
|
||
---
|
||
|
||
# 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.
|