shield_lock
JinDaGe
← Back to skills
extension
Category: Development & EngineeringNo API key required

project-workflow-patterns

Common GitHub Projects workflow patterns and best practices for team collaboration. Use when designing workflows, setting up new projects, or optimizing existing processes.

personAuthor: jakexiaohubgithub
open_in_newRepositorydownloadDownload package

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.