Projects, Epics, Sprints and Story Points
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. Epics, sprints and story points 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 epic — a theme that outlives any one sprint, holding its tickets wherever they fall. Bands are what the roadmap plots.
Read a column and you have a sprint: 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.
Epic — A theme that groups tickets — a release, a client, a campaign, a phase. Epics are also what the roadmap plots, which is the main reason to use them.
Sprint — A fixed stretch of time — often two weeks — that a team commits a batch of work to. Only one sprint 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 sprint
Every ticket is either in a sprint 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 sprint at all.
If you do run sprints:
- Plan a sprint, give it a goal and dates, then drag work into it from the backlog. Sprints aren’t named — they are numbered for you, Sprint 1, Sprint 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 sprint 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 sprint — you choose, and nothing is ever quietly marked done.
Story points, and why not hours
A story point is a rough size, not a duration. Estimates 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 sprints you will know roughly how many points 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 sprint's ticket total and contribute nothing to its points, which is exactly right.
Then: the roadmap
Sprints 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 epics 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, epic, sprint, 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: epics, sprints, 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 under Settings → Who's on this project. 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.