Projects are containers with intent: a name, an owner, dates, and a status. Sprints are optional cycles within them.
Projects
Use a project when work has a beginning and an end, or a client, or a budget. Do not create one for every category of ongoing work; that is what filters and labels are for.
A project view shows its tasks, its timeline, its people, and its activity. For agencies and services teams, the project is also where budget consumption and profitability live, joined from Finance and time entries.
Sprints
If your team works in cycles, sprints add a start date, an end date, and a scope. During a sprint you get burndown, scope-change visibility, and slippage detection: when the AI notices velocity is off pace, it raises a signal rather than waiting for the retrospective.
Teams that work continuously should skip sprints entirely. Kanban with a work-in-progress limit is a complete way to operate here.
Releases and milestones
Milestones mark meaningful dates inside a project. Releases group what shipped, which matters if you also use Product OS.
Keeping status honest
Pro Tip: The weekly status meeting exists because nobody trusts the board. Fix the board instead: make sure statuses are current, then let the AI produce the weekly summary. Most teams find the meeting shrinks to the decisions that actually need discussion.