task-queue-proof/README.md

Unweighted Average Completion Time Is Not a Fair Metric for Task Scheduling

A mathematical proof that unweighted average task completion time is a biased statistic that incentivizes cherry-picking easy work, and that any scheduling advantage it appears to reveal is an artifact of the metric — not a reflection of genuine throughput or service quality.

---

1. Definitions

Let there be n tasks with processing times p_1, p_2, \ldots, p_n.

A schedule \sigma is a permutation of \{1, 2, \ldots, n\} assigning tasks to execution order on a single executor.

The completion time of task \sigma(k) under schedule \sigma is:

C_{\sigma(k)} = \sum_{j=1}^{k} p_{\sigma(j)}

The unweighted mean completion time is:

\bar{C}(\sigma) = \frac{1}{n} \sum_{k=1}^{n} C_{\sigma(k)}

The work-weighted mean completion time is:

\bar{C}_w(\sigma) = \frac{\sum_{k=1}^{n} p_{\sigma(k)} \cdot C_{\sigma(k)}}{\sum_{k=1}^{n} p_{\sigma(k)}}

---

2. SPT Is Optimal for the Unweighted Statistic

Theorem 1. The schedule that minimizes \bar{C}(\sigma) is Shortest Processing Time first (SPT): sort tasks so that p_{\sigma(1)} \le p_{\sigma(2)} \le \cdots \le p_{\sigma(n)}.

Proof (exchange argument).

Consider any schedule \sigma in which two adjacent tasks i, j satisfy p_i > p_j with task i scheduled immediately before task j. Let t be the start time of task i.

	Task i finishes	Task j finishes	Sum
Before swap (i then j)	t + p_i	t + p_i + p_j	2t + 2p_i + p_j
After swap (j then i)	t + p_j	t + p_j + p_i	2t + p_i + 2p_j

The change in the sum of completion times is:

(2p_i + p_j) - (p_i + 2p_j) = p_i - p_j > 0

Every swap of a longer-before-shorter adjacent pair strictly reduces the total. Any non-SPT schedule contains such a pair. Repeated swaps converge to SPT. Therefore SPT uniquely minimizes \bar{C}(\sigma). \blacksquare

---

3. The Work-Weighted Statistic Is Schedule-Invariant

Theorem 2. The work-weighted mean completion time \bar{C}_w(\sigma) is the same for every schedule \sigma.

Proof.

Expand the numerator:

\sum_{k=1}^{n} p_{\sigma(k)} \cdot C_{\sigma(k)} = \sum_{k=1}^{n} p_{\sigma(k)} \sum_{j=1}^{k} p_{\sigma(j)}

Reindex by letting a = \sigma(k) and b = \sigma(j). The double sum counts every ordered pair (a, b) where b is scheduled no later than a:

= \sum_{\substack{a, b \\ b \preceq_\sigma a}} p_a \, p_b

For any pair (a, b) with a \ne b, exactly one of \{b \preceq_\sigma a\} or \{a \prec_\sigma b\} holds. The diagonal terms (a = b) contribute p_a^2 regardless of order. Therefore:

\sum_{\substack{a, b \\ b \preceq_\sigma a}} p_a \, p_b = \sum_{a} p_a^2 + \sum_{\substack{a \ne b \\ b \prec_\sigma a}} p_a \, p_b

Now consider the complementary sum:

\sum_{\substack{a \ne b \\ a \prec_\sigma b}} p_a \, p_b

Together the two off-diagonal sums cover all unordered pairs \{a, b\}:

\sum_{\substack{a \ne b \\ b \prec_\sigma a}} p_a \, p_b + \sum_{\substack{a \ne b \\ a \prec_\sigma b}} p_a \, p_b = \sum_{a \ne b} p_a \, p_b

The right-hand side is schedule-independent. By symmetry of p_a p_b, both off-diagonal sums are equal:

\sum_{\substack{a \ne b \\ b \prec_\sigma a}} p_a \, p_b = \frac{1}{2} \sum_{a \ne b} p_a \, p_b

Therefore:

\sum_{k=1}^{n} p_{\sigma(k)} \cdot C_{\sigma(k)} = \sum_a p_a^2 + \frac{1}{2} \sum_{a \ne b} p_a \, p_b = \frac{1}{2}\left(\sum_a p_a\right)^2 + \frac{1}{2}\sum_a p_a^2

This expression contains no reference to \sigma. Since the denominator \sum p_a is also schedule-independent:

\bar{C}_w(\sigma) = \frac{\frac{1}{2}\left(\sum p_a\right)^2 + \frac{1}{2}\sum p_a^2}{\sum p_a}

is constant across all schedules. \blacksquare

---

4. Concrete Example

Two tasks: A with p_A = 1 hour, B with p_B = 10 hours.

SPT order (A first)

Task	Completion time
A	1
B	11

• Unweighted mean: (1 + 11) / 2 = 6.0
• Work-weighted mean: (1 \times 1 + 10 \times 11) / 11 = 111/11 \approx 10.09

Reverse order (B first)

Task	Completion time
B	10
A	11

• Unweighted mean: (10 + 11) / 2 = 10.5
• Work-weighted mean: (10 \times 10 + 1 \times 11) / 11 = 111/11 \approx 10.09

SPT appears 4.5 hours better on the unweighted metric but provides zero improvement on the work-weighted metric. The apparent advantage exists only because the unweighted statistic lets a 1-hour task "vote" equally with a 10-hour task.

---

5. Connection to Little's Law

Little's Law states L = \lambda W, where L is the average number of tasks in the system, \lambda is the arrival rate, and W is the average time a task spends in the system.

For a stable system, L and \lambda are determined by arrival and service rates — not by scheduling policy. Therefore W = L / \lambda is schedule-invariant when measured correctly (i.e., weighted by the quantity being served).

SPT appears to violate this only because the unweighted statistic counts completions rather than work, systematically underweighting large tasks.

---

6. Consequences

Theorem 3 (Metric Bias). Any scheduling policy that minimizes unweighted mean completion time necessarily maximizes the completion time of the largest task relative to other schedules.

Proof. SPT places the largest task last. Its completion time equals the total processing time \sum p_i, which is the maximum possible completion time for any individual task. Meanwhile, FIFO or any non-SPT order would allow the large task to finish earlier. \blacksquare

This creates a starvation incentive: rational agents optimizing the unweighted statistic will indefinitely defer large tasks in favor of small ones.

Real-world manifestations

Domain	Gameable metric	Perverse outcome
Support desks	Tickets closed / day	Complex issues ignored
Sprint planning	Story count velocity	Work split into trivial pieces
Emergency rooms	Average wait time	Critical patients deprioritized
Academic publishing	Papers per year	Incremental work favored over deep research

---

7. Impact on Client Satisfaction and Team Productivity

The preceding theorems are not merely abstract. They have direct, provable consequences for client satisfaction and team productivity when a team adopts unweighted mean completion time as its performance metric.

7.1 Defining Client Satisfaction: The Slowdown Ratio

A client submitting a task of size p_i has an expectation anchored to that size. The natural measure of their experience is the slowdown ratio:

S_i = \frac{C_i}{p_i}

This is the factor by which the client's wait exceeds the task's inherent processing time. A slowdown of 1 means no queuing delay at all. A slowdown of 10 means the client waited 10x longer than the work itself required.

Client satisfaction is inversely related to slowdown: a client who waits 2x their task size is more satisfied than one who waits 20x, regardless of the absolute times involved.

Theorem 4 (SPT Maximizes Slowdown Inequality). Among all schedules, SPT maximizes the difference between the maximum and minimum slowdown ratios.

Proof.

Under any schedule \sigma, the task in position k has completion time C_{\sigma(k)} = \sum_{j=1}^{k} p_{\sigma(j)} and slowdown:

S_{\sigma(k)} = \frac{\sum_{j=1}^{k} p_{\sigma(j)}}{p_{\sigma(k)}}

Under SPT, the last task (position n) is the largest, p_{\max}, with:

S_n^{\text{SPT}} = \frac{\sum_{i=1}^{n} p_i}{p_{\max}}

The first task is the smallest, p_{\min}, with:

S_1^{\text{SPT}} = \frac{p_{\min}}{p_{\min}} = 1

The slowdown range under SPT is:

\Delta S^{\text{SPT}} = \frac{\sum p_i}{p_{\max}} - 1

Now consider the reverse schedule (Longest Processing Time first, LPT). The largest task goes first with slowdown 1. The smallest task goes last:

S_n^{\text{LPT}} = \frac{\sum p_i}{p_{\min}}, \quad S_1^{\text{LPT}} = 1

While LPT has a larger maximum slowdown, its minimum is also 1. The critical difference is which clients suffer. Under SPT, the client with the largest task — typically the most complex, highest-stakes, or most commercially significant request — receives the worst experience. Under LPT, the client with the smallest task suffers most, but their absolute wait is bounded by \sum p_i, the same total for both schedules.

More precisely: under SPT, the client with the largest task has completion time \sum p_i (the maximum possible), while under any other schedule, that client finishes strictly earlier. SPT uniquely minimizes the satisfaction of the highest-effort client. \blacksquare

Corollary 4.1. A team optimizing unweighted mean completion time will systematically deliver the worst experience to clients with the most complex needs.

This is not a side effect — it is the mechanism by which the metric improves. The only way to lower the unweighted average is to complete more small tasks early, which necessarily means completing large tasks later. The metric improves because high-effort clients are deprioritized.

7.2 The Fairness Benchmark: Proportional Slowdown

A fair schedule is one where all clients experience equal slowdown:

S_i = S_j \quad \forall \, i, j

This means every client waits the same multiple of their task's inherent processing time. A 1-hour task might wait 2 hours; a 10-hour task waits 20 hours. The ratio is the same.

Theorem 5 (Proportional Scheduling). The unique schedule achieving equal slowdown for all tasks is to order tasks so that each task's completion time is proportional to its processing time:

C_i = S \cdot p_i \quad \text{where } S = \frac{\sum p_i}{\sum p_i} \cdot \frac{\sum_{j} p_j}{p_i} \text{ ... }

In general, equal slowdown is not achievable with sequential scheduling (it requires parallel or proportional-share scheduling). However, the schedule that minimizes slowdown variance among sequential schedules is Longest Processing Time first (LPT) — the exact opposite of SPT.

Proof sketch. Under LPT, large tasks go first and receive slowdown close to 1. Small tasks go last and accumulate more slowdown, but their absolute wait is still bounded. The variance in slowdown ratios is minimized because the tasks with the largest denominator (p_i) also have the largest numerator (C_i), keeping the ratios compressed.

Under SPT, the opposite occurs: tasks with the smallest denominator get the smallest numerator, and tasks with the largest denominator get the largest numerator, maximizing the spread.

Formally, for any two schedules \sigma_1 (SPT) and \sigma_2 (LPT):

\text{Var}(S^{\text{SPT}}) \ge \text{Var}(S^{\text{LPT}})

with equality only when all p_i are equal. \blacksquare

7.3 Productivity Is Not Improved

Theorem 6 (Throughput Invariance). Total work completed over any time horizon T is identical under all scheduling policies.

Proof. The executor processes work at a fixed rate. Over time T, the total work completed is:

W(T) = \sum_{\{i : C_i \le T\}} p_i + \text{(partial progress on current task)}

In the non-preemptive case (tasks run to completion once started), W(T) may vary slightly at the boundary depending on which task is in progress at time T. However, over any horizon T \ge \sum p_i (i.e., long enough to complete all tasks), the total work done is exactly \sum p_i regardless of order.

For the steady-state case with ongoing arrivals, the long-run throughput is determined by the service rate \mu and is completely independent of scheduling:

\lim_{T \to \infty} \frac{W(T)}{T} = \mu \quad \text{for all schedules } \sigma

\blacksquare

Corollary 6.1. A team that switches from any scheduling policy to SPT will observe an improvement in unweighted mean completion time with zero change in actual throughput.

The metric improves. The output does not.

7.4 The Compound Effect: Satisfaction Down, Productivity Flat

Combining Theorems 4, 5, and 6:

Measure	Effect of optimizing unweighted mean
Throughput (work/time)	No change (Theorem 6)
Client satisfaction for small tasks	Improves
Client satisfaction for large tasks	Worsens maximally (Theorem 4)
Satisfaction equity across clients	Worsens maximally (Theorem 5)
Overall perceived quality of service	Net negative (see below)

The net effect on perceived quality is negative because:

1. Loss aversion is asymmetric. A client whose 100-hour task is deprioritized to last experiences a large, salient negative. A client whose 1-hour task moves from position 5 to position 1 experiences a small, often unnoticed positive. The absolute dissatisfaction created exceeds the absolute satisfaction gained.

2. High-effort tasks correlate with high-value clients. Large tasks are disproportionately likely to come from major clients, complex contracts, or critical business needs. Systematically giving these clients the worst experience is anti-correlated with revenue and retention.

3. Starvation compounds. In a continuous system (Theorem 3), large tasks are not merely delayed — they may be indefinitely deferred as new small tasks keep arriving. The affected client's satisfaction does not merely decrease; it collapses entirely.

Theorem 7 (The Core Result). For a team processing tasks of non-uniform size, adopting unweighted mean completion time as a performance metric:

(a) Provides zero productivity gain (Theorem 6), while (b) Maximally degrading satisfaction for clients with the largest tasks (Theorem 4), and (c) Maximally increasing inequality in service quality across clients (Theorem 5).

This is not a tradeoff — there is no compensating benefit on the productivity side. The metric creates a pure transfer of service quality from high-effort clients to low-effort clients, with no net work gained.

A team using unweighted mean completion time as its performance metric will, under rational optimization, simultaneously fail to improve productivity and systematically degrade the experience of its most demanding clients. \blacksquare

---

8. When Unweighted Mean Completion Time Is Valid

For completeness: the unweighted metric is appropriate if and only if all tasks are approximately equal in size (p_i \approx p_j for all i, j). In this case, the work-weighted and unweighted statistics converge, SPT and FIFO produce similar schedules, and slowdown ratios are naturally equal.

The pathology arises specifically from variance in task size. The greater the variance, the greater the distortion, and the more damage the metric causes when optimized.

---

9. Complete Breakdown Under Priority Classification

The preceding sections proved that unweighted mean completion time is biased when tasks vary in size. We now show that introducing a priority system — as virtually all real teams use — causes the metric to become not merely biased but actively adversarial to the organization's stated goals.

9.1 Extended Model: Tasks With Priority

Let each task i have processing time p_i and a priority class q_i \in \{1, 2, 3, 4\} where 1 is the highest priority (critical) and 4 is the lowest (cosmetic/enhancement). Assign priority weights:

w(q) = \begin{cases} 8 & q = 1 \text{ (Critical)} \\ 4 & q = 2 \text{ (High)} \\ 2 & q = 3 \text{ (Medium)} \\ 1 & q = 4 \text{ (Low)} \end{cases}

The specific weights are illustrative; the results hold for any strictly decreasing weight function. The key property is that priority is assigned by business impact, not by task size.

9.2 The Metric Contradicts the Priority System

Theorem 8 (Priority-Size Inversion). When priority is independent of task size, the schedule that minimizes unweighted mean completion time (SPT) will, in expectation, complete low-priority tasks before high-priority tasks of greater size.

Proof.

SPT orders tasks by p_i ascending, regardless of q_i. Consider two tasks:

• Task A: p_A = 40 hours, q_A = 1 (Critical — e.g., server outage)
• Task B: p_B = 0.5 hours, q_B = 4 (Low — e.g., cosmetic UI fix)

SPT schedules B before A. The unweighted mean completion time for this pair:

\bar{C}^{\text{SPT}} = \frac{0.5 + 40.5}{2} = 20.5

The priority-respecting order (A before B):

\bar{C}^{\text{priority}} = \frac{40 + 40.5}{2} = 40.25

The metric declares SPT nearly twice as good — despite completing a cosmetic fix while a server outage burns for an additional 0.5 hours.

In general, for n tasks where priority q_i is statistically independent of processing time p_i (a reasonable assumption, since priority reflects business impact while processing time reflects technical complexity):

\text{Corr}(p_i, q_i) \approx 0

SPT's ordering is determined entirely by p_i. The expected position of a task in the SPT schedule has zero correlation with its priority. A Critical task is equally likely to be scheduled first or last.

More precisely: the expected fraction of Critical tasks in the bottom half of the SPT schedule equals the fraction of Critical tasks whose processing time exceeds the median. In practice, Critical tasks (outages, security incidents, data loss) often require more work, so this fraction exceeds 50%. The metric is not merely uncorrelated with priority — it is plausibly anti-correlated. \blacksquare

9.3 Dimensionality Collapse

The unweighted mean completion time reduces a three-dimensional task (p_i, q_i, C_i) to a one-dimensional signal (C_i), then averages that signal uniformly. This discards two of the three dimensions:

1. Priority (q_i) is completely ignored. A critical task and a cosmetic task contribute identically to the mean.
2. Size (p_i) is implicitly inverted. Small tasks are rewarded with early completion, large tasks are punished — regardless of their importance.

Theorem 9 (Information Destruction). Let I(\sigma) be the mutual information between the schedule's implicit priority ranking (position in schedule) and the actual priority assignment q_i. For SPT:

I(\sigma_{\text{SPT}}) = 0 \quad \text{when } p_i \perp q_i

Proof. SPT assigns positions based solely on p_i. When p_i and q_i are independent, knowing a task's position in the SPT schedule provides zero information about its priority. The schedule is statistically independent of the priority system.

Contrast this with a priority-first schedule, where I > 0 by construction. \blacksquare

Corollary 9.1. A team that optimizes unweighted mean completion time is operating a scheduling system that carries zero information about its own priority classification. The priority field in their ticketing system is, with respect to execution order, decorative.

9.4 Quantifying the Damage: Priority-Weighted Delay Cost

Define the priority-weighted delay cost of a schedule:

D(\sigma) = \sum_{i=1}^{n} w(q_i) \cdot C_i

This measures the total business-impact-weighted time spent waiting.

Theorem 10 (SPT Maximizes Priority-Weighted Delay in the Worst Case). Among all schedules, SPT produces the highest priority-weighted delay cost when high-priority tasks are large and low-priority tasks are small.

Proof. Consider the worst case: all Critical (q = 1) tasks have processing time p_H and all Low (q = 4) tasks have processing time p_L, with p_H > p_L. Let there be n_H critical tasks and n_L low tasks, n = n_H + n_L.

SPT places all n_L low tasks first, then all n_H critical tasks.

The priority-weighted delay cost under SPT:

D_{\text{SPT}} = w(4) \sum_{k=1}^{n_L} k \cdot p_L + w(1) \sum_{k=1}^{n_H} (n_L \cdot p_L + k \cdot p_H) = 1 \cdot \frac{n_L(n_L+1)}{2} p_L + 8 \left( n_H \cdot n_L \cdot p_L + \frac{n_H(n_H+1)}{2} p_H \right)

Under priority-first scheduling (all Critical tasks first):

D_{\text{priority}} = w(1) \sum_{k=1}^{n_H} k \cdot p_H + w(4) \sum_{k=1}^{n_L} (n_H \cdot p_H + k \cdot p_L) = 8 \cdot \frac{n_H(n_H+1)}{2} p_H + 1 \cdot \left( n_L \cdot n_H \cdot p_H + \frac{n_L(n_L+1)}{2} p_L \right)

The difference D_{\text{SPT}} - D_{\text{priority}} simplifies. The critical cross-terms are:

• SPT charges 8 \cdot n_H \cdot n_L \cdot p_L for Critical tasks waiting behind Low tasks.
• Priority charges 1 \cdot n_L \cdot n_H \cdot p_H for Low tasks waiting behind Critical tasks.

Since w(1) = 8 and w(4) = 1:

D_{\text{SPT}} - D_{\text{priority}} = n_H \cdot n_L \cdot (8 p_L - p_H) + n_H \cdot n_L \cdot (p_H - 8 p_L)

Wait — let me compute this more carefully. The cross-term in SPT is the cost of all Critical tasks being delayed by all Low tasks:

\Delta_{\text{cross}} = w(1) \cdot n_H \cdot n_L \cdot p_L - w(4) \cdot n_L \cdot n_H \cdot p_H = n_H \cdot n_L \cdot (8 p_L - p_H)

When p_H > 8 p_L, the priority-first schedule wins on both the priority-weighted metric and unweighted metric — SPT is Pareto-dominated. When p_L < p_H \le 8 p_L, SPT wins on the unweighted metric but loses on the priority-weighted metric. In either case:

The unweighted metric recommends the schedule that inflicts the most business-impact-weighted delay whenever large tasks are high-priority. \blacksquare

---

10. A Proposed Solution: Priority-Weighted Completion Score

10.1 The Metric

Replace unweighted mean completion time with the Priority-Weighted Completion Score (PWCS):

\text{PWCS}(\sigma) = \frac{\sum_{i=1}^{n} w(q_i) \cdot \frac{C_i}{p_i}}{\sum_{i=1}^{n} w(q_i)}

This is the priority-weighted mean slowdown ratio. It measures:

• How long each task waited relative to its size (the slowdown C_i / p_i), weighted by
• How much that task mattered (the priority weight w(q_i)).

Lower is better. A PWCS of 1.0 means every task was completed instantly with zero queuing delay. A PWCS of 3.0 means the average task waited 3x its processing time, weighted by importance.

10.2 Properties of PWCS

Property 1: Priority-respecting. PWCS penalizes delays to high-priority tasks more heavily than low-priority tasks. A 2-hour delay to a Critical task costs 8x more than the same delay to a Low task.

Property 2: Size-fair. By using the slowdown ratio C_i / p_i rather than raw completion time C_i, the metric does not inherently penalize large tasks for being large. A 40-hour task that waits 80 hours contributes the same slowdown (2.0) as a 1-hour task that waits 2 hours.

Property 3: Not gameable by SPT. Because the metric weights by priority and normalizes by task size, reordering tasks by processing time does not systematically improve the score. The optimal strategy is to minimize slowdown for high-priority tasks — i.e., to actually respect the priority system.

Property 4: Reduces to unweighted mean when tasks are uniform. If all tasks have equal priority and equal size, PWCS equals the unweighted mean completion time divided by the common task size. It is a strict generalization.

10.3 Optimal Policy for PWCS

Theorem 11. The schedule minimizing PWCS processes tasks in order of decreasing w(q_i) / p_i — highest priority first, breaking ties by shortest processing time within the same priority class.

Proof (exchange argument, as in Theorem 1).

Consider adjacent tasks i, j with i before j. Each task's contribution to the PWCS numerator depends on the completion times of both. Swapping i and j:

The change in the weighted slowdown sum is proportional to:

w(q_i) \cdot \frac{p_j}{p_i} - w(q_j) \cdot \frac{p_i}{p_j}

The swap improves PWCS when this quantity is positive, i.e., when:

\frac{w(q_i)}{p_i^2} > \frac{w(q_j)}{p_j^2}

Hmm — this doesn't simplify as cleanly due to the ratio structure. Let us instead consider the more practical priority-weighted completion time:

\text{PWCT}(\sigma) = \frac{\sum_{i=1}^{n} w(q_i) \cdot C_i}{\sum_{i=1}^{n} w(q_i)}

For PWCT, the exchange argument gives: swap improves the score when w(q_j) \cdot p_i > w(q_i) \cdot p_j, i.e., when w(q_j)/p_j > w(q_i)/p_i but j is scheduled after i. The optimal order is therefore decreasing w(q_i)/p_i, which is the Weighted Shortest Job First (WSJF) rule:

\text{Schedule by: } \frac{w(q_i)}{p_i} \text{ descending}

This means: within a priority class, do short tasks first; across priority classes, a Critical 8-hour task (w/p = 8/8 = 1.0) ties with a Low 1-hour task (w/p = 1/1 = 1.0) — but a Critical 4-hour task (w/p = 8/4 = 2.0) beats both. \blacksquare

10.4 Applied Example: IT Service Desk

Consider an IT team with the following ticket queue on a Monday morning:

Ticket	Priority	Type	Est. Hours
T1	P1 (Critical)	Email server down	6
T2	P2 (High)	VPN failing for remote team	4
T3	P3 (Medium)	New employee laptop setup	2
T4	P4 (Low)	Update desktop wallpaper policy	0.5
T5	P3 (Medium)	Install software license	1
T6	P1 (Critical)	Database backup failing	3
T7	P2 (High)	Printer fleet offline	2
T8	P4 (Low)	Archive old shared drive folder	0.25

SPT order (optimizing unweighted mean): T8, T4, T5, T3, T7, T6, T2, T1

Position	Ticket	Priority	Hours	Completion	Slowdown
1	T8 (archive folder)	P4 Low	0.25	0.25	1.0
2	T4 (wallpaper)	P4 Low	0.5	0.75	1.5
3	T5 (software)	P3 Med	1	1.75	1.75
4	T3 (laptop)	P3 Med	2	3.75	1.875
5	T7 (printers)	P2 High	2	5.75	2.875
6	T6 (backups)	P1 Crit	3	8.75	2.917
7	T2 (VPN)	P2 High	4	12.75	3.1875
8	T1 (email)	P1 Crit	6	18.75	3.125

• Unweighted mean completion: (0.25 + 0.75 + 1.75 + 3.75 + 5.75 + 8.75 + 12.75 + 18.75) / 8 = 6.5625 hours
• PWCT: (1 \cdot 0.25 + 1 \cdot 0.75 + 2 \cdot 1.75 + 2 \cdot 3.75 + 4 \cdot 5.75 + 8 \cdot 8.75 + 4 \cdot 12.75 + 8 \cdot 18.75) / 30 = 9.225 hours
• Email server is down for 18.75 hours. Database backups fail for 8.75 hours.

WSJF order (optimizing PWCT by w(q)/p descending):

Ticket	Priority	Hours	w/p
T6	P1 Crit	3	8/3 = 2.667
T8	P4 Low	0.25	1/0.25 = 4.0
T5	P3 Med	1	2/1 = 2.0
T4	P4 Low	0.5	1/0.5 = 2.0
T1	P1 Crit	6	8/6 = 1.333
T7	P2 High	2	4/2 = 2.0
T2	P2 High	4	4/4 = 1.0
T3	P3 Med	2	2/2 = 1.0

Wait — T8 has w/p = 4.0, the highest. That places a Low-priority task first, which feels wrong. This reveals an important practical point: pure WSJF can still be gamed by tiny tasks because their small p inflates the ratio. In practice, this is mitigated by enforcing strict priority class ordering and only applying WSJF within priority classes.

Practical WSJF (priority-class-first, then w/p within class):

Position	Ticket	Priority	Hours	Completion
1	T6 (backups)	P1 Crit	3	3
2	T1 (email)	P1 Crit	6	9
3	T7 (printers)	P2 High	2	11
4	T2 (VPN)	P2 High	4	15
5	T5 (software)	P3 Med	1	16
6	T3 (laptop)	P3 Med	2	18
7	T8 (archive)	P4 Low	0.25	18.25
8	T4 (wallpaper)	P4 Low	0.5	18.75

• Unweighted mean completion: (3 + 9 + 11 + 15 + 16 + 18 + 18.25 + 18.75) / 8 = 13.625 hours
• PWCT: (8 \cdot 3 + 8 \cdot 9 + 4 \cdot 11 + 4 \cdot 15 + 2 \cdot 16 + 2 \cdot 18 + 1 \cdot 18.25 + 1 \cdot 18.75) / 30 = 6.633 hours
• Email server restored in 9 hours. Backups fixed in 3 hours.

Comparison

Metric	SPT	Practical WSJF	Winner
Unweighted mean completion	6.5625 hrs	13.625 hrs	SPT
Priority-weighted completion (PWCT)	9.225 hrs	6.633 hrs	WSJF
Time to fix email server	18.75 hrs	9 hrs	WSJF
Time to fix database backups	8.75 hrs	3 hrs	WSJF
Time to fix printers	5.75 hrs	11 hrs	SPT
Time to update wallpaper	0.75 hrs	18.75 hrs	SPT

SPT wins the unweighted metric by completing wallpaper policies and folder archives first. WSJF wins every metric that accounts for business impact.

The unweighted metric would report that the SPT team is more than twice as efficient (6.56 vs 13.63), when in reality the SPT team left a critical email outage burning for nearly an entire business day while updating desktop wallpaper.

10.5 Recommended Metric Suite

No single metric suffices. A complete measurement system for a priority-based team should track:

Metric	What it measures	Formula
PWCT	Business-impact-weighted responsiveness	\sum w(q_i) C_i / \sum w(q_i)
P1 mean time to resolution	Critical incident response	\bar{C} filtered to q = 1
Throughput	Raw work capacity	Work-hours completed / calendar time
Aging violations	Starvation prevention	Count of tasks exceeding SLA by priority
Slowdown by priority class	Equity across task types	\bar{S} grouped by q

---

11. Devil's Advocate: The Case for Unweighted Mean Completion Time

Intellectual honesty requires acknowledging where the preceding argument has limits. The following are genuine counterarguments — not strawmen.

11.1 Simplicity Has Real Value

Argument. The unweighted mean is trivially computable: sum the completion times, divide by the count. It requires no priority weights, no task-size estimates, no calibration. Every alternative proposed in Section 10 requires estimating p_i (task size) before the task is complete — and these estimates are notoriously unreliable.

Assessment: This is true. PWCS and PWCT require inputs (priority weights, size estimates) that introduce their own sources of error. If size estimates are systematically wrong — and in software engineering they often are, with large tasks underestimated and small tasks overestimated — then the weighted metric inherits that noise.

However, the unweighted metric does not avoid this problem — it hides it by implicitly setting all weights to 1 and all sizes to 1. That is not "making no assumptions"; it is making the specific assumption that all tasks are equally important and equally sized, which is demonstrably false in any real system. A known-imprecise estimate of task size is still more informative than the implicit assumption that all sizes are equal.

11.2 Minimizing the Number of People Waiting

Argument. If each task represents one client, then unweighted mean completion time minimizes the total person-hours spent waiting. SPT is optimal for this because completing short tasks first "frees" the most people from the queue earliest.

Assessment: This is mathematically correct. The sum \sum C_i counts total person-time in the system. SPT genuinely minimizes this quantity. If you run a DMV and every person's time is equally valuable regardless of why they're there, SPT is the right policy.

The argument breaks down when:

1. Tasks are not 1:1 with clients. In IT, one client may submit tasks of varying size. Across a relationship, SPT systematically fast-tracks their easy requests and starves their hard ones — which is not perceived as good service.

2. Waiting cost is not uniform. A person waiting for a server outage to be fixed is not equivalent to a person waiting for a wallpaper change. The cost of waiting is proportional to the impact of the unresolved task, which is what priority encodes.

3. The metric is applied to teams, not DMVs. When a team's performance is measured by unweighted mean, the rational response is to cherry-pick — which is individually rational but collectively destructive.

11.3 SPT as a Triage Heuristic

Argument. In high-volume systems where task sizes cluster tightly (e.g., a call center where most calls are 3-7 minutes), SPT approximates FIFO and the unweighted mean approximates the weighted mean. The pathologies described in this paper only manifest when task sizes span orders of magnitude.

Assessment: This is correct. As shown in Section 8, when task sizes are approximately uniform, all scheduling policies converge and all metrics agree. The coefficient of variation of task size, CV = \sigma_p / \bar{p}, determines the severity of the distortion:

CV	Task size distribution	Metric distortion
< 0.3	Tight (call center)	Negligible
0.3 - 1.0	Moderate (mixed IT)	Moderate
> 1.0	Wide (typical IT queue)	Severe

For a typical IT service desk, task sizes range from 15 minutes (password reset) to 40+ hours (infrastructure migration), giving CV > 2. The distortion is not a theoretical edge case — it is the default condition.

11.4 Gaming Requires Malice

Argument. The theorems show that the metric can be gamed, not that it will be gamed. A well-intentioned team might use the unweighted mean as a rough health indicator without actively optimizing for it, avoiding the pathologies described.

Assessment: This is the strongest counterargument. If the metric is used purely for monitoring — "are we completing things at a reasonable pace?" — and not for performance evaluation, rewards, or scheduling decisions, then the gaming incentive is absent and the metric is relatively harmless.

However, this argument requires the metric to remain purely informational and never influence behavior. In practice, any metric that is reported to management, tied to OKRs, or used in sprint retrospectives will influence behavior — this is Goodhart's Law, and it applies to well-intentioned teams as reliably as to cynical ones. The team need not be gaming the metric consciously; it is sufficient that completing three easy tickets "feels productive" while staring at one hard ticket does not. The metric validates the feeling, and the drift happens organically.

11.5 Summary: When the Unweighted Mean Is Defensible

The unweighted mean completion time is a defensible metric only when all four conditions hold simultaneously:

1. Task sizes are approximately uniform (CV < 0.3)
2. There is no priority differentiation (all tasks are equally important)
3. Each task represents exactly one client
4. The metric is not used to evaluate, reward, or direct team behavior

In a system satisfying all four conditions — such as a simple FIFO queue with uniform jobs and no priority system — the unweighted mean is adequate, and its simplicity is a genuine advantage.

In any system that violates even one of these conditions — which includes virtually every IT service desk, development team, and support organization — the metric produces the distortions proven in Sections 2-9.

The honest conclusion is not that the unweighted mean is always wrong. It is that the conditions under which it is right are narrow, easily identified, and rarely met in the systems where it is most commonly used.

---

12. Conclusion

The unweighted average completion time is a biased statistic that:

1. Can be gamed by scheduling policy (Theorem 1), unlike work-weighted completion time which is schedule-invariant (Theorem 2).
2. Incentivizes starvation of large tasks (Theorem 3).
3. Contradicts Little's Law unless tasks are uniformly sized.
4. Degrades client satisfaction with zero compensating productivity gain (Theorem 7).
5. Actively contradicts priority systems by carrying zero information about business-impact classification (Theorem 9).
6. Maximizes priority-weighted delay in the most common real-world scenario where high-priority tasks are large (Theorem 10).

A metric that can be improved by reordering work — without doing any additional work — is measuring the scheduling policy, not the system's capacity or effectiveness. When combined with a priority system, the metric does not merely fail to reflect priorities — it recommends the schedule that inflicts the most damage on the highest-priority work.

The unweighted mean is defensible only under narrow, identifiable conditions (Section 11.5): uniform task sizes, no priority system, one-to-one client-task mapping, and no behavioral influence from the metric. These conditions are rarely met in practice.

Unweighted average completion time is not a fair or accurate measurement of task execution performance. Its adoption as a team metric will rationally produce starvation of complex work, violation of stated priorities, inequitable client outcomes, and the illusion of productivity where none exists.

---

This proof was developed conversationally and formalized on 2026-03-28.