A team split is a shuffled partition
A fair team assignment starts with one random ordering of the whole roster. The tool uses Fisher–Yates to make that ordering, then cuts it into consecutive blocks of the requested size. No person is drawn twice and no person disappears because every input position is used exactly once. This is different from choosing members for Team 1, then Team 2, with replacement: that flawed procedure can duplicate people unless it constantly repairs its own list. Here a roster of ten people and a size of three becomes three full teams plus one final team of one. The smaller final group is a consequence of arithmetic, not a hidden preference.
What the shuffle rule guarantees
For N named roster positions, an ideal uniform shuffle has N! possible orders. Each person then has the same probability of occupying every position. When groups are slices of that order, each person has the same mathematical chance of joining any particular size-three block. It does not mean every possible pair is guaranteed to occur equally often in a small series of reruns; random allocation can repeat a pairing. The page’s rule shuffles the supplied roster once before cutting it into blocks, so it gives no name a privileged position by design. It is suitable for a casual transparent allocation, not for a security-sensitive or regulated drawing that needs a specified random source and independent audit.
Worked roster
Enter Alex, Blair, Casey, Drew, Emery, Finley, Gray, Harper, Indigo, and Jules with team size 3. A possible shuffled order is Gray, Alex, Jules, Casey, Harper, Emery, Blair, Indigo, Finley, Drew. The displayed blocks are Team 1: Gray, Alex, Jules; Team 2: Casey, Harper, Emery; Team 3: Blair, Indigo, Finley; Team 4: Drew. There are four teams because ceiling(10 ÷ 3) is 4. The last team holds 10 mod 3 = 1 person. If a solo team is unacceptable, decide an adjustment before running the draw: use size 2, move one volunteer, or ask for a fixed number of teams instead.
Practical allocation rules
This method suits a workshop activity, casual sport warm-up, study groups, or rotating project tables where equal-sized groups matter more than skill balance. Read the roster aloud before drawing and agree whether absentees count. A name that appears twice is rejected rather than silently treating the duplicate as two people; distinguish people with the same first name as “Sam P.” and “Sam R.”. If someone joins late, rerunning creates an entirely new allocation. Adding that person by hand may be preferable when preserving the original draw matters, but then it is an organizer decision, not a random split.
What it cannot balance
Equal headcount is not equal ability, accessibility need, language, role, or equipment. A basketball organizer trying to distribute ratings should use a balanced-team method that explicitly models those ratings; randomness alone can put the strongest players together. Nor does a size-based split produce pairs only: a group size of two does, but an odd roster still leaves one person. Do not use a randomizer for hiring, disciplinary, medical, educational eligibility, or any decision where an unexamined draw would affect someone’s rights. The result is an auditable allocation aid, not evidence that every real-world outcome is fair.
Choosing a fixed group size
A random team generator asks for the number of teams and deals people round-robin, so it spreads the remainder among groups. This page begins from the number of people wanted in each team and makes the final partial group explicit. A partner generator is narrower: it creates pairs only. A tournament bracket creates opponents and BYEs for elimination, not working groups. This tool is the right choice when “three per table” or “four per lab bench” is the governing constraint. The roster and result remain in this browser tab; they are not sent to DiceDecide.
A repeatable event procedure
For a visible classroom or workshop draw, prepare the list in a plain-text document first and paste it only after the names have been confirmed. State the intended size and the treatment of the remainder before pressing Run tool. Screenshot or copy the assignment, then lock the result for that activity. Those simple steps distinguish an honest random allocation from a redraw performed until an organizer likes the arrangement. If teams meet repeatedly, retain the previous rosters and inspect pairings across sessions; independent daily shuffles can accidentally place the same two people together several times. Avoid “correcting” a result by secretly swapping people. If a necessary accommodation requires a change, announce it and record the reason separately from the random portion.
Remainders and stable tables
A partial final team is not the only possible remainder policy. Ten people at tables of three can instead form two teams of three and two teams of two; eight people can make one team of four and two teams of two. Those are different partitions with different social and practical properties. The page deliberately does not invent such a policy because it cannot know whether a table needs exactly three chairs, whether pairs are acceptable, or whether a facilitator can join the smaller group. Calculate the remainder first: divide the roster count by the desired team size, then inspect both quotient and remainder. If the physical setup requires equal groups, change the size or the eligible roster before drawing. Randomness decides membership after the constraints are clear; it should not conceal an unresolved capacity problem.
Pair exposure across several sessions
One shuffle makes a defensible allocation for one meeting; it does not distribute partnerships evenly over a term. With ten people, a named person has nine possible partners, yet a new independent draw can pair the same two people again immediately. If the purpose is to make everyone work together over six classes, keep a pairing log and choose a scheduling rule that penalizes prior pairings. That is a constrained rotation problem, not a promise delivered by a single random permutation. The useful result from this page is the visible roster partition for the present session. Do not claim that it has already achieved long-run diversity, because that property needs records from earlier sessions.