So if I follow well, the interest is in having all different types of 'blocking stages' in the pipeline so that you can identify the points that slow down your

So if I follow well, the interest is in having all different types of 'blocking stages' in the pipeline so that you can identify the points that slow down your process. With the right tool, and provided the tasks are accurately tracked, you get good statistics pointing to where you should optimize the workflow. However, it's not so simple to read. In some cases tasks were blocked because of a superficial or nonexistent analysis, which required to get more information. Which is a clear break of the flow, since it has to be paused for the time before the meeting can happen. But sometimes, the analysis can be fairly bad and very time-consuming on the other department, making the broken flow more efficient than the flowy one if you account for the whole team and not only developer time. Which seems to me that it's a good idea to optimize for flow only after you have enough consistency in the process, but still a powerful tool.