Planning technique

Resource-Constrained Scheduling, Explained Properly

A plan that ignores who is available is a wish with dates on it. Here is how to schedule around real capacity, and a straight account of what Orangescrum does and does not automate.

Start free trial See all features

What is resource-constrained scheduling?

Resource-constrained scheduling means building a schedule around the people and equipment you actually have, rather than around dates and dependencies alone. An ordinary plan assumes a task can start as soon as the work before it is finished. A resource-constrained plan adds a second rule: it can only start if somebody is free to do it. Adding that rule almost always pushes the finish date out, which is uncomfortable and also true. In classic project management the technique is paired with resource levelling, where a scheduling algorithm shifts tasks within their slack until nobody is over-allocated, and with resource smoothing, which does the same without moving the end date.

Where capacity quietly breaks the plan

The plan assumes everyone is fully availableFive days a week of project work per person, with nothing subtracted for meetings, support duty, interviews, or the other project they are also on.
Over-allocation is discovered by the person, not the plannerThe engineer notices they are booked twice, tells nobody, quietly picks one, and the other task slips silently until somebody chases it.
One scarce skill sets the whole dateThere is a single person who can do the database work or the design. The plan is drawn as if that skill were plentiful, so every estimate downstream is wrong.
Approved leave is nowhere in the scheduleSomeone books a fortnight off, it is approved, and the plan still shows them working through the middle of it on a task with no slack.

What Orangescrum actually gives you

Real features, named. Nothing here is an algorithm that decides for you.

See availability, not headcountAllocation and availability per person show how much of someone is genuinely free in a period, which is the number a constrained plan has to be built from.Resource management Find over-allocation before the person doesThe workload heat map shows who is committed beyond capacity and in which week, so the collision is visible at planning time rather than at delivery time.Workload heat map Let approved leave reduce capacityIn Self-Hosted, attendance and approved leave feed the capacity you plan against, so a booked holiday is not silently scheduled over. Self-Hosted only.Attendance and leave Reschedule and see what movesDrag work on the timeline and dependent tasks follow, so you can try a rebalanced plan and see the cost in days before you commit to it.Gantt chart Know which slip actually mattersCritical path shows the chain that sets the end date. Tasks with slack are where you absorb a capacity problem without moving the delivery.Critical path Check the calendar before you commitA shared calendar shows holidays, absences, and clashing dates across the project, which is usually where an over-optimistic plan first shows its cracks.Project calendar

How to schedule around real capacity

Start from availability, not headcountTake each person's week and subtract leave, meetings, support duty, and time on other projects. The usable figure is almost always well below five days.
Name your scarce skillsIdentify the skills only one or two people have. Those people are your constraint, and the realistic schedule is really their schedule.
Schedule the constraint firstBook the scarce person's work before you plan anything around it. Planning everything else first and hoping they fit is how the date slips.
Look at the workload view before you publishCheck the heat map for anyone over capacity. A plan published with visible over-allocation will be broken by the second week, and everybody will already know.
Rebalance by hand, then check againMove a task, reassign it, or move a date. Then look at the heat map once more, because fixing one collision routinely creates another somewhere else.

What Orangescrum does not do here

This is the page where the gap matters most, so it is worth stating flatly. Classic resource-constrained scheduling assumes resource levelling, where an algorithm shifts tasks within their slack until nobody is over-allocated. Orangescrum does not do that. There is no levelling engine, no scheduling solver, and nothing that moves your tasks to resolve an over-allocation. What it does is surface the problem: the workload heat map shows who is over-committed and when, resource management shows availability and allocation, and in Self-Hosted approved leave reduces the capacity you plan against. A human then rebalances, by reassigning, resequencing, or moving a date. If you need genuine automated levelling across a large constraint set, that is specialist scheduling software and you would run it alongside us. Resource management and the workload heat map are on the Cloud Premium plan and included in Self-Hosted.

Resource-constrained scheduling <em>FAQ</em>

Does Orangescrum automatically level resources?

No. There is no resource levelling algorithm in any edition, and nothing that reschedules tasks to remove an over-allocation. Orangescrum shows you who is over-committed, by how much, and in which period, and a person rebalances the plan. We would rather say that plainly here than have you find it out during a trial.

What is the difference between resource levelling and resource smoothing?

Levelling moves tasks until nobody is over-allocated and accepts a later finish date. Smoothing rearranges work inside the existing slack so the end date does not move, which means it can only fix smaller conflicts. Neither is automated in Orangescrum, but the workload view gives you what you need to do either by hand.

How do I find over-allocation?

The workload heat map. It shows commitment against capacity per person per period, so someone booked beyond what they have appears clearly rather than as two separate assignments that each look reasonable.

Does approved leave reduce capacity automatically?

In Self-Hosted, yes, attendance and approved leave feed the capacity you are planning against. On Cloud that link does not exist, so teams reflect leave manually, usually by keeping it on the project calendar and checking it before committing dates.

Which plan or edition do I need for this?

Resource management and the workload heat map are on the Cloud Premium plan and included in Self-Hosted. Dependencies and the Gantt chart are in Cloud and Self-Hosted, with critical path on Cloud Premium and in Self-Hosted. Attendance and leave feeding capacity is Self-Hosted only.

Should I plan people at one hundred per cent?

No. A person planned at full capacity has no room for the meetings, questions, and small interruptions that make up a real week, so the first small problem pushes the plan out. Most teams plan project work at somewhere around two thirds of the working week and still find it tight.

What do I do when the constrained plan misses the deadline?

You have three levers and only three: reduce the scope, add capable people, or move the date. Adding people helps least in the short term because they need time from the people you already have. Choosing between the three early is the value of doing this at all.

Is this the same as critical chain?

No. Critical chain is a related method that adds explicit buffers around the constrained resource and manages those buffers instead of individual task dates. Orangescrum does not implement critical chain buffers. You can approximate the idea by leaving slack around your scarce people, but it is a working practice rather than a feature.

Plan around the people you have

Free 14 day trial, no credit card. Every plan includes unlimited users.

Start free trial

Resource managementAvailability, skills, allocation Workload managementOver-allocation made visible Workforce assignmentDeciding who does the work Multi-project schedulingSeveral projects, one team