← Help & Docs

Projects, Milestones & Sprints

Structure multi-month initiatives into milestones and sprints, with live progress rollup, staff capacity planning, a portfolio dashboard, and a RAID log. Last updated 2026-07-02

TATER Ops → Projects gives you a three-level tree - Project → Milestone → Task - for tracking multi-week initiatives without leaving the platform your compliance data already lives in. A Milestone can also double as a dev Sprint, with a goal and a manual staff capacity roster. Everything expands in place: click a project to see its milestones, click a milestone to see its tasks.

What are Projects, Milestones, and Tasks?

A Project is the top-level container for a multi-month initiative or engagement - a migration, an audit-prep push, a client onboarding. A Milestone is a named checkpoint or phase within that project (e.g. "Phase 1: Discovery", or "Sprint 14"). A regular Tasker task links to a milestone via an optional milestoneId field, giving you the full hierarchy: Project → Milestone → Task.

Milestone progress is always computed live from its linked tasks - never cached or manually updated - so the percentage you see is never stale.

Don't confuse this with Compliance Roadmap. A Roadmap (guide) is a phased remediation plan built from failing controls, with MSP billing and cost tracking. Projects/Milestones track team and task work - who's doing what, by when - independent of any specific control gap. Use a Roadmap to plan and quote remediation; use Projects to run the actual work, including work that has nothing to do with control gaps.

Creating a project

Ops → Projects → + New Project. Required: name. Optional: description, status (Planning / Active / Cutover / PostCutover / Closed), startDate / endDate, common symptoms and known issues (surfaced to the AI Analyst and troubleshooting agents so they check active projects before guessing at root cause), and tags.

Assigning Project Manager / Project Worker roles

A project's Team roles section lets you tag people with a role scoped to that specific project: Project Manager or Project Worker. Add as many of each as the project needs - a project can have co-managers, and everyone else you tag is a worker.

These are not TATER access-control roles. They carry no permission of their own and do not change what a person can see or do anywhere else in TATER (see Settings reference for the actual SuperAdmin / ServiceProvider / OrgAdmin / Auditor / Viewer role hierarchy that gates access). A Viewer can be tagged Project Worker on a project without gaining any elevated access - it's purely a label for "who's running this" and "who's doing the work," shown as a PM: line on the project card and returned to agents via list_active_projects/create_project/update_project so they know who to point a status question at.

Adding milestones

Click a project row to expand it, then + Add Milestone. A milestone carries the datapoints an experienced project manager expects:

Linking tasks to a milestone

Set the Milestone field on any Ops task (create or edit) to link it. A milestone's progress bar, health (on-track / at-risk / complete / no-tasks), and task counts are all recalculated on every read from its currently-linked tasks - there is nothing to keep in sync manually.

Pre-scaffolding tasks with relative due dates

A task linked to a milestone can use a Due date offset (days) instead of a fixed calendar date - "due 5 days after the milestone starts" rather than a specific date you'd have to update if the milestone slips. This lets a PM build out a milestone's full task list before the milestone kicks off, without having to guess real dates in advance.

Parking future-phase tasks as "Planned"

Tasks also have a first-class Planned (parked) state for future project-plan phases - no more 2036-placeholder due dates or dates hidden in the description. A Planned task is:

Tasks created under a milestone that isn't Active yet default to Planned automatically. When the phase arrives, activate the task by setting it to Open or In Progress - the activation date is applied as the due date in the same flip. A "Planned (parked)" status filter on the Ops task queue lists everything parked across the plan.

Planned complements the relative due-date offsets above: use an offset when the task should go live automatically as soon as its milestone starts, and Planned when activation is a deliberate decision tied to a date or trigger.

Linking to controls, risks, and config docs

A milestone can carry linkedControlIds, linkedConfigDocIds, and linkedRiskIds - so, for example, an "Exchange Transport Hardening" milestone stays connected to the actual CIS controls and config docs it affects, not just described in a free-text field. This is what lets an AI agent connect project work back to compliance evidence automatically.

Turning a milestone into a sprint

Set a milestone's Type to Sprint to run it as a time-boxed dev sprint instead of a project phase. The milestone's existing startDate/targetDate become the sprint boundary - no separate sprint dates. Sprint-type milestones get one extra field: sprintGoal, the single outcome statement for the sprint (e.g. "Ship the reporting API"). Everything else - linked tasks, progress rollup, cross-links to controls/risks - works exactly the same as a regular milestone.

Tracking team capacity

A milestone (typically a sprint) can carry a manual capacity roster: one entry per team member with allocated hours (expected to spend) and capacity hours (actually available). The expanded milestone shows a percent bar per person - allocated vs. capacity - so overcommitment is visible before it becomes a missed deadline. Bars turn amber near 100% and red past it.

This is a deliberately lightweight, manual snapshot - not a time-tracking integration. There is no automatic resource-leveling or cross-milestone conflict detection; if a person is over-allocated across two concurrent sprints, that's on the PM to notice, not something TATER flags for you.

Portfolio, Workload, and Timeline views

The Projects page has four tabs: List (the expand-in-place tree described above), Portfolio, Workload, and Timeline - built for a team lead or PM managing several projects at once rather than working inside one at a time.

All three reuse the SAME underlying data the List tab already loads - there's no separate "refresh everything" step, and no extra Cosmos round-trips beyond what Portfolio/Workload each need once per tab switch.

RAID log (Risks, Assumptions, Issues, Dependencies)

Each project has a lightweight RAID Log section (below its milestones when expanded) for the things a PM needs to track that aren't tasks: a Risk that might derail the timeline, an Assumption the plan depends on, an Issue actively blocking progress, or a Dependency on something outside the project's control. Each item has a type, title, optional description, status (Open/Mitigated/Closed), optional owner and impact (Low/Medium/High/Critical), and an optional due date.

This is a quick-add convenience, not the Risk Register. A RAID Risk entry lives only on the project and has no likelihood/impact scoring or formal acceptance workflow. If a risk needs either of those, track it in the full Risk Register instead (a project's linkedRiskIds field is how the two connect) - RAID is for fast capture during project work, not a replacement.

My TATER: personal workload and RAID items

My TATER's dashboard surfaces the same data scoped to you specifically, so an individual contributor doesn't need to open Ops to see where they stand:

XP and achievements for project work

Creating a project or milestone, and completing a milestone (sprint or not), award XP and count toward achievements - first project, 5 projects, first milestone, 10 milestones, first completed milestone, 10 completed - the same incentive layer that drives control and task hygiene elsewhere in TATER. See the Community & Gamification guide for the full XP/achievement system.

REST endpoints

MCP tools (HTTP + stdio parity)

AI agents connected over MCP are tuned to proactively turn multi-step work described in chat into a tracked Project with Milestones - if you describe a migration, a multi-phase audit push, or a rollout, ask your agent to structure it as a project instead of leaving it as a one-off chat answer.

Recommended patterns

Pitfalls