done prior to the development teams. We can think of product development flow to have four stages. These are shown in Figure 2.
Figure 2. The stages of product development flow.
Identification and sizing of business capabilities. This is the first step. Business stakeholders (typically business executives or product managers) identify the business capabilities needed. They size these by refining them to their minimum marketable features (MMFs), sometimes called minimum viable features (MVFs).
Prioritization of these capabilities. For organizations with more than one product line, the business stakeholders and product managers that are associated with those products must decide which of these MMFs are the most important. This is product portfolio management. An organization must look across all of its products in order to determine what to work on next. Some products will return most of their value in a short period of time while others may continue to deliver large returns with each investment. It is important that teams not get locked into their products but rather switch to a product with a higher return if it makes more business sense.
Creation of stories for the teams to build these capaibilities. Once the MMFs have been prioritized, they need to be broken down further before the teams pull them to actually build the capabilities. It should be apparent that for large organizations this flow will be somewhat complex. Each business capability will likely be split out across several teams which must build different components that have both technical and business dependencies. A technical dependency between components means that one component requires another one to work. A business dependency means that although the components may work without each other, their value won’t be realized until all of them work. This is not unlike when you wait for your bags after a flight. If you have three bags, getting the first two doesn’t give you any value. It is only when that third bag arrives that you can leave.
A Short Lesson in Pull
To understand the flow in Figure 2, you need to understand a key Lean management concept: pull. Planning work is very difficult in high-variability situations – which software development certainly is. The idea of pull is that rather than planning the timing of our work, we have each step pull work from the output of the previous step. For example, in Figure 2, the development team (depicted as ‘building the capabilities’) would pull from the work area preceding it that creates the stories.  The people doing the work here need just enough work to ensure that when a team is ready to start a project there is enough work there for them to do so. Perhaps a little more for safety’s sake since sometimes projects are longer or shorter than expected. In other words, the development teams should be working as fast as they can, working to their capacity, and pulling work whenever ready. The upstream folks know to create another project to be ready when the developers pull one off the ready queue. 
By managing with pull, the organization focuses on lowering the queues between the different steps. As the queues get smaller, the work flows faster since the biggest delays in most software development is not so much the work itself as much as the time between the steps. To see this, consider how much time people are waiting for answers or approvals.
The Need for Management
It should be apparent that trying to coordinate this sequence of events with its accompanying business dependencies and technical dependencies requires a larger perspective than a team