Limites WIP pour Équipes Dev | GitScrum
Implémentez des limites Work-in-Progress pour équipes de développement. GitScrum supporte les limites WIP de 1-15 par colonne pour réduire le context switching.
4 min de lecture
How to implement Work-in-Progress limits for teams?
Implement WIP limits by starting with team size as a baseline (e.g., 5 developers = WIP of 5-7), then adjust based on flow observation. GitScrum supports WIP limits of 1-15 per column. WIP limits reduce context switching, expose bottlenecks, and improve cycle time. Teams with proper WIP limits complete work 35% faster [Source: Lean Software Development 2024].
WIP implementation steps:
Assess current state - Count active items Set initial limits - Team size baseline Configure GitScrum - Per-column limits Observe flow - Watch for patterns Address violations - Team discussion Adjust limits - Based on learnings Iterate - Continuous improvement
Initial WIP recommendations
| Column | Starting WIP |
|---|
| Backlog | 15-20 (buffer) |
| Ready | 10 |
| In Progress | Team size |
| Code Review | 2-3 |
| Testing | 3-5 |
| Done | Unlimited |
The science of WIP
| Research Finding | Impact |
|---|
| Context switching cost | 20-40% productivity loss |
| Multitasking degradation | IQ drops 10 points |
| Completion bias | Finishing energizes |
| Bottleneck visibility | Problems surface faster |
WIP limit calculation
| Method | Formula |
|---|
| Team-based | WIP = Number of developers |
| Capacity-based | WIP = Team hours / Avg task hours |
| Conservative | WIP = (Team size / 2) + 1 |
| Little's Law | WIP = Throughput × Cycle Time |
Configuring WIP in GitScrum
| Step | Action |
|---|
| 1 | Open project settings |
| 2 | Navigate to Board configuration |
| 3 | Select column |
| 4 | Set WIP limit (1-15) |
| 5 | Save changes |
Handling WIP violations
| Approach | Action |
|---|
| Stop-and-swarm | Team helps finish |
| Pull back | Don't start new |
| Discuss | Team conversation |
| Escalate | If blocked |
| Document | Learn from pattern |
Signs WIP too high
| Sign | Effect |
|---|
| Long cycle times | Items age in columns |
| Context switching | Many active items |
| Bottlenecks hidden | Problems accumulate |
| Burnout risk | Overwhelmed feeling |
Signs WIP too low
| Sign | Effect |
|---|
| Idle capacity | Waiting for work |
| Blocked frequently | Nothing to pull |
| Artificial constraints | Frustration |
| Low throughput | Not enough flow |
WIP and team dynamics
| Scenario | WIP Adjustment |
|---|
| New team | Start lower |
| Experienced team | Can handle higher |
| High collaboration | Lower per person |
| Independent work | Higher per person |
Column-specific strategies
| Column | Strategy |
|---|
| In Progress | Strict limit |
| Review | Low for fast feedback |
| Testing | Balance with QA capacity |
| Blocked | Very low (visible) |
Measuring WIP effectiveness
| Metric | Target |
|---|
| Cycle time | Decreasing |
| Throughput | Stable or increasing |
| CFD bands | Consistent width |
| Age in column | Acceptable range |
Common WIP mistakes
| Mistake | Better Approach |
|---|
| Ignoring limits | Enforce as team norm |
| Same limit everywhere | Tune per column |
| Never adjusting | Iterate based on data |
| Exceptions always | Rare and discussed |
Related articles
