Upgrade & Secure Your Future with DevOps, SRE, DevSecOps, MLOps!
We spend hours scrolling social media and waste money on things we forget, but won’t spend 30 minutes a day earning certifications that can change our lives.
Master in DevOps, SRE, DevSecOps & MLOps by DevOps School!
Learn from Guru Rajesh Kumar and double your salary in just one year.
Ask any operations team how many things are in flight right now and you will get a nervous laugh. A model rollout here, a dashboard rebuild there, three half-finished automation experiments and a pile of tickets that were “almost done” last month. A work in progress limit for AIOps projects is a simple cap on how many of those can be open at once, and it is one of the most misunderstood habits in the field. Six common beliefs deserve a second look.
Myth 1: More open projects means more progress
It feels true. Ten threads moving a little each day sounds better than one thread moving fast. But a thread only counts when it lands in production and somebody relies on it. Starting is cheap and finishing is rare, so a crowded board mostly measures how much has been started. Teams that cap their open items usually see the same total output arrive sooner, because nothing sits waiting for attention that is split ten ways.
Myth 2: A cap is just a polite word for slowing down
The cap slows starting, not finishing. When the limit is reached, the next move is to help the item that is stuck, not to open a new one. That sounds small, yet it changes behaviour: the person with free hands reviews a pull request, answers a question or pairs on a blocked model evaluation instead of picking up something shiny. Flow improves because the oldest work gets the spare capacity first.
Myth 3: AI tooling makes juggling safe
Machine learning in operations is good at spotting patterns across logs and metrics, and it is tempting to assume that smart tooling lets people carry more at once. It does not change how human attention works. Every open item still demands a bit of your head: where you left off, what you were waiting for, who you told. Context switching costs the same whether the pipeline behind it is clever or not. If you want a grounded starting point for bringing such tooling in, this walkthrough on getting a team ready for AIOps the right way pairs well with the idea of keeping rollouts few and finished.
Myth 4: The limit should be the same for everyone
There is no magic number. Most teams begin with one or two live items per head, with a shared ceiling on the whole board that is a little lower than the head count. Treat that as a hypothesis. If the board starves, raise it by one. If items keep ageing, lower it by one. What matters is that the number is written on the board, visible, and respected by whoever is most senior in the room.
Myth 5: Urgent work must be exempt
Every team has an “expedite” lane, and every team abuses it. If everything urgent bypasses the cap, the cap is decoration. A better rule is to allow one expedite slot at a time, with a name beside it, and to pause something else visibly when it is used. That makes the real cost of interruptions obvious to the people asking for them, which is often enough to make them rarer.
Myth 6: You will know the cap is working by looking at the board
A tidier board is nice but it is not the proof. Watch how long things take from the day somebody picks them up to the day they are really done, and how often an item gets reopened. When the cap is doing its job, the waiting time shrinks, fewer threads are “forgotten for a week”, and stand-ups stop sounding like a list of apologies. Pair the board with a short look at how work flows through a beginner-friendly explanation of solving IT problems as they happen, because quick problem handling and a capped queue support each other.
What a capped week looks like in practice
Picture a small platform team with four people. The board limit is three open projects. Monday starts with a capacity forecast task, a log-enrichment change and an on-call handover document. Someone wants to add a cost report. The answer is not “no” forever, it is “after one of these three closes”. By Wednesday the handover document is finished, the report moves in, and nobody has had to remember which of seven things they promised to look at on Thursday.
Small habits help. End each day by moving one item closer to done rather than refreshing the backlog. Write down the blocker next to any item that has not moved in two days. Say aloud which item you are pulling next and why. None of this needs a new tool, only a limit that people agree to keep.
Where to look for fresh ideas on finishing things
Wellness communities have been talking about doing less, better, for years. One example is a health-and-wellbeing site that mixes discussion boards, articles and directory listings, which shows how one address can hold several kinds of pages without pretending to be everything at once. The lesson carries over to operations: pick the few things you can maintain well and be honest about the rest.
A simple way to try it
Count what is open today. Choose a limit that is one fewer than that number. Mark the items that are closest to complete and push those over the line first. Only then pull something new. Check in after two weeks, adjust by one, and keep the number on the wall. Teams that do this rarely go back, mostly because finishing feels good and the board finally tells the truth.