In your specific case, you should probably begin thinking of analysis as a queue with work-in-progress (WIP) limits and finite capacity. Analyzing faster than work can be pulled into the next step in the process is generally an agile anti-pattern, where just-in-time (JIT) planning and embracing change are core principles.
If you decide you must queue in a way that exceeds the capacity of the rest of your process, then you should either define a separate Kanban for that workflow, or break your current workflow into smaller steps that can be visualized and pulled from within your current board.
Pull Work Only When It's Ready to be Acted Upon
Kanban is a pull-queued system. This means that work must:
- Be pulled into a column by the person doing the work. It is never pushed there be anyone or anything else in your process. NB: Even a "Done" column is conceptually a pull, where someone is taking an action to mark work complete.
- The pull should only happen when there is available capacity, e.g. both the column and the board are within their defined work-in-progress (WIP) limits.
So, in your example, the analyst (or whoever will be doing the analysis) pulls work from Backlog -> Analysis whenever that person has capacity and is ready to queue or perform the work. I recommend only pulling the task when it's ready to be acted upon so that it's actually work in progress, rather than simply queued up.
Kanban does allow for the notion of queues, but the queueing column should never exceed WIP limits. If you find the team pulling (or worse, pushing) work into a column that is routinely blocking, you'll need to review your process and your WIP limits to determine how to optimize your flow better.
Queueing the Analysis
It's certainly possible to design a Kanban process that has multiple flows, with multiple input and output queues, but this isn't really your use case. Instead, you should acknowledge that you can only analyze a certain amount of work at a time, and define your WIP limits and processes around that fact.
However, visualization is important, too. If you really want to queue work that needs to be analyzed (e.g. queued separately from the backlog), you might consider sub-columns. For example:
BACKLOG | ANALYSIS | QA/DEV REVIEW
... | Queued for Analysis | Analyzing | Analysis Complete | ...
In this case, you can visualize how much work is queued, how much work is actively in progress, and what's available for the QA and Development teams to pull into their columns. Just keep in mind that it's still conceptually a pull queue: the analysts pull the work into the queue, and through their own task columns; the developers pull only from "Analysis Complete" when they have capacity.
If you go this route, you will also need to ensure that the WIP limits for "Analysis" as a whole, and each sub-column within it, have sensible individual and collective limits. Within a single Kanban process, there's very little point in pulling 10,000 items into "Queued for Analysis" if you're trying to measure cycle time from Backlog -> Release, or having more work in "Analysis Complete" than can reasonably be expected to be done within your cycle time or iteration. That's why the WIP limit for the whole board should be adhered to, in addition to any column-level limits: Kanban requires optimization for flow by reducing queue length and batch size, so you violate those principles at your own risk.