Managing portfolio with roadmaps and teams

If you are working with teams, assign products or project to them and want to structure your planning process on a higher level, you might consider using a roadmap for your portfolio level (I use the term product equal to project).

To give product portfolio a sound basis you might use a roadmap to visualise the load factor of your teams. Just give every team its own lane and assign the planned products to the teams.

If you are doing this for the first time, you might wonder on how much products in parallel your teams are working. It is reasonable to think about the reduction of product multitasking to increase productivity.

For those products you are not sure if they are worth working on them yet, you have three choices:

  1. Keep them unassigned (unstaffed), but put them on the "should be considered soon for implementation list". Those products should be discussed in a portfolio meeting.
  2. Put them on a parking lot, if you do not want decide soon about the implementation but do not want to forget about them.
  3. Kill them, if you don't want to think about them in the future anymore or if they will never get the priority to get capacity.
This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

Here comes a little more description about the used lanes in the roadmap:

The team lanes

Within the team lanes you assign products to the teams. As long as a team works and is planned on a given product no other product should interfere. I recommend you to set a work in process limit (wip limit) for each team. This should speed you up and reduce waste.

Unassigned

Each product which could not be staffed by a team stays unassigned. Unassigned indicates: you want to work on this product, but do not know how to stuff it yet. In future discussion these products might get development time.

Parking Lot

You've got a product which is interesting enough not to kill it but doesn't have the priority to be developed you put it on the parking lot. These products might be good opportunities but hard to realise in practice.

Killed

If you refuse to work on a product, kill it. This means throw it away. Do not bother yourself in the future with concerns or thoughts about this product.

If you decide about your product portfolio, share it. Communicate it and make it visible as much as you can. If you want alignment, people must know about your decisions and for sure you have to defend it against the drift of the daily business. You might provide guidance for people and create policies for them. If you want to read about an example, I recommend to read about "how an issue finds its way into development".

If you are working in a hierarchical organisation, management should support or communicate the decisions. If communication is not aligned chances are hight that your portfolio gets sacked. Or just to stick with Gojko Adzic:

If communication fails, everthing else is just painting the corps.

SVNWNK

Sources: