--- title: "Milestone & Deadline Optimisation | Orangescrum" description: "How to set milestones that give real early warning: fewer of them, tied to verifiable outcomes, with buffer held at the end rather than hidden in every task." canonical: https://www.orangescrum.com/milestone-deadline-optimization --- # Milestone & Deadline Optimisation | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Planning techniques](/optimization) / Milestone and deadline optimisation Planning technique # Milestone and Deadline Optimisation, _Explained Properly_ A milestone is only useful if missing it tells you something in time to act. Here is how to place them so they warn you early, and what Orangescrum tracks them with. [Start free trial](/sign-up?utm_source=site&utm_medium=technique&utm_campaign=milestone-deadline-optimization) [See all features](/features) ## What is milestone and deadline optimisation? A milestone is a zero duration checkpoint in a plan: a date by which something is verifiably true, rather than a task with effort in it. Optimising milestones means choosing few enough of them that each one matters, placing them where a miss gives you enough warning to respond, and tying each to a result somebody can check rather than to a status somebody can claim. Deadlines then follow from the plan rather than being imposed on it. Orangescrum lets you set milestones on the Gantt chart alongside task dependencies and the critical path, so a milestone sits on top of the work that actually determines whether it will be met. ## Why milestones _stop meaning anything_ - **There are far too many of them**Every stage gets a milestone, so missing one is routine. Once a missed milestone is normal, the mechanism has stopped being a warning and become paperwork. - **They measure activity, not results**Design complete is a claim. Design signed off by the three people who have to build it is a fact. Milestones tied to activity are always met and never tell you anything. - **All the warning arrives too late**The first real checkpoint is two thirds of the way in. By the time it is missed the options are cutting scope or moving the date, and neither is cheap at that point. - **Buffer is hidden inside every task**Everyone pads their own estimate, so the project looks fine until it suddenly is not. The margin exists but nobody can see it or manage it as one pool. ## What Orangescrum _actually gives you_ Real features, named. Nothing here is an algorithm that decides for you. [**Put milestones on the timeline**Mark the dates that matter as milestones on the Gantt chart, so a checkpoint sits visibly on top of the work that leads to it._Milestones_](/gantt-chart)[**See which chain decides the date**Critical path shows the sequence that sets your finish, which is where a threat to a milestone will come from long before the milestone itself is due._Critical path_](/gantt-chart)[**Make the knock-on effect visible**With dependencies linked, moving one task shifts everything behind it on the chart, so you can see immediately whether a slip reaches the checkpoint._Task dependencies_](/gantt-chart)[**Compare plan against reality**Baseline against actuals shows the drift between where you said you would be and where you are, which is the earliest honest signal you get._Baseline and reporting_](/project-reports-analytics)[**Keep the dates in one calendar**A project calendar puts due dates and checkpoints somewhere the whole team sees them, rather than in a plan only the manager opens._Project calendar_](/project-calendar)[**Protect the delivery windows**In the Self-Hosted edition, release management adds a release calendar and blackout windows, so a delivery date is not set inside a period you already ruled out._Release management_](/release-management) ## How to _make a milestone worth having_ 1. **Cut the list to the ones that would change a decision**Ask of each milestone what you would do differently if it were missed. If the answer is nothing, it is a status update rather than a checkpoint, and it can come off the plan. 2. **Define each one as a verifiable result**Write the checkpoint as something that is either true or not, and name who confirms it. Signed off by, tested by, or accepted by beats complete every time. 3. **Put one early enough to be useful**Place a real checkpoint in the first third of the project. An early miss is cheap information. A late miss is only an announcement. 4. **Pool the buffer at the checkpoint**Estimate tasks honestly and hold one visible margin before each milestone instead of padding every task. A buffer you can see is a buffer you can spend deliberately. 5. **Watch the chain, not the date**A milestone is not at risk on the day it is missed, it is at risk when the critical path leading to it slips. Review that chain weekly and the date takes care of itself. ## What Orangescrum does not do here Orangescrum tracks milestones and deadlines. It does not optimise them. There is no deadline solver that rearranges the plan to hit a date, no schedule compression, no resource levelling, and no probabilistic forecast that gives you a percentage chance of meeting a checkpoint. It does not flag a milestone as at risk on its own, and it does not escalate anything automatically. Buffer is not a first class concept, so a pooled margin is something you model as a task or a gap and manage yourself. What you get is the milestone on the timeline, the dependencies and critical path leading to it, the baseline to compare against, and the reporting to see drift. Milestones, dependencies, and the Gantt chart are available in Cloud and Self-Hosted, critical path is on the Cloud Premium plan and included in Self-Hosted, and release management with blackout windows is Self-Hosted only. ## Milestone and deadline optimisation FAQ Does Orangescrum automatically adjust the plan to meet a deadline? No. Orangescrum will not reschedule your project to hit a date, compress the schedule, or work out what to drop. There is no deadline solver and no forecast of your chance of finishing on time. It shows the milestone, the chain of work leading to it, and how far the plan has drifted, and the decision is yours. Does Orangescrum have milestones? Yes, and this part is a real feature rather than a technique. Milestones are set on the Gantt chart alongside task dependencies and critical path, and they are available in both the Cloud and Self-Hosted editions. How many milestones should a project have? Few enough that missing one is an event. For most projects that is somewhere between three and seven. If a milestone slipping would not change what you do next week, it is a progress update rather than a checkpoint. What makes a good milestone? It has no duration, it falls on a date, and it describes something verifiably true rather than an activity that has happened. Approved by the customer is a milestone. Development ongoing is not. Naming who confirms it is what stops it being claimed rather than met. Will Orangescrum warn me when a milestone is at risk? There is no at risk flag. What gives you the warning is the Gantt chart: with dependencies linked, a slip upstream visibly pushes the work in front of the checkpoint, and the critical path tells you whether that slip reaches it. That is a weekly look at the plan rather than an alert. Where should the buffer go? In one visible block before the milestone, rather than spread invisibly through every task. Individual padding gets consumed whether or not it was needed, whereas a pooled margin can be spent on the tasks that genuinely went wrong and defended against the ones that did not. Can I stop a delivery landing in a bad week? In the Self-Hosted edition, yes. Release management includes a release calendar and blackout windows, so periods you have ruled out are recorded on the plan rather than remembered. In Cloud you would mark those periods yourself on the project calendar. ## Set checkpoints that warn you early Free 14 day trial, no credit card. Every plan includes unlimited users. [Start free trial](/sign-up?utm_source=site&utm_medium=technique_cta&utm_campaign=milestone-deadline-optimization) ## Related [**Gantt chart**Milestones, dependencies, and critical path](/gantt-chart)[**Critical path optimisation**Shortening the chain that sets the date](/critical-path-optimization)[**Release planning coordination**Getting several teams to one date](/optimization/release-planning-coordination)[**Project calendar**Dates the whole team can see](/project-calendar)