Prioritization does not happen in isolation from how work actually flows. Little's Law states that average lead time equals work-in-progress divided by throughput. The implication is direct: adding WIP without raising throughput just slows everything down. Each in-progress item competes for attention, increases lead time, and raises the chance of context-switch errors. The cost of context-switching is real — each switch carries minutes of reorientation, and heavy multitasking can erase double-digit percentages of productive time.
The "stop starting, start finishing" rule captures the discipline: a half-done item delivers zero value, so prioritize finishing before opening new work. A WIP limit caps how many items can be in progress at once, forcing completion before new starts — a core kanban practice. Throughput itself is a prioritization signal: low throughput often means too many parallel priorities, not too few people. The concurrent priority cost rule is brutal — two priorities take more than twice the time of one because of switch overhead, so where possible a single live priority should be picked.
Different work needs different treatment. Class-of-service prioritization distinguishes expedite items (jump the queue), fixed-date items (scheduled against a deadline), standard items, and intangibles. A swim-lane prioritization view splits the kanban board by class of service so targeted rules can be applied per lane. Single-threading a goal assigns one owner with unambiguous authority on a top priority — Amazon's mechanism for moving important bets fast without committee drag. Queue discipline is the team's habit of not letting new asks jump live work without explicit re-prioritization.
The Theory of Constraints (TOC) frames prioritization around the system's bottleneck. Elevating the constraint — investing extra capacity at the bottleneck — is usually higher-leverage than optimizing non-bottleneck steps, because other improvements are merely local. The critical chain is the longest chain of dependent tasks accounting for resource constraints; it drives total project duration. For product teams, dual-track agile prioritization runs discovery and delivery as separate streams in parallel. An opportunity backlog — a list of validated user problems separate from the solution backlog — forces prioritization to happen at the problem level first. Story slicing breaks a big story into smaller deliverable pieces so the highest-value slice can ship without the rest. Smaller architectural patterns — walking skeleton, tracer bullet, smallest valuable increment, minimum testable change, shrink the change, expand the change — all push the same idea: prove the architecture or the bet cheaply before scaling investment.