Small teams

A four-person product team needs a shared view of what is shipping, who owns each task, and what changed since yesterday. It does not need a workflow designer or several 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
Ownership and cadence	One owner per task; a 15-minute weekly scope and ownership review
Agent role	Draft scoped tasks, retrieve context, 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” do not; those are outcomes or time periods.

Agreeing on areas early gives every new task an obvious home. It also gives teammates and coding agents enough context to find related work without creating a hierarchy of epics and sub-projects. Review areas when the product architecture changes, not every sprint.

Keep one shared active release

Use the active release to answer one question: what are we shipping together now? Team invites is a stronger release than “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. Keep improvements, unrelated bugs, and later ideas in the backlog unless they block the release. Anyone opening Releases should be able to judge progress from the outcome, remaining tasks, and current status.

Make task ownership explicit

Assign one person to each task. Other people can contribute, but one owner is responsible for moving it forward or explaining why it is blocked. Use priority for actual ordering pressure, not as a substitute for deciding what belongs in the release.

Keep statuses predictable: To Do means ready but not started, In Progress means someone is actively working on it, and Done means the expected result is complete. If In Progress keeps growing, stop starting work and finish or unblock what is 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 place to catch up after time away. A teammate should be able to scan recent activity, open the active release, and know what needs attention before sending a message or scheduling a meeting.

This works only when the plan reflects reality. Move a task when its state changes, record the blocker in its description, and update the release outcome when the team deliberately changes scope.

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 reduces hand-written setup prompts and keeps implementation tied to the agreed scope. Use agent auto-tracking so the repository resolves to the correct project automatically.

Agents should update the task they are working on, not create a second private backlog in chat. Humans still decide priority, release scope, and whether a tradeoff is acceptable.

Centralise incoming feedback

Enable the Feedback Hub when reports start arriving through several people. Let one shared queue capture bugs and requests, then review it on a simple rotation. Convert a submission into a task only when the problem is understood and someone is willing to own it.

Run a weekly scope and ownership check

1. Confirm the active release still represents the next shippable outcome.
2. Check every open release task for a clear owner and next step.
3. Move unrelated work back to the backlog instead of stretching the release.
4. Review new feedback and assign one person to follow up or close it.

This is a planning check, not a progress performance review. Fifteen focused minutes is enough when the board stays current during the week.

Apply this setup

1. Write the product context and create four stable areas with clear descriptions.
2. Invite the team and assign an owner to every active task.
3. Create one active release named after the outcome, then remove work that does not support it.
4. Connect each developer's agent to the same project and repository.