Workstream Staffing Planner — User Guide

Quick start

1. Open the planner in any browser — no installation required.
2. Set your project configuration in the panel at the top.
3. Fill in the duration and parallelism for each workstream.
4. Drag the People sliders to allocate your team.
5. Read the results in the metrics bar and chart.

The configuration panel

At the top of the page, three inputs define the shape of your project. Press Apply (or hit Enter in any field) to rebuild the tool with new values.

Input	What it controls
Workstreams	Number of parallel workstreams (1–12). New workstreams are added with sensible defaults.
Team members	Total headcount available to allocate across all workstreams.
Base unit (days)	The reference unit used in the subtitle and for default durations of new workstreams. Does not affect existing workstream durations.

When you change the number of workstreams or team size and hit Apply, workers are redistributed evenly and all sliders reset to that baseline allocation.

Configuring each workstream

Every workstream card has three inputs:

Duration

The estimated time this workstream would take one person working alone, in days. This is the most important input — it anchors all the calculations.

Example: if one person could complete the workstream in 20 working days, enter 20.

Parallel %

The percentage of the workstream's work that can be done in parallel by multiple people. The remaining percentage is serial — it must be done sequentially regardless of team size.

• 100% — fully parallelisable; doubling the team halves the time.
• 0% — fully serial; adding more people has no effect at all.
• 50% — half the work benefits from extra people, half doesn't.

Example: a workstream with lots of independent tasks (writing, testing separate modules) might be 70–80%. One with a strict sequential dependency chain might be 20–30%.

People

How many team members are assigned to this workstream. The total across all workstreams must equal your configured team size — the People allocated metric turns red if you're over or under.

Reading the results

Metrics bar

Metric	Meaning
People allocated	Running total of assigned workers vs your team size. Turns red if mismatched.
Project duration	The elapsed time of the slowest (bottleneck) workstream — this is how long the project takes overall.
Avg workstream time	Mean elapsed time across all workstreams. Useful for spotting imbalance.
Bottleneck serial floor	The irreducible minimum time for the current bottleneck workstream — the time it would take even with infinite people. You cannot optimise below this.

The two time metrics each show a delta vs the original allocation (the even distribution set when you last pressed Apply). Green means an improvement, red means it got worse.

Workstream cards

Each card shows the elapsed time for that workstream in its current state, alongside a badge:

Badge	Meaning
bottleneck	This is the slowest workstream and defines the project duration.
−Xd	Faster than the original allocation by X days.
+Xd	Slower than the original allocation by X days.
unchanged	No meaningful change from the original.

The card subtitle updates live to show the current serial floor as you change duration and parallelism.

Chart

The bar chart shows elapsed time per workstream:

• Grey bars — time under the original (even) allocation.
• Green bars — time under your current allocation.
• Red dashed line — the serial floor for each workstream (the minimum possible time, regardless of how many people you add).

The Y-axis scales automatically to your data.

Optimisation buttons

Button	What it does
Minimise project duration	Redistributes all workers to make the slowest workstream as fast as possible.
Minimise average time	Redistributes workers to bring the average workstream time down across the board.
Reset to original	Returns all sliders to the even distribution from when you last pressed Apply.

These buttons use a greedy algorithm — they repeatedly assign the next available person to whichever workstream benefits most, until all workers are placed.

Scaling models

Toggle between two models using the buttons below the config panel.

Pollack's Rule (default)

T = D × [(1 − P) + (P / √N)]

Performance scales with the square root of the number of workers. This is more realistic for most knowledge work — doubling the team doesn't double throughput because of coordination overhead, communication costs, and ramp-up time.

Amdahl's Law

T = D × [(1 − P) + (P / N)]

Performance scales linearly with workers on the parallel portion. This is the theoretical maximum — it assumes perfect coordination with zero overhead. Useful as an optimistic upper bound.

In practice: Pollack is the better default for software, research, or any knowledge-intensive work. Amdahl may apply to highly mechanical or well-isolated tasks.

Key concepts

Tips

• Start with Minimise project duration to see the theoretical best allocation, then adjust manually to reflect real-world constraints like skills, availability, and team preferences.
• If the serial floor of your bottleneck workstream is close to your target date, no amount of staffing will help — you need to change the work, not the headcount.
• A wide gap between the grey and green bars on a workstream means your current allocation is very different from the baseline — worth checking whether that's intentional.
• Switch to Amdahl to see how much headroom you'd have if coordination were perfect. A large gap between Pollack and Amdahl results suggests coordination costs are a significant factor in your project.