Project Management Hub

This directory contains all project management artifacts for the Heritage Community Hub project.

Single source of truth for work: Azure DevOps Boards (dev.azure.com/hybridcloudsolutions, project "Heritage Community Hub"). The files in pmo/ are reference and planning documents only — they inform ADO, they do not replace it.

Structure

/sprints — Sprint records

• Sprint planning documents (one file per sprint, named sprint-NNN-<slug>.md)
• Sprint goals and commitments
• Sprint review notes

/releases — Release management

• Release planning documents
• Changelogs
• Release criteria and checklists

/retrospectives — Team retrospectives

• Sprint retrospective notes
• Action items and process improvements

/planning — Long-term planning

• Roadmap documents
• Feature specifications and requirements

Project management model

Azure DevOps Boards (authoritative)

All work items are created and tracked in ADO. The hierarchy is:

Epic
  Feature
    User Story
      Task

Key rules (see D:\git\platform\docs\standards\work-items.md for the full standard):

• Titles: verb-first (Create, Add, Fix, Define…); [scope] prefix for cross-repo items; max 120 chars.
• Acceptance Criteria: required on every Epic, Feature, and User Story (minimum 3 per item); minimum 2 for Bugs; not required on Tasks.
• Priority: 1–4; default is 3. Priority 1 = production-impacting; 4 = unscheduled backlog.
• Iterations: YYYY-Q<n>-S<m> (2-week sprints; S1–S6 per quarter). Active items must be assigned a sprint iteration. Unscheduled backlog items stay at the project root iteration.
• Tags: use the standard vocabulary from work-items.md; no freeform tags.
• Dependencies: link items using ADO Predecessor/Successor/Related — do not describe them only in prose.
• Closing: an item may only move to Closed when all AC are met, the pipeline has passed, and any linked GitHub Issues have been updated.

GitHub Issues (intake mirror only)

GitHub Issues serve as a public intake surface and visibility mirror. They are not authoritative.

• A new GitHub Issue triggers creation of an ADO intake item (triage → ADO story or feature).
• ADO status changes are reflected back to the linked GitHub Issue via a comment.
• GitHub Issues are never the source of record for sprint planning or closure.
• Work items tracked in ADO reference GitHub PRs and commits via AB#<id> in the commit message and PR description.

There are no GitHub Milestones or GitHub Projects boards used for sprint tracking. Those concerns live in ADO.

Project management process

1. Work item authoring

Author items in ADO following the work-items.md standard before moving them out of New state. Every item needs: verb-first title, description (what / why now / in scope / out of scope), AC, priority, tag(s), area path, and a sprint iteration (if Active).

2. Sprint planning

• 2-week sprint cycles; iterations named YYYY-Q<n>-S<m>.
• Sprint backlog is locked at sprint start. Mid-sprint additions require Priority 1 or 2 justification.
• Incomplete items move to the next sprint with a comment explaining why.

3. Daily standups

• Progress updates against the ADO board.
• Blockers surfaced and linked as ADO dependencies.

4. Sprint review

• Demo completed work against the sprint goal.
• Verify all items meet AC before closing.
• Identify items to carry forward.

5. Sprint retrospective

• What went well / what to improve / action items.
• Action items become ADO Tasks in the next sprint.

Metrics and reporting

Sprint metrics

• Velocity (story points per sprint)
• Burndown (from ADO sprint burndown)
• Completion rate
• Bug discovery and resolution rates

Release metrics

• Feature completion by phase
• Quality gate pass rates
• Performance benchmarks

Quick links

• ADO Boards — Heritage Community Hub
• ADO Backlog
• ADO Sprints
• Platform strategy (canonical)
• Work items standard
• GitHub repo

Templates

Use these templates for consistency:

• Sprint Planning Template
• Release Planning Template
• Retrospective Template