Exercise set

Operations Queue Capacity, Service Level, and WIP Control Exercises

Solved operations queue exercises for Little's Law, utilization, M/M/1 waiting time, tail risk, WIP caps, capacity and service release.

These exercises practise operations queue and capacity decisions: Little’s Law, utilization, service rate, waiting time, tail probability, added capacity, WIP limits, bottleneck capacity, urgent-job reserve, service-level release and validation trials.

The goal is to make queue performance operationally honest. A process can look efficient at high utilization while lead time grows, tail wait fails, urgent work waits too long, WIP hides problems or average throughput masks a bottleneck.

Assume simplified queueing screens unless an exercise states otherwise. Real service release should also check arrival clustering, priority classes, job-size distribution, rework, travel time, batching, skill constraints, shift coverage, failed handoffs and data quality.

Release Evidence Notes

Queue evidence should define arrival boundary, service boundary, WIP boundary and priority class. Mixing urgent work, routine work, rework and waiting-for-parts jobs creates false utilization and false wait estimates.

Capacity evidence should separate theoretical capacity from effective capacity. Breaks, setup, travel, changeovers, quality review, meetings and escalation work can reduce the service rate that actually controls waiting time.

Service-level evidence should include average wait and tail wait. A queue may pass average lead time while failing the probability of exceeding an urgent threshold.

WIP evidence should be tied to throughput and lead-time targets. Reducing WIP without protecting bottleneck capacity can starve the system; increasing WIP without capacity can hide aging work.

Engineering Boundary Notes

This page covers queue and service-capacity behaviour. Critical path and milestone schedule risk belong in the operations schedule exercise set. Backlog recovery, skill-hour loading and shutdown readiness belong in the resource-loading exercise set.

If a queue result fails because a specific skill, permit, spare or work package is unavailable, the failed readiness gate should be escalated to the resource-loading or spare-parts page.

Scenario Map

ScenarioExercisesPrimary checkEngineering decision
WIP and lead time1-3, 10Little’s Law, WIP cap and throughputSet release rate or WIP limit.
Capacity and utilization4-6, 12-14crew count, utilization and effective capacityAdd capacity, reduce demand or split work classes.
Queue wait and tail risk7-9, 15M/M/1 wait, tail probability and service-level marginDecide whether the service queue is releasable.
Bottleneck and release validation11, 16-18bottleneck rate, trial output and hard gatesRelease, restrict or rebalance operations.

Exercise 1: Little’s Law Lead Time

A planning queue has average WIP:

L=54\ \text{work orders}

and completion rate:

\lambda=18\ \text{work orders/day}

Estimate average lead time.

Solution

Little’s Law gives:

L=\lambda W

So:

W=\dfrac{L}{\lambda}=\dfrac{54}{18}=3.0\ \text{days}

Engineering Comment

At fixed throughput, reducing lead time means reducing WIP or variability. Releasing more work into the same queue will not shorten lead time.

Plausibility Check

At eighteen completions per day, fifty-four jobs represent exactly three days of work.

Exercise 2: WIP Cap for a Lead-Time Target

A team completes:

\lambda=22\ \text{jobs/day}

The target average lead time is:

W=2.5\ \text{days}

Find the WIP cap from Little’s Law.

Solution

Use:

L=\lambda W

Thus:

L=22(2.5)=55\ \text{jobs}

Engineering Comment

The WIP cap is only valid if the completion rate is stable. If capacity drops, the same WIP creates longer lead time.

Plausibility Check

About twenty-two jobs per day for two and a half days gives about fifty-five jobs in process.

Exercise 3: Throughput Needed for a WIP Limit

An operations desk has:

L=72\ \text{open jobs}

The lead-time target is:

W=4\ \text{days}

Find required completion rate.

Solution

Rearrange Little’s Law:

\lambda=\dfrac{L}{W}

So:

\lambda=\dfrac{72}{4}=18\ \text{jobs/day}

Engineering Comment

If the desk cannot complete eighteen jobs per day, the WIP target, staffing model or release rate must change.

Plausibility Check

Seventy-two jobs spread over four days requires eighteen completions per day.

Exercise 4: Crew Utilization Gate

A maintenance intake receives:

\lambda=18\ \text{jobs/day}

One technician completes:

r=4.5\ \text{jobs/day}

Utilization must stay at or below 85\%. Find technicians required.

Solution

Required technicians:

N\geq\dfrac{\lambda}{0.85r}

Substitute:

N\geq\dfrac{18}{0.85(4.5)}=4.71

Round up:

N=5

Engineering Comment

The reserve protects urgent work, troubleshooting, travel and handoff. Four technicians would be fully loaded on average.

Plausibility Check

Four technicians provide exactly eighteen jobs per day at 100\%, so five are needed for reserve.

Exercise 5: Effective Capacity after Availability Loss

A review cell has nominal capacity:

C_n=40\ \text{jobs/day}

Meeting and support losses remove:

15\%

Find effective capacity.

Solution

Effective capacity is:

C_e=C_n(1-0.15)

So:

C_e=40(0.85)=34\ \text{jobs/day}

Engineering Comment

Nominal capacity should not be used for release if predictable support work consumes part of the day.

Plausibility Check

Fifteen percent of forty is six, leaving thirty-four.

Exercise 6: Utilization after Demand Growth

Effective capacity is:

C_e=34\ \text{jobs/day}

Current demand is:

28\ \text{jobs/day}

A new program adds:

4\ \text{jobs/day}

Find utilization.

Solution

Total demand:

D=28+4=32\ \text{jobs/day}

Utilization:

U=\dfrac{32}{34}=0.941=94.1\%

Engineering Comment

The queue may be technically stable but too close to saturation. Service levels will be fragile.

Plausibility Check

Demand is only two jobs below capacity, so utilization above ninety percent is expected.

Exercise 7: M/M/1 Average Queue Wait

A specialist desk receives:

\lambda=7\ \text{jobs/day}

and can serve:

\mu=9\ \text{jobs/day}

Use:

W_q=\dfrac{\lambda}{\mu(\mu-\lambda)}

Solution

Substitute:

W_q=\dfrac{7}{9(9-7)}=\dfrac{7}{18}=0.389\ \text{days}

Engineering Comment

This is an average waiting-time screen. Priority classes and urgent response may need separate queues.

Plausibility Check

Utilization is about 78\%, so wait is noticeable but not unstable.

Exercise 8: Queue Tail Probability

For the same desk, estimate:

P(W_q>1)\approx\rho e^{-(\mu-\lambda)t}

with:

t=1\ \text{day}

Solution

Utilization:

\rho=\dfrac{7}{9}=0.778

Tail probability:

P(W_q>1)=0.778e^{-2}=0.105

So about:

10.5\%

Engineering Comment

Average wait may look acceptable while the one-day tail is too high for urgent jobs.

Plausibility Check

The service gap is only two jobs per day, so a nontrivial tail is plausible.

Exercise 9: Added Capacity Tail-Risk Reduction

Service capacity increases to:

\mu=10.5\ \text{jobs/day}

Arrival rate remains:

\lambda=7\ \text{jobs/day}

Estimate P(W_q>1).

Solution

Utilization:

\rho=\dfrac{7}{10.5}=0.667

Tail:

P(W_q>1)=0.667e^{-(10.5-7)(1)}=0.020

Engineering Comment

Small capacity additions can sharply reduce tail risk when the original queue was close to saturation.

Plausibility Check

The capacity gap grows from 2.0 to 3.5 jobs per day, so the tail should fall strongly.

Exercise 10: WIP Aging Rate

A queue has:

L=96\ \text{jobs}

and completion rate:

\lambda=24\ \text{jobs/day}

Find average age from Little’s Law.

Solution

Average age:

W=\dfrac{L}{\lambda}=\dfrac{96}{24}=4\ \text{days}

Engineering Comment

Average age hides aging tails. A service rule should also check jobs older than the escalation threshold.

Plausibility Check

At twenty-four completions per day, ninety-six open jobs represent four days.

Exercise 11: Bottleneck Capacity

A process has station rates:

StationRate
intake38 jobs/day
technical review31 jobs/day
release check35 jobs/day

Find system capacity.

Solution

The bottleneck is the minimum station rate:

C=\min(38,31,35)=31\ \text{jobs/day}

Engineering Comment

Improving non-bottleneck stations will not raise system throughput unless it changes the governing constraint.

Plausibility Check

The technical review station is the slowest, so it controls.

Exercise 12: Reserve Capacity for Urgent Jobs

A service cell has effective capacity:

C=50\ \text{jobs/day}

Routine demand is:

D_r=39\ \text{jobs/day}

Urgent reserve must be at least:

R_{min}=8\ \text{jobs/day}

Check reserve.

Solution

Available reserve is:

R=C-D_r=50-39=11\ \text{jobs/day}

Since:

11\geq8

the reserve passes.

Engineering Comment

Reserve should be protected. Filling it with routine work improves utilization but weakens urgent response.

Plausibility Check

Routine demand uses most capacity but leaves eleven jobs, more than the required eight.

Exercise 13: Priority Split Capacity

Urgent demand is:

D_u=7\ \text{jobs/day}

Protected urgent capacity is:

C_u=9\ \text{jobs/day}

Find urgent utilization.

Solution

Urgent utilization:

U_u=\dfrac{D_u}{C_u}=\dfrac{7}{9}=0.778

Engineering Comment

Protected urgent capacity can pass even when the total desk is busy. Mixing priority classes would hide this control.

Plausibility Check

Seven out of nine is just under eighty percent.

Exercise 14: Capacity from OEE

A work cell has nominal output:

R_n=60\ \text{jobs/shift}

Measured OEE is:

OEE=0.72

Find effective output.

Solution

Effective output:

R_e=R_n OEE=60(0.72)=43.2\ \text{jobs/shift}

Round down for a release screen:

R_e=43\ \text{jobs/shift}

Engineering Comment

OEE turns nominal capacity into usable planning capacity, but the losses should be understood before adding demand.

Plausibility Check

Seventy-two percent of sixty is a little above forty-three.

Exercise 15: Average Wait Pass, Tail Wait Fail

A queue has:

W_q=0.32\ \text{days}

against an average-wait limit of:

0.50\ \text{days}

The one-day tail probability is:

P(W_q>1)=0.08

against a limit of:

0.05

Check service release.

Solution

Average wait passes:

0.32<0.50

Tail risk fails:

0.08>0.05

The queue is not releasable.

Engineering Comment

Tail risk often drives user experience and urgent work. Average performance is not enough.

Plausibility Check

One metric passes and one fails. A hard tail-risk rule blocks release.

Exercise 16: Takt and Queue Build-Up

Demand requires one job every:

T_d=12\ \text{min}

The bottleneck cycle time is:

T_c=14\ \text{min/job}

Find backlog growth over an 8 hour shift.

Solution

Demand rate:

r_d=\dfrac{60}{12}=5.0\ \text{jobs/h}

Capacity rate:

r_c=\dfrac{60}{14}=4.29\ \text{jobs/h}

Growth rate:

g=5.0-4.29=0.71\ \text{jobs/h}

Over eight hours:

B=0.71(8)=5.7\ \text{jobs}

Engineering Comment

Small cycle-time gaps create visible WIP over a shift. The response should target the bottleneck, not downstream expediting.

Plausibility Check

The system falls short by less than one job per hour, so about six jobs of backlog over a shift is plausible.

Exercise 17: Service Validation Trial

A queue improvement trial runs for five days with completed jobs:

42,\ 45,\ 44,\ 41,\ 46

The release rule requires average completion at least 43 jobs/day and no day below 40. Check release.

Solution

Average:

\bar{x}=\dfrac{42+45+44+41+46}{5}=\dfrac{218}{5}=43.6

Minimum:

x_{min}=41

Both gates pass:

43.6\geq43,\quad 41\geq40

Engineering Comment

The trial should still state demand mix, staffing, rework and whether urgent work was included.

Plausibility Check

All daily results are near the target and none are below forty.

Exercise 18: Queue Release Gate

A service queue has:

GateRequirementCurrent result
utilizationat most 85\%80\%
average waitat most 0.5 days0.389 days
one-day tailbelow 5\%10.5\%
urgent reserveat least 8 jobs/day11 jobs/day

Decide whether to release.

Solution

Utilization, average wait and urgent reserve pass:

80\%\leq85\%,\quad 0.389<0.5,\quad 11\geq8

Tail risk fails:

10.5\%>5\%

The queue is not releasable.

Engineering Comment

The service-level tail is a hard gate. The likely response is added capacity, priority splitting or demand throttling.

Plausibility Check

Most metrics pass, but the explicit tail-risk threshold fails.

Validation Package Checklist

A strong queue and capacity solution should check:

  • whether arrival and service boundaries match the work actually controlled;
  • whether priority classes are separated when their service rules differ;
  • whether WIP, throughput and lead time use consistent units;
  • whether effective capacity, not nominal capacity, controls release;
  • whether average wait and tail wait are both checked;
  • whether high utilization is treated as queue risk, not productivity proof;
  • whether added capacity has the right skill and authority;
  • whether validation trials include representative demand and rework.

Common Release Mistakes

Common mistakes include applying Little’s Law to mixed queues, using nominal capacity after known losses, accepting high utilization as efficient when tail wait fails, mixing urgent and routine jobs in one average, improving a non-bottleneck station, lowering WIP without protecting throughput, ignoring arrival clustering, and releasing a queue because average wait passes while the tail-risk gate fails.

REF

See also