Task Allocation Generator

What this generator does

Handles the constraints that make real allocation hard. The team and group generators on this site split a list evenly and cannot be told anything else — not that a task needs a qualification, not that two people should not share one, not that a task takes at most two people. This takes those rules as input and either satisfies all of them or tells you that it could not.

How to use this tool

1. Enter the people, one per line.
2. Enter the tasks, one per line, with a capacity after a colon where only so many can work on it.
3. Add rules — must be, must not be, prefers — for anything that is not free to vary.
4. Press Allocate tasks and read the status line before the allocation.

Understanding the controls

People

One name per line. If there are more people than places across all the tasks, the tool reports that up front rather than leaving somebody unassigned without saying so.

Tasks

One per line. A number after a colon caps how many people that task takes — "Review: 2". A task with no number takes as many as it needs, which suits a role rather than a fixed-size job.

Must be / must not be

Rules, never broken. If keeping them all is impossible the result is reported as impossible and nobody is placed — the tool will not quietly drop one to produce an answer that looks fine.

Prefers

A wish rather than a rule. Granted where it can be, and where it cannot the result says which preference lost. A bar always beats a preference for the same pairing.

Spread numbers evenly

Levels the count across tasks as far as the other rules allow. Turn it off when tasks are genuinely different sizes and an even split would be the wrong answer.

Seed

Reproduces the same allocation, so a published split can be regenerated rather than redrawn into something different.

Worked examples

Six people, four tasks

Everyone assigned, numbers levelled at two, two, one and one.

With a capacity

"Review: 2" never holds three people, whatever else the rules ask for.

An impossible set

Two people barred from every task but one that holds one person — reported as impossible, with nobody placed and a line saying no allocation keeps every rule inside the capacities.

Common use cases

• Sharing out a sprint's tasks without the same person always taking the dull ones
• Distributing on-call or support duties where some people are not trained for some of it
• Allocating project workstreams across a team with different capacities
• Giving out volunteer jobs where a couple of people have to be kept apart
• Any split where a plain shuffle would produce something obviously unworkable

How this generator works

Fixed assignments are applied first and checked against the bars and capacities. The rest is solved by backtracking, placing the most constrained person first — whoever has fewest tasks open to them — because that is where a dead end shows up soonest. The search runs in escalating passes: it first tries to satisfy every preference and avoid every repeat as though they were rules, and only relaxes them one at a time once it has proved no stricter arrangement exists. That is what makes a reported compromise genuine rather than the first answer that happened to work.

Randomness and fairness

Randomness decides only between options the rules leave genuinely open — where several tasks score equally for a person, one is chosen at random rather than by list order. That matters because without it every unconstrained person would land in the first task, which is a valid allocation and a useless one. A seed swaps the cryptographic source for a deterministic, non-cryptographic generator so the same split can be reproduced.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

• Every task is treated as the same size. Capacity limits how many people a task takes, not how much work it is, so a heavy task and a trivial one count the same when numbers are levelled.
• Skills are modelled only as bars. There is no notion of who is better at something, only of who cannot do it, so the tool cannot optimise for the best fit.
• Randomised allocation is the wrong tool for anything requiring professional judgement — case assignment, performance-related work, or anything where the right person genuinely matters. Use it for work that is genuinely interchangeable.
• The search has a step limit. A very large and heavily constrained problem may stop early, which is reported explicitly rather than presented as the best answer.
• History is not carried between runs from this page. Use a seed if you need the same split back.

Common mistakes

Using a preference where a rule is meant

Preferences can be overridden; rules cannot. If something genuinely must not happen, use must not be rather than hoping the preference wins.

Reading the allocation without reading the status line

The line above the result says whether every rule held. A partial result is still shown in full, so it looks identical to a complete one at a glance.

Adding capacities that total fewer places than there are people

The tool reports this before allocating anything. Raise a capacity or remove a person — there is no arrangement that fits.

Practical tips

• Add the hard rules first and generate once before adding preferences, so you can see whether the rules alone are satisfiable.
• Run it in front of the team. An allocation everyone watched being drawn is much easier to accept than one that arrives by email.
• Keep the seed with the published split so it can be reproduced if anyone queries it.

Privacy and your data

Names, tasks and rules are handled entirely in your browser. Nothing is uploaded, nothing is stored between visits, and nothing is written into the page address — which matters here, because an allocation names real colleagues and often records who cannot do what. Analytics sees the number of assignments and nothing else. Copy or print the result before closing the tab.

Frequently asked questions

What happens if the rules contradict each other?

The result is reported as impossible and nobody is placed. Where a single pairing is both required and barred, the result names it and sets both rules aside; where the clash is spread across several rules and capacities, it says only that no allocation keeps them all. No allocation is presented as valid.

What is the difference between a rule and a preference?

A rule is never broken. A preference is granted where possible, and where it is not, the result says which preference lost and why.

Can I stop two people working on the same task?

Not directly — the rules attach a person to a task rather than to another person. Bar one of them from the task the other must take.