# PM Sprints & Agile Resources

Curated for the merge decision in [[MISSION.md]]. Everything here is a primary or
peer-reviewed source; nothing is vendor marketing.

## Knowledge

- [The Scrum Guide (2020), Schwaber & Sutherland](https://scrumguides.org/scrum-guide.html)
  The normative definition, and the single most decision-relevant source here.
  Read the **Sprint** and **Commitment: Sprint Goal** sections. Note what the
  Guide does *not* say: there is no numeric commitment, no velocity, no story
  points, and no capacity. The commitment is a **Sprint Goal**, qualitative.
  Use for: deciding what a sprint is permitted to store, and why
  `pm_sprints.committed_points` has no authority behind it.

- [InfoQ: "Changes in the 2020 Scrum Guide — Q&A with Ken Schwaber and Jeff Sutherland"](https://www.infoq.com/articles/changes-2020-scrum-guide/)
  Primary interview with the co-creators. The load-bearing quote is Sutherland
  on why *Commitment* was removed in 2017 and reintroduced qualitatively in 2020:
  > "Unfortunately, some managers weaponized team velocity. They criticized teams
  > for delivering a point less or sometimes even for delivering a point more
  > directly running counter to what Edward Deming taught the Japanese. Systems
  > have variability and if you try to control normal variability, the system
  > will spin out of control."

  Use for: the single strongest argument against persisting velocity as a
  committed number. Directly applicable to `committed_points` / `completed_points`.

- [Rodamar: "There ought to be a law! Campbell versus Goodhart", Systematics](https://rss.onlinelibrary.wiley.com/doi/10.1111/j.1740-9713.2018.01205.x)
  Peer-reviewed account of why metrics corrupt under pressure. Gives Strathern's
  "When a measure becomes a target, it ceases to be a good measure" and Campbell's
  longer 1979 formulation, plus the precedence argument (Campbell first, 1969).
  Use for: the general rule that any metric you render *next to a person's name*
  will be gamed. A sprint board in a product sold to HR buyers will be gamed.

- [Forsgren, Storey, Maddila, Zimmermann, Houck, Butler — "The SPACE of Developer Productivity", ACM Queue 19(1)](https://queue.acm.org/doi/fullHtml/10.1145/3454122.3454124)
  The alternative to velocity: five dimensions in tension (Satisfaction,
  Performance, Activity, Communication, Efficiency) rather than one number. Full
  text is free. Use for: what to show on `/pm/sprints` instead of a points
  progress bar — and note their PR-turnaround-SLA story, which is the exact
  failure mode of a deadline metric on a delivery board.

- [The Agile Manifesto and Principles](https://agilemanifesto.org/)
  Short, primary, worth the three minutes. Principle 2 ("changing requirements
  are welcome") and the manifesto principle "working software over comprehensive
  documentation" both bear on whether an unwired sprint board is a net positive.
  Use for: arguing against speculative surface area.

- [Wikipedia: Goodhart's law](https://en.wikipedia.org/wiki/Goodhart%27s_law)
  Tertiary, kept only for the citation graph back to Goodhart 1975 and
  Strathern 1997. Prefer the Rodamar paper for anything quotable.

### Repo-local sources (highest trust of all — read the code, not the docs)

- `dbschema.md` — the actual Postgres shape. Ground truth. Lines 2897 (`pm_sprints`),
  3635 (`tasks`), 3039 (`project_milestones`), 3088 (`projects`).
- `apps/backend/lib/services/capacity.service.ts` — the only real HRMS↔work
  interlock. Reads employees, employee_capacities, project_resource_allocations,
  project_members, leave_requests, tasks, timesheet_entries, holidays.
- `apps/backend/lib/task-status.ts` — an unusually good in-repo essay on why a
  free-text status column rots, and the precedent for the fix. Model for how to
  document the sprint decision.
- `apps/frontend/lib/pm-store.ts` — the hybrid localStorage/Supabase store that
  makes the whole module untrustworthy.
- `PM_MODULE_GUIDE.md` §5 and `PROJECT_MANAGEMENT_WORKFLOW.md` — **actively
  misleading**. Cite only as the thing being corrected.

## Wisdom (Communities)

- [r/ExperiencedDevs](https://reddit.com/r/ExperiencedDevs/)
  High-signal, sceptical of process tooling, tolerant of "we tried Jira and it
  hurt". Good place to test the *"do PMs actually use sprint boards or is this
  enterprise theatre?"* half of the decision.

- [r/ExperiencedManagers](https://reddit.com/r/ExperiencedManagers/)
  For the other half: what actually survives contact with a paying client, and
  which PM artifacts get used when someone is holding a deadline.

- Local: the three-person LVC dev standup. The decision ultimately lands on
  whether Chakresh, plus the two other devs, will ever look at
  `/pm/sprints`. No community will answer that.

## Gaps

- No primary-source study on **sprint length vs estimation accuracy** that we
  could cite. The literature here is weak and mostly vendor content. If a future
  session needs "do two-week sprints estimate better than four-week ones", this
  gap will block it — seek an academic source before asserting anything.
- No source on **multi-tenant SaaS product analytics for sprint tooling** — i.e.
  what fraction of HR-suite customers actually open a sprint board. This directly
  affects the commercial case for building it. Worth a session with real PMs
  (see Wisdom) rather than a literature search.