Process
How we work day to day — the work hierarchy, milestones and versioning, labels, the board, DRIs, and our operating cadence.
Work hierarchy
We plan and track work in GitHub, using two levels: epics and issues.
Epics
An epic is a tracking issue for a body of work that spans more than one milestone, with the individual issues that make it up linked as children. Epics carry the epic label. An epic is bounded — it has a defined scope — and it closes when that scope is complete, not on a fixed date.
A large epic can be broken into a parent epic with child epics linked under it, the parent-child link is what expresses the nesting.
Issues
Issues are the unit we actually plan and schedule against. The rule of thumb: one issue = one user story = fits in one milestone. If something doesn’t fit in a month, it’s either an epic with several issues under it, or it needs to be broken down further.
New issues should use the issue template (problem statement, user story, acceptance criteria, task checklist).
Milestones and versioning
Milestones are our planning time-box. We plan, scope, and report against them — not against arbitrary sprints or ad hoc dates.
- Cadence: roughly one milestone per month.
- Naming:
XX.0,XX.1,XX.2, … — the minor number increments each milestone, and the major number (XX) bumps every important release. - Dates: every milestone has an explicit start and due date. A milestone always starts on a Monday, so it usually runs about a month but can be a little longer to line up with the week boundary.
An issue belongs to exactly one milestone. If it slips, it moves to the next milestone rather than sitting in a dateless limbo.
Label taxonomy
We use a small, consistent set of labels rather than letting them sprawl:
| Label | Meaning |
|---|---|
type::feature | New user-facing capability |
type::bug | Something broken that needs fixing |
type::tech-debt | Non-user-facing cleanup, refactor, or paydown work |
type::ux | Design/UX-driven work |
epic | Marks a tracking issue as an epic |
priority::p1 / priority::p2 / priority::p3 | Relative priority, used mainly during planning and triage |
needs-refinement | Not yet ready to be pulled into a milestone — scope or acceptance criteria still need work |
If you find yourself wanting a new label, raise it with the product DRI rather than adding it ad hoc — the taxonomy only stays useful if it stays small.
The board
There’s one persistent GitHub Projects board, not a new board every month. Its columns are:
Backlog → Planned → In Progress → In Review → Done
Epics show up across milestones too — the roadmap view surfaces epic progress across the milestones their child issues live in, so you can see a multi-month body of work at a glance without digging through individual issues.
Milestone-filtered views
To see what’s happening in a specific milestone, use the board’s milestone field with a view filtered or grouped by milestone, rather than spinning up a separate board. This keeps history and cross-milestone context in one place instead of scattered across throwaway boards.
DRIs and ownership
A DRI (Directly Responsible Individual) is the one person accountable for a given piece of work moving forward — not necessarily the person doing all of it, but the person you go to if it stalls, and the person who makes the call when a decision is needed.
- The product DRI owns the backlog: what’s in it, how it’s prioritized, and what’s ready to be pulled into a milestone.
- Each milestone has a DRI accountable for its scope and for surfacing blockers during the weekly sync.
- Each epic has a DRI accountable for its overall progress across the milestones it spans.
If it’s not obvious who the DRI is for something, that’s worth raising in planning rather than guessing.
Operating cadence
Every milestone gets a standing planning issue, created from the planning issue template, that captures its scope, goals, and the list of candidate issues going in. That issue is the reference point for planning sessions touching that milestone.
Daily standups
A daily async standup runs in Slack via Geekbot. Answer the standard questions (what you did, what you’re doing, any blockers) on your own time each day; no meeting required.
Weekly sync
A recurring meeting to review in-progress work, surface blockers, and check milestone burndown. Calendar invite and agenda template are attached to the recurring event.
Planning
Every two weeks, a forward-looking session to plan the next few milestones, refine and prioritize the backlog, and pull ready issues into upcoming milestones. Also has a calendar invite and agenda template.
Retros
Retrospectives run ad hoc, not on a fixed schedule. Triggered by a milestone wrapping up, an incident, or just the team feeling one would help.