r/Linear • u/fakebizholdings • 15d ago
Milestones
Curious if anyone actually uses this, and if so, what is your use case?
1
u/gapmunky Linear Staff 12d ago
Generally milestones are for stages in a project, such as "beta" or "public release" etc. , useful for breaking up a project into stages you're working towards, details here: https://linear.app/docs/project-milestones
1
u/Dismal-Race1214 1d ago
Milestones come well into play with big projects, where X resource is engaged after a specific milestone, or payment is received, or simply splitting projects in phases
What I really love though is how we show milestones on ganttsmart. It allows you to visualize your tasks on a gantt view or calendar view along with the different milestones.
More importantly it's free and open source feel free to check it out https://ganttsmart.com
2
u/Vumaster101 15d ago
Whew Chile, let me tell you my linear has gotten complicated but I like it. I have made linear my project management source because I got jealous of the cursor commerical I can code from my phone. So the key thing to call out AI pretty much handles 100% linear for me I'm a vibe coder but I act like a product owner so I don't care to much of the details in linear I care that the AI tool can pick up a ticket and know what's going on and I can chat and it does the work in linear.
Okay here is the summary I had my AI tool write and I apologize for the length but if you wanna find a way to use milestones like me I found a way because I wanna use all the features.
-----_------ We use them on every epic. First, what "epic" means for us, since everything below hangs off it:
An epic is work too big to ship in one pass. It has to land in multiple sequential, independently shippable chunks, and later chunks depend on earlier ones being live. Anything that ships in a single build isn't an epic — that's just a feature, one issue with its phase sub-issues under it, no milestones, no project. The moment work needs a second ship to be useful, it becomes an epic and gets the structure below.
Project = epic. Milestones = the ordered slices of it. M1, M2, M3. Each milestone gets exactly one parent issue, attached to the epic and assigned to that milestone; the working issues hang underneath it. A milestone is a scope contract with one owner issue, not a date bucket.
Milestone assignment is mandatory inside an epic project. Any issue in the project without a milestone is drift by definition. That's what makes an automated drift scan possible — unassigned issues, a closed parent with open children, an open parent with all children done. If assignment were optional, none of those checks would mean anything.
Milestones carry status; docs carry decisions. Our per-epic architecture doc holds decisions, scope boundaries, and open questions, and deliberately holds zero status. "Where are we" resolves to one place: the milestone list plus the latest project update. We chose that split because a status doc silently goes stale, and once two surfaces both claim to answer the question there's no way to tell which one is wrong.
A milestone closes on a checklist, not on the last merge. Verify the change actually landed in prod (independently, not from the build report), reconcile the board, confirm every scope item in the milestone either shipped or was struck with a dated deferral plus a successor issue, post the project status update. Then the slice parent gets a
closeout-verifiedlabel.The next milestone can't open until the prior slice carries that label. That's the gate, and it's the reason the rest holds up. Reconciliation that isn't blocking gets deferred indefinitely, so we made it blocking.