Project Management
Work is planned in two-week sprints, everywhere. The tracker depends on the kind of work:
| Work | Tracker |
|---|---|
| CueHIRE™ client engagements | Linear — one team/project per engagement. Client reports arrive through Jira Service Management today and are triaged into Linear; the roadmap is a WhatsApp bot filing Linear issues directly, automating intake end to end. SLAs per client engagements. |
| CueLABS™ open-source products | GitHub Projects — boards live beside the code in the cuesoftinc org, in the open like the products. |
| CueTA™ teaching | Google Classroom carries cohorts today; our own CueLearn platform is being built to replace it. |
The sprint
- Planning. At sprint start, the lead and the team select the sprint's issues by business impact, severity and capacity. A sprint is a commitment, not a wishlist.
- The board. Every issue moves through the same states: Todo → In Progress → In Review → Done. One in-progress issue per person — finish or park before pulling the next.
- Issues are the record. Told something verbally? Write the issue yourself, immediately, and assign it to yourself. If it isn't on the board, it isn't planned.
- Done means shipped. An issue closes when the work is merged, deployed to the target environment and verified — not when the code is written.
Issue hygiene
- Titles state the outcome ("Applications page 500s on empty phone"), not the activity ("look into bug").
- Every bug carries reproduction steps, expected vs actual, and screenshots or logs where they exist.
- Epics/projects group large bodies of work; break them into issues small enough to finish within a sprint.
Capacity honesty
There are roughly twenty-six sprints in a year, and a sprint holds what it holds. When requests exceed capacity, we prioritise with the client or the product lead rather than pretending everything fits — see client engagements for how that conversation is governed.