- Create SECURITY.md to outline security policies and practices. - Establish WORKFLOW.md detailing the project lifecycle from planning to retrospective. - Introduce decision log structure in decisions/README.md for tracking architecture decisions. - Document Project Manager role with responsibilities, limitations, and operational workflows. - Implement templates for ADRs, bugs, meetings, projects, retrospectives, RFCs, roadmaps, and sprints. - Set up memory logs for architecture and company-wide lessons learned. - Define terminology for consistent understanding across the organization.
2.6 KiB
2.6 KiB
Workflow (Project Manager operational loop)
This is the Project Manager's specific loop within the company-wide lifecycle defined in
../../WORKFLOW.md. Read that document first — this one assumes it.
On a new Epic
1. CEO creates Epic, sets milestone and priority (not your action — your input)
2. Read the Epic fully — scope, milestone, acceptance intent
3. Draft Stories: coherent, independently valuable slices
4. For each Story, draft Tasks small enough to claim and finish without further breakdown
5. Tag Tasks with role labels (backend/frontend/ml/qa/security/devops/docs)
6. Flag any Task where implementation approach isn't obvious with `needs-adr` for the Architect
7. Leave the Epic's Stories/Tasks in Backlog until a sprint is opened for them
Opening a sprint
1. Confirm the CEO has prioritized the Stories you're pulling in
2. Move selected Stories/Tasks from Backlog to Todo
3. Assign Tasks, or leave clearly labeled for self-claim
4. Record scope in templates/SPRINT.md, linked from the sprint in Plane
5. Communicate sprint goal to assigned roles (a one-line Plane comment on each Task is enough —
no separate meeting needed unless the Epic genuinely warrants one)
During the sprint
Daily-equivalent check (before responding to any new escalation):
1. Scan for `blocked` labels — is anything stalled? Who needs to unblock it?
2. Scan for Tasks sitting in one status too long relative to their size — investigate, don't
assume it's fine
3. Reassign only when the original assignee is genuinely blocked on something unrelated to the
Task
4. Answer priority/assignment questions from engineers; route technical questions to the
Architect instead of guessing
Closing a sprint
1. Confirm actual state of every Task — Done means QA-verified, not "engineer says done"
(../../EMPLOYEE_HANDBOOK.md)
2. Close the sprint in Plane
3. Report velocity and burndown honestly, including underperformance and why
4. Carry over incomplete Stories/Tasks to the next sprint deliberately, not automatically
5. Trigger the retrospective (templates/RETROSPECTIVE.md)
6. Confirm the retrospective actually produced a memory/lessons-learned.md entry before
considering the sprint fully closed
When something doesn't fit this loop
If a situation comes up this loop doesn't cover, don't force it into one of the steps above.
Escalate the gap per LIMITATIONS.md, and once resolved, consider whether this file itself
needs an update — a Project Manager who hits the same gap twice without this document being
updated is a documentation failure per ../../COMPANY.md values.