Set and Enforce WIP Limits

practices/set-and-enforce-wip-limits

@@ -0,0 +1,54 @@
+# Set and Enforce Work-in-Process Limits
+
+Teams often have too much work in progress at once. This leads to long-lived branches, delayed code reviews, bottlenecks in QA, and constant context switching. Setting and enforcing work-in-process (WIP) limits helps teams stay focused, finish work already in motion, and reduce the overhead caused by juggling too many tasks at once.
+
+## When to Experiment
+
+“I am a developer and I need to learn how to prioritize tasks so I can move work across the finish line more quickly and avoid context switching.”
+
+"I am a team leader and I need to ensure our members stay focused on work that matters most so that we can avoid team burnout." 
+
+## How to Gain Traction
+
+  ### Set Limits that Feel Ambitious
+
+When teams start by setting limits that feel ambitious, it forces them to make deliberate choices about what work matters most. The exact number depends on your team's context, but the goal is to find the sweet spot where teams feel focused but not hamstrung. [more is needed here to make this point actionable, perhaps an example]
+
+  ### Finish Work Before Starting New Work
+
+When team members are blocked or waiting, instead of starting new tickets, they can contribute in other ways. This might include refining upcoming tickets, pairing on active work with other developers, performing code reviews, or helping QA test in-progress items. These activities keep the team moving without adding more work to the queue.
+
+  ### Visualize All Work 
+
+Use a storyboard or dashboard tool, such as [xyz], to visualize all ongoing tasks, including hidden or auxiliary tasks like meetings or production support. When the board shows that a limit has been reached, treat it as a hard stop -- no new work enters the system until something completes. This creates the pressure needed to finish what's started and forces the prioritization conversations that lead to better decisions. 
+
+## Lessons From The Field
+
+[Pragmint to complete]
+
+This section captures real-world patterns (things that consistently help or hinder this practice) along with short, relevant stories from the field. It’s not for personal rants or generic opinions. Each entry must be based on either:
+1. a repeated observation across teams, or
+2. a specific example (what worked, what didn’t, and why).
+
+## Deciding to Polish or Pitch
+
+After experimenting with this practice for [insert appropriate quantity of time in bold], bring the team together to determine whether the following metrics and/or signals have changed in a positive direction:
+
+### Fast & Measurable
+
+Fewer tickets stuck in review or QA (as tracked by ...)
+
+### Slow & Measurable
+
+Shorter lead times from development to release (as tracked by ...)
+
+### Slow & Intangible
+
+Less context switching and fewer rework cycles (via feedback captured by ...)
+
+Higher throughput and better team focus (via feedback captured by ...)
+
+## Supported Capability
+
+  ### [Work-in-Process Limits](https://github.com/pragmint/open-practices/blob/main/capabilities/work-in-process-limits.md)
+WIP limits help teams deliver more value by finishing what matters most. The focus shifts from starting new work to moving existing work across the finish line with greater speed and quality.