Projects, Milestones, Goals and Estimates
The vocabulary every project management tool uses, explained without assuming you have used one. None of it is required — you can create a project and start making tasks today.
You can ignore most of this
The only two things Projects actually requires are a project and a ticket. Create a project, start writing down what needs doing, and you have a working system. Milestones, goals and estimates exist for teams who want them — they are all optional, and a project that never uses one is not missing anything.
Everything below is here so the words on the screen mean something when you do want them.
The shape of it
Four words cover the whole model. A project holds everything, and a ticket is one piece of work inside it. The other two are just two ways of grouping those tickets.
Each band is one milestone — a theme that outlives any one goal, holding its tickets wherever they fall. Bands are what the roadmap plots.
Read a column and you have a goal: a fixed stretch of time. Only one runs at a time, and it is the board.
Project — The container. One per initiative, client, product line or season — whatever your company organizes work by. It also has a short key of its own, and that key prefixes every ticket id inside it — so a ticket carries its project around with it.
Ticket — One piece of work. It has a type (Task by default), a status, and optionally an assignee, a due date and an estimate. Break it down with subtasks — a title and a status each — and say what it has to do with other tickets: blocks, blocked by, duplicates, relates to.
Milestone — A theme that groups tickets — a release, a client, a campaign, a phase. Milestones are also what the roadmap plots, which is the main reason to use them.
Goal — A fixed stretch of time — often two weeks — that a team commits a batch of work to. Only one goal runs at a time, and the board shows whichever one that is.
Ticket types are yours to name
Every project starts with one type — Task — and adds whatever else that team actually tracks. A software team adds Bug and Story. A landscaping company adds Site visit and Quote. A clinic adds Referral.
- Types belong to one project, the way its labels do — so a team can track something specific without putting the word in everybody else’s menu.
- One type is the default: what a new ticket in that project gets when nobody picks. Any other type can be promoted to it.
- Removing a type never deletes work: its tickets move to another type in that project.
Types are managed per project, under Settings.
The backlog, and running a goal
Every ticket is either in a goal or in the backlog. The backlog is just “everything not committed to yet” — it is where new work lands, and there is nothing wrong with a team that works straight out of it and never plans a goal at all.
If you do run goals:
- Plan a goal, give it an objective and dates, then drag work into it from the backlog. Goals aren’t named — they are numbered for you, Goal 1, Goal 2, and the count starts over each January.
- Start it. It becomes the board, and the board is what the team looks at each day. Only one goal runs at a time, on purpose — two would make “the board” ambiguous.
- Complete it when the time is up. Anything unfinished goes back to the backlog or rolls into the next goal — you choose, and nothing is ever quietly marked done.
Estimates, and why not hours
An estimate is a rough size, not a duration. Out of the box they run on the fibonacci scale — 1, 2, 3, 5, 8, 13, 21 — and the widening gaps are the point: the bigger a piece of work, the less precision anyone honestly has about it. “Somewhere between 8 and 13” is a real answer; “eleven and a half hours” usually isn't.
- Estimate relative to other work: if this is about twice that one, and that one is a 3, this is a 5.
- After a few goals you will know roughly how much your team finishes in one. That number is the only reliable planning input you get — and it is earned, not set.
- Leaving tickets unestimated is fine. They count toward the goal's ticket total and contribute nothing to its estimate, which is exactly right.
- The scale is yours. Fibonacci is only the default — a project's settings cog offers powers of two, a plain 1–5, hours, or whatever numbers you type. A crew that quotes in hours should estimate in hours rather than translate into somebody else's abstraction twice a week. Changing it never touches a ticket: anything already estimated keeps its number even if it leaves the scale.
Then: the roadmap
Goals answer “what are we doing for the next two weeks”. A roadmap answers “what are we doing for the next year”, and it works at the level of milestones rather than tickets.
Who can do what
Access belongs to the project, not to the person. Anyone at your company can start one, and the people added to a project are the people who can see it — a project you were never added to doesn't appear in your sidebar at all.
- Member — does the work: files tickets, picks them up, and adds to anybody's — comments, files, links, related tickets, checklist lines. Changing what a ticket is (its title, description, assignee, milestone, goal, estimate, priority, due date, labels and status) is for the person it was filed by, the person it is assigned to, and the project's managers.
- Whatever you add, you can take back — and only what you add. Removing somebody else's comment, file, link or checklist line is a manager's call, because it takes their account of the work off the record.
- Manager — runs the project as well: milestones, goals, ticket types, settings, deleting, and who else is on it. Whoever creates a project starts as one, and can promote anybody else.
projects:admin— the one company-wide permission. It reaches every project whether or not you're on it, and it's what every Projects endpoint in the public API requires.
Add people from the settings cog on the project, under Who runs it. A project always keeps at least one manager, so the last one can't be removed or stepped down — promote somebody else first. Deleting is permanent everywhere in Projects: there is no archive and nothing to restore, so move finished work to Done rather than deleting it.