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
Project
The container. One per initiative, client, product line or season — whatever your company organizes work by. It has a short key, like SPRING, which prefixes every ticket id in it: SPRING-14.
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 company starts with one type — Task — and adds whatever else it actually tracks. A software team adds Bug and Story. A landscaping company adds Site visit and Quote. A clinic adds Referral.
- A company-wide type is offered by every project — the shared vocabulary everybody files against.
- A project-only type belongs to one project, so a single team can track something specific without imposing it on everyone else.
- Removing a type never deletes work: its tickets move to another type you pick.
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, comments, attaches files, moves things across the board.
- Manager — runs the project as well: epics, sprints, ticket types, settings, archiving, 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. Archiving pulls a record out of every board it was being tracked on, so it stays restorable for 30 days.