Linear structure guide (delivery)
Aligns with sow-project-plan-template.md terminology table and playbook §8.2 (see playbook PLAYBOOK_DEVELOPMENT_PLAN.md).
Hierarchy
| Linear object | Use for |
|---|---|
| Team | Client / engagement container |
| Initiative | Major client objective (often maps to SOW theme) |
| Project | Workstream under an Initiative (offering or work package) |
| Project milestone | Client-visible outcome or phase gate |
| Issue | Atomic work; one assignee; links to Project (and milestone when helpful) |
Rules of thumb
- Don’t invent extra layers (e.g. fake “Phase” entities) unless the team explicitly agrees — express timing with milestones and dates on Projects.
- Naming: consistent client prefix (see template § “Linear naming conventions”).
- Hygiene: No orphan Issues without Project when the engagement uses projects; see linear-hygiene-standards.md.
Practice team exception (service lines)
Default: Team = Client engagement.
Exception: One internal practice team for service-line capability work where Brainforge is the client.
| Element | Pattern | Example |
|---|---|---|
| Team | Single “Delivery — Practice” (or similar) | Delivery — Practice |
| Initiative | Establish {X} Service per top-level line | Establish Data Service |
| Project | Quarterly or thematic buckets | Q2 2026, Playbooks, Operating hygiene |
| Issue | Archetypes: playbook, service review follow-up, Operating hygiene | Same shape across all three lines; line-specific content in title/AC |
Supersedes older debates: Views + Operating (not labels) for cross-client visibility; Operating (not Linear) for allocation hours; practice board for capability outcomes only.
See client-vs-service-line-systems-of-record.md for full SoR table.
Last updated: 2026-03-30