Collaboration During the Sprint: Swarming, Pairing, and Managing Work in Progress

Why “finish work” beats “start work”

During a Sprint, the biggest risk to delivering a usable Increment is not a lack of tasks to start—it’s too many partially done items. Partially done work creates hidden queues: reviews waiting, tests waiting, clarifications waiting, deployments waiting. Collaboration patterns like limiting work in progress (WIP), swarming, and pairing help the team shorten these queues so items reach “Done” sooner and the Sprint Goal stays achievable.

Think of your Sprint Backlog as a system with limited capacity. Every new “in progress” item consumes attention, context, and coordination. The practical question to ask every day is: What is the smallest set of items we can actively work on to finish the next valuable thing?

Limiting WIP using the Sprint Backlog

What WIP means in a Sprint

WIP is the number of backlog items (and sometimes tasks) currently being worked on but not yet meeting the team’s Definition of Done. High WIP usually shows up as many items sitting in “In Progress,” “In Review,” or “In Test,” while “Done” grows slowly.

Two levels of WIP limits

• Item-level WIP: Limit how many Product Backlog Items (PBIs) can be “in progress” at once (e.g., 2–4 items for the whole team).
• Stage-level WIP: Limit how many items can be in a workflow stage (e.g., max 2 in “Review,” max 1 in “Ready for Test”).

Item-level limits keep the team focused on finishing. Stage-level limits reveal bottlenecks (for example, reviews piling up).

How to set a simple WIP policy (step-by-step)

1. Define your workflow states on the Sprint Backlog board (example: “Ready,” “In Progress,” “Review,” “Test,” “Ready to Release,” “Done”).
2. Pick one starting rule: “No more than N PBIs in progress at a time.” A common starting point is N = 1–2 for small teams, N = 2–4 for larger teams.
3. Add one stage limit where you feel pain (often “Review” or “Test”). Example: “Review WIP limit = 2.”
4. Write the policy on the board (short, visible, unambiguous). Example: “If WIP limit is hit, we swarm to finish before starting new work.”
5. Decide the exception rule (see urgent work section). Make exceptions explicit, rare, and visible.

Practical behaviors that make WIP limits real

• Stop starting, start finishing: When the WIP limit is reached, nobody pulls a new item. The default action is to help move an existing item toward Done.
• Prefer “pull” over “push”: Don’t push work to QA/design/ops as a handoff. Instead, pull them into the item earlier so it flows through stages faster.
• Make waiting visible: If an item is blocked, mark it clearly (tag, sticker, or “Blocked” state) and write the blocking reason.
• Use “aging” indicators: Highlight items that have been in progress for more than a day or two. Old items get attention first.

Example WIP policy for a Sprint Backlog board

Swarming: unblocking and completing items

What swarming is (and isn’t)

Swarming means multiple team members collaborate on the same backlog item to move it to Done quickly—especially when it’s blocked or close to completion. It is not “everyone doing the same task.” It’s coordinated teamwork where people contribute different skills (analysis, coding, testing, UX checks, automation, deployment) to finish one item.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

When to swarm

• An item is blocked and the blocker can be removed by collaboration (clarification, environment fix, test data, review).
• WIP limits are hit and no new item should be started.
• An item is in “Review” or “Test” and waiting time is growing.
• The Sprint is mid-to-late and you need to protect the Sprint Goal by finishing the most valuable items first.

Swarming playbook (step-by-step)

1. Pick the swarm target: Choose the item closest to Done or most critical to the Sprint Goal.
2. Define “Done for this item” in concrete checks: Example: “API endpoint implemented, unit tests passing, UI updated, accessibility check done, logs added, deployed to staging, acceptance checks pass.”
3. Assign micro-roles for 30–90 minutes: One person drives the main change, another reviews continuously, another prepares test cases/data, another checks monitoring/deploy steps.
4. Remove the blocker first: If blocked by a decision, get the decision now. If blocked by tooling, fix the environment now. Don’t keep coding around the blocker.
5. Integrate continuously: Merge small, keep builds green, run tests frequently. Avoid a “big bang” merge at the end.
6. Stop the swarm when the item is Done: Then reassess WIP and pick the next best item.

Swarming example: item stuck in “Test”

Scenario: A PBI is in “Test” with failing automated checks and unclear reproduction steps.

• Developer A pairs with QA to reproduce and isolate the failure.
• Developer B investigates recent changes and prepares a small fix branch.
• Another teammate updates test data and improves the failing test’s diagnostics.
• Once fixed, the team reruns the full suite and confirms acceptance checks.

Outcome: The item moves to Done the same day instead of lingering for multiple days.

Pairing and mobbing patterns that reduce rework

Why pairing helps flow

Pairing reduces delays caused by later reviews, misunderstandings, and knowledge silos. It also improves quality earlier, which prevents items from bouncing between “In Progress” and “Fixing.”

Common pairing modes

• Driver–Navigator: One person types (driver), the other thinks ahead, spots risks, and checks alignment (navigator). Swap every 15–30 minutes.
• Ping-pong pairing: Person A writes a test, Person B makes it pass, then swap. Works well for test-first or behavior-driven approaches.
• Review-as-you-go: Pair briefly at key points (design choice, tricky logic, edge cases) rather than full-time pairing.

When to pair (practical triggers)

• The item has unclear acceptance checks or tricky edge cases.
• The change touches a risky area (security, payments, migrations, performance).
• A teammate is new to the codebase or domain.
• The item is late in the Sprint and rework would threaten the Sprint Goal.

Mobbing (ensemble work) for high-risk or cross-cutting changes

Mobbing (sometimes called ensemble programming) is when the team (or a subset) works together on one item at one workstation/session. Use it sparingly for work that benefits from rapid alignment: architectural changes, complex refactors, incident fixes, or a new pattern the team wants to learn together.

Lightweight mobbing format:

• Timebox: 60–120 minutes.
• One driver, rotating every 10–15 minutes.
• Clear goal: “Get the migration script safe and tested in staging.”
• End with a concrete artifact: merged PR, updated runbook, automated test, or verified deployment.

Pairing across specialties

Pairing is not only for developers. Cross-specialty pairing reduces handoffs:

• Dev + QA: Define acceptance checks together, add automation while implementing.
• Dev + Design: Validate UI behavior and edge cases early, avoid late redesign.
• Dev + Ops/SRE: Add logging/metrics, confirm deployment steps, validate rollback plan.

Coordinating across specialties without creating queues

Shift from “handoff” to “co-ownership”

Queues form when work is “thrown over the wall” to another specialty. Instead, treat each PBI as a shared responsibility. The goal is to have specialties involved early enough that the item can flow to Done without waiting days for the next person.

Practical coordination patterns

• Three-amigos mini-session (10–20 minutes): For a PBI about to start, a developer, QA, and design/PO (as needed) quickly align on scenarios, edge cases, and what “good” looks like.
• Embedded QA/design time: Instead of “QA after dev,” include QA activities inside the item’s tasks from the start (test data, automation hooks, exploratory notes).
• Definition-of-ready checks for starting work: Not a separate artifact—just a quick checklist before pulling an item: acceptance checks understood, dependencies identified, design assets available (if needed), environment ready.
• Ops involvement early: If an item needs config changes, feature flags, or infra updates, schedule that work alongside implementation, not after.

Example task breakdown that supports flow

PBI: Add password reset email flow  (Sprint Goal critical) Tasks: - Confirm email template + edge cases with design (30m) - Add endpoint + unit tests (3h) - Add email service integration + logging (2h) - Add automation: reset flow happy path (2h) - Exploratory checks: rate limiting, expired token (1h) - Deploy to staging + verify monitoring (1h)

This breakdown makes cross-specialty work part of the item, reducing late-stage surprises.

Handling urgent work without derailing the Sprint Goal

Classify urgency quickly

Not all “urgent” requests are equal. Use a fast classification so the team doesn’t constantly interrupt itself:

• Production incident / severe customer impact: Usually requires immediate attention.
• Time-sensitive business request: Might be urgent, but confirm impact and deadline.
• Internal request / nice-to-have: Often can wait.

Urgent work protocol (step-by-step)

1. Make it visible: Create a clearly labeled Sprint Backlog entry (e.g., “URGENT: …”) so it’s not hidden in chat.
2. Check Sprint Goal impact: Ask: “If we do this now, what will we not finish?”
3. Timebox investigation: If unclear, do a short spike (e.g., 30–60 minutes) to determine size and options.
4. Choose one of three actions:
   • Swarm and finish fast: If it’s truly critical, swarm to resolve quickly and return to Sprint work.
   • Swap work: Remove or de-scope a lower-priority item to keep capacity balanced.
   • Schedule next: If it can wait, put it in the Product Backlog for ordering later.
5. Protect WIP: Do not start urgent work by increasing total WIP. Pause/finish something else first, or explicitly stop another item.
6. Capture learning: Add a small follow-up task if needed (monitoring, test coverage, runbook update) so the same urgency doesn’t recur.

Micro-policy example: “One-lane expedite”

If urgent work is frequent, create an explicit expedite lane with strict rules:

• At most 1 urgent item at a time.
• Requires a clear impact statement and acceptance checks.
• Team swarms until Done, then lane is empty again.

This prevents “urgent” from becoming a permanent second backlog.

Day-to-day playbook: when work is stuck

Step 1: Identify the type of stuck

• Blocked by decision: unclear requirement, missing approval, conflicting expectations.
• Blocked by dependency: another team, external system, vendor, environment.
• Blocked by quality: failing tests, flaky pipeline, unclear acceptance checks.
• Blocked by complexity: unknown approach, hidden technical risk.

Step 2: Apply the smallest effective intervention

• Decision block: Schedule a 10-minute alignment with the needed people; write the decision in the item.
• Dependency block: Create a concrete request with deadline; assign an owner to follow up; consider a workaround that still meets acceptance checks.
• Quality block: Pair dev+QA; reproduce; fix; add/adjust tests so the issue can’t return silently.
• Complexity block: Timebox a spike; mob for 60 minutes; split the item into a smaller slice that can reach Done.

Step 3: Decide: swarm, split, or stop

Use this quick decision table:

Day-to-day playbook: when too many items are “in progress”

Symptoms

• Many PBIs are started, few are Done.
• Review/Test columns are full.
• People say “I’m waiting on…” frequently.
• Context switching increases and quality drops.

Reset protocol (step-by-step)

1. Freeze new starts: For the next half-day (or day), nobody pulls a new PBI unless one reaches Done.
2. Rank in-progress items by Sprint Goal contribution: Mark the top 1–2 items as “Finish First.”
3. Swarm on the top item: Move it through review/test/release steps. Treat downstream work (review, test, deploy) as first-class work.
4. Clear bottlenecks explicitly: If “Review” is full, prioritize reviews. If “Test” is full, prioritize fixing failures and stabilizing tests.
5. Stop or de-scope the least valuable in-progress item: If you can’t finish everything, reduce WIP by pausing an item (document status and next step) rather than keeping it half-done.
6. Reinstate WIP limits: Add or tighten limits so the situation doesn’t recur (e.g., reduce “In Progress” from 4 to 3).

Team agreements that prevent WIP creep

• “Review before new work”: If you have capacity, check the Review column before pulling a new task.
• “Test failures are emergencies”: A broken pipeline or failing tests get immediate attention because they block flow for everyone.
• “One item per person is not the goal”: It’s acceptable for someone to have no personal task if the best move is to help finish a shared item.
• “Aging limit”: If a PBI is in progress more than X days, it triggers a swarm or a split.

Practical templates you can copy into your Sprint Backlog

Blocked note template

BLOCKED: [short reason] Impact: [what can't progress] Needed: [decision / access / fix] Owner: [name] Next check: [date/time]

Swarm checklist template

• What is the fastest path to “Done” for this item?
• What is the current bottleneck (review, test, deploy, decision)?
• Who can remove the bottleneck in the next 60 minutes?
• What is the next verifiable step (PR merged, test passing, staging verified)?