Small teams
Give a small product team one shared release, stable areas, clear task ownership, and an async routine that replaces status meetings.
A four-person product team needs a shared view of what's shipping, who owns each task, and what changed since yesterday. It doesn't need a workflow designer or layers of planning. This setup uses one project, four stable areas, and one active release, so anyone can open Frostbyte and understand the current work without asking for a status update.
Recommended setup at a glance
| Part | Example setup |
|---|---|
| Project | Workspace app |
| Product context | A collaborative workspace for small client-service teams that need decisions and files in one place |
| Areas | Auth, Workspace, Notifications, Billing |
| Active release | Team invites |
| Starter tasks | Create invite links, add role selection, send invite email, show pending members |
| Cadence | One owner per task; a 15-minute weekly scope and ownership review |
| Agent role | Draft scoped tasks and keep each developer's coding agent working from the same plan |
Agree on stable areas before the board fills up
Map the product into three to six areas that will still exist after the current release. Auth, Workspace, Notifications, and Billing work because they describe systems with ongoing ownership. "Team invites", "beta", and "Q3" don't; those are outcomes or time periods.
Agreeing on areas early gives every new task an obvious home, and gives teammates and coding agents enough context to find related work. Review areas when the product architecture changes, not every sprint.
Keep one shared active release
The active release answers one question: what are we shipping together now? Team invites beats "v1.4" because the intended result is clear. The release is done when an owner can invite a teammate, choose a role, and see whether the invitation was accepted.
Only include tasks required for that result. Improvements, unrelated bugs, and later ideas stay in the backlog unless they block the release. Anyone opening Releases should be able to judge progress from the outcome, the remaining tasks, and the status.
Make task ownership explicit
Assign one person to each task. Others can contribute, but one owner is responsible for moving it forward or saying why it's blocked. Use priority for real ordering pressure, not as a substitute for deciding what belongs in the release.
Keep statuses honest: To Do means ready but not started, In Progress means someone is actively on it, Done means the expected result exists. If In Progress keeps growing, stop starting and finish what's already there. See Tasks for task properties and assignment.
Catch up asynchronously
The activity feed records meaningful changes to tasks, releases, areas, and feedback. Use it as the first stop after time away: scan recent activity, open the active release, and know what needs attention before sending a message or booking a meeting.
This only works when the plan reflects reality. Move a task when its state changes, record blockers in the description, and update the release when the team changes scope on purpose.
Put humans and agents on the same plan
Each developer can connect Claude Code or Codex to the project. The agent reads the same product context, areas, releases, and tasks as the team, which cuts down hand-written setup prompts and keeps implementation tied to the agreed scope. Use auto-tracking so the repository resolves to the right project automatically.
Agents should update the task they're working on, not build a second private backlog in chat. Humans still decide priority, release scope, and whether a tradeoff is acceptable.
Centralise incoming feedback
Enable the Feedback Portal when reports start arriving through several people. One shared queue captures bugs and requests; review it on a simple rotation. Convert a submission into a task only when the problem is understood and someone will own it.
Run a weekly scope and ownership check
- Confirm the active release still represents the next shippable outcome.
- Check every open release task for a clear owner and next step.
- Move unrelated work back to the backlog instead of stretching the release.
- Review new feedback and assign one person to follow up or close it.
Fifteen focused minutes is enough when the board stays current during the week.