The fact that your oldest note (task) is three years is not necessarily a problem, simply because no matter how big a team you have they together with your customers will always be able to generate more ideas on new things to develop/change/refactor/fix/etc than what your team's capacity will be able to manage. If this is understood by the team members they will have less of a problem with an ever increasing backlog. However you might want to spend a day or two per year to clean it up; simply by going through the older items and get rid of the ones that no longer would create value.
The benefits of using WIP limits are very well described https://leankit.com/learn/kanban/benefits-of-wip-limits/ in my opinion.
However your question was on how to manage both urgent and stalled tasks, let me try to elaborate a bit on how we manage it in our development, which is working quite well.
First of all I believe you might consider changing the content of your notes. You mentioned that you have notes containing tasks. In our development model we are trying to make sure each note is describing a deliverable that will add value to the product. To complete that deliverable (note), a lot of different tasks may have to be undertaken (requirements analysis, architectural choices, design, implementation, documentation, verification, validation etc). When working with WIP limits, we have seen that it becomes more effective if you use deliverables instead of tasks. We have two different WIP limits. One for the notes on the entire board (not including notes in the backlog or the done columns), we call this the Kanboard WIP Limit (KWL). The other one is the WIP limit for the individual phases on the Kanboard, we call this Phase WIP Limit (PWL).
KWL = team size - 1
PWL <= KWL
On top of this we have also said that the PWL should decrease as we move from right to left on the Kanboard.
An example:
If your Kanboard has the phases Requirements and Design (RAD), Development and Component Test (DCT), Feature Test (FTE) and Integration Test (ITE), while your team size is 4.
KWL would be 3 (team size - 1) and PWL <= 3. PWL starts from one in the rightmost column and increases by one up to a max of 3 in this case.
- RAD has a PWL of 3
- DCT has a PWL of 3
- FTE has a PWL of 2
- ITE has a PWL of 1
We try to keep the estimated effort for a note in the backlog to maximum of what can be completed within 2 man weeks. Since the number of notes in progress are limited by the WIP limit, this means that more than one person will work on at least on one of the notes; promoting team work.
With the PWLs decreasing over the board, it also supports the core idea with Kanban to support flow (getting things ready for release) instead of keeping many things in progress (or stalled) at the same time. If a note is stuck in the ITE column, then no other note may move there. This emphasizes even more on that it is more important for the team to jointly finish off the remaining tasks to get that note done instead of starting something new.
With the estimated deliverables are of at most 2 man weeks, we believe that they are broken down well enough to support that all persons in the team will be able to understand what is to be done to get the note to the "ready for release" column. When deliverables in the backlog are bigger than that, too much time tend to be spent on doing things that are not necessary or things get missed simply because what to deliver is not clear enough.
Lets say there is an item stalled in the ITE column and only 3 out of the four people in the team can contribute to working on it, then the fourth person should work on the top-most note in the FTE column (highest priority at the top in each column, just as in the backlog). Maybe that fourth person cannot contribute (easily) to the FTE note or the DCT note or the RAD note for that matter. In that case slack has occurred (slack in the sence of what is described in the link above).
Stalled notes need to be managed by the team or team managers just as any other note. If something is hindering the team to continue working on it, then a manager/product manager/project manager/scrum master/agile master (or whatever you have at your place) needs to assist in solving the hinderance. If this is something that does not involve the team members, then the note should be put back into the backlog again (because nobody in the team is actively working on it).
Urgent tasks as you say may very well be tasks (not necessarily deliverables). It could be "investigate this bug report" or "measure this" or "summarize this for a customer", "a bug that prevents the team from working needs to be solved" etc. For these, we have introduced an ambulance (just one) on our Kanboard. Such an urgent note is accompanied by the ambulance as it moves over the board and the ambulance is the only item that is allowed to break the WIP limit. When the ambulance is on the board, it takes priority over the other notes and as many as possible from the team should contribute to remedy the urgent note as quickly as possible.
If you use this setup and find yourself in a situation where the ambulance is always (or very often) present on the Kanboard then you may have to consider setting up a single specific team to manage only the ambulance notes.
