Kanban principle with three items

The optimal batch size is ideally one (single piece flow). Good teams generally try to reduce their batch sizes. By limiting work in progress through better collaboration and focus, they can provide value to a higher quality earlier and more often. This in turn enhances predictability and flow, and increases the reliability of any forecasts about when future work is likely to be delivered.

Why do you think that you can only have four workflow steps? Why do you think that you can only have three items in progress at any one time? Both are things that should be evaluated by the team. I'm not sure what article you're referring to, so having that would probably be helpful.

I don`t think that we need to have only four workflow steps. It depends on the scope of the project. 

For example, the project that I am talking about involves more than ten internal applications in the company and how we monitor them. So I think that if in that previous moment, I had chosen the approach with only three tasks or only one, this would reflect the end result with so many unfinished tasks.Do you think this is the right way to think?

@Thomas I just copied the one part of the articles. See how they explain it.

In my experience, Kanban worked best when we moved a single item across the board/workflow.  That item was not a task. It was a representation of the value being created/delivered.  It described the work being done from the business value perspective.  It traversed the various steps in the workflow as the people working on it determined it had completed that step and there was availability to work on it in the next step of the workflow. 

One thing I always point out to people having trouble with Kanban is to remember the origin of the process.  It was an inventory management technique created by Toyota.  The purpose was to visualize units of inventory as they progressed through the factory. In that case, the item traversing the boards was some allocation of inventory (a pallet containing 200 brake pads for example).  The columns on the board would show the workflow for the supply and use of the item, some examples could be inbound on truck, in warehouse, waiting at installation station, in use, exhausted. There were a lot of tasks involved in the use of the item but they did not traverse the board. 

I do not know why you are only using 4 steps in your workflow as that seems pretty limiting and doesn't help you in determining where bottlenecks occur and how to prevent them.  I have never been involved in a team using Kanban that had that minimalistic of a workflow defined. 

In software development where I have used Kanban, the columns on the board would represent the tasks (usually at a high level).  Your column named "in progress" should actually be "in development" because you have a column named "in validation".  In progress means that it is moving through the workflow and "in validation" is work.  So you have already made things less clear.  Where does the work for refining the requirements happen?  Or the user interface design?  Or the system design?  How do you recognize that there are too many things in progress at any stage of the work flow if you only have 1 column for the majority of the workflow?  

Your original question is regarding the monitoring of Work In Progress (WIP).  That practice is used to help prevent bottlenecks and ensure a smooth transition of work across the workflow.  Research it, read multiple sources and then form your own opinion on how it can aid your team.  Discuss it with the team since they are the ones that are doing the work.  Remember that a lot of people can "tell" you how to do things but they are only giving you their opinions (such as everything I have typed in this response).  The people doing the work should come together to agree on a definition that they choose to work for them while doing that work. 

I reread your question and my response.  I realized that I didn't really address your question and instead took an opportunity to discuss Kanban.  So, excuse me for double posting but this one will be about your original question.

Your question is in regards to limiting Work in Progress (WIP).  That practice is used to help the people doing the work to focus on finishing work instead of starting new work.  In my 30+ years of work in software development, one thing I have learned is that people writing code like to write code.  They like to write code to address a situation, then move on to writing code to address a different situation.  While this can be a good thing, in today's era it might not be.  Most organizations today have some requirements in place that code has to be reviewed and tested before it can be delivered.  But most developers don't like to do code reviews as it isn't as creative and engulfing as writing code.  So, often you will see that many code branches/commits will sit waiting for others to review so that they can meet the organizational requirements to move forward.  This is a bottleneck. It can also lead to large groups of work being progressed to the next step which can overwhelm the next people in the workflow (testers for example).  The concept of WIP helps to establish a constant flow of work.  Before anything can be pulled into a workflow state, the previous work has to complete that state and enable an open spot.  This helps people focus on finishing work before starting other work.  Otherwise, the work that they do will pile up in a state and may not be able to be completed when it is needed. 

As I stated in my previous post, research the concept of Work In Progress limits.  Get insights from multiple sources and focus on understanding the concept and benefits instead of the mechanics of doing it. Then work with your team to experiment.  Break the "in progress" state into some smaller units (possible examples: coding, review, addressing reviews, deploying). Watch the flow of items through those states and see if there are any bottlenecks that form.  If so, implement a WIP for that state to encourage the people involved in that activity to focus on keeping it from becoming a bottleneck.

You might find that the project you mentioned could have benefitted from the practice and that it might have been possible to deliver it early or with additional functionality.  Or you may find that it wouldn't have made a difference because the team doing the work already made the efforts necessary to keep work flowing.  As with anything, it all boils down to experimentation and adaption as new information is gained (i.e. empiricism). 

The statement that "no bucket can contain more than three items at a time" seems, without any further context at least, to be the WIP limit for the specific example. It's not a universal truth that all teams implementing Kanban (or, more generally, WIP limits) are forced to have a WIP limit of three per state. Monitoring cycle time, throughput, and work item age (overall and within each state) can give you the tools to experiment with WIP limits. On top of this, some teams have an overall WIP limit instead of a WIP limit for each stage. You need to find what works for you.