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:

From the trenches: How an issue finds its way into development

This article covers strategic planning using a project portfolio approach and tactical planning including incident management. It's direct from the trenches of development and explains the involvement and planning between stakeholders and development teams.

To dig into it, we need to distinguish two levels of planning:

  1. The strategic level: priorities and roadmaps are planned here. Teams get allocated concerning these priorities. Usually we allocate one team one project at a time (wip limit equals one).
  2. The tactical level: iteration (sprint) planning is done here and we deal with urgent issues from projects which are not allocated (lower priorities). Iterations follow goals of the project which is currently in progress.

As said: we are working under the constraint of "avoid multi-tasking", so each teams only works on one product/project at a time (iteration/sprint).

Stakeholders of an allocated project are are fine, because they are on the development track. If the project is not allocated, stakeholders only have chance of capacity if the issues do not clash with the overall priorities from management. The best thing a stakeholder can do is to plan the issues two weeks ahead of each sprint, so that there is time to break down the requests to get them into the sprint planning during the tactical planning and align them with the overall goals and priorities.

Strategic level

Planning on strategic level means managing priorities on product or project level. This is done with the management and Product Owner team. The result of this planning is an allocation of each an product/project to a team over a given period of time. Other projects keep unassinged and others might be suspended on a waiting list (parking lot) or killed (won't ever be done). 

We use a roadmap for planning and communicating the plan.

The allocation implies the priority. Allocated projects are those ones under development or planned for development. Unassigned are those ones which will be discussed next time and are more likely to get development time, parking lot means that this project is out of development scope and killed projects are entirely removed from priorizaton process.

The strategic planning is an reoccurring meeting - at least every six weeks. 

Tactical level

Tactical planning is about which issues should be done in wich sprint and dealing with change and other (external) effects. This is where reality hits. Yes, there might be requests from not allocated projects like bugs or small improvements. Its the duty of the Product Owner to deal with this requests and not to violate the given priorities from management. Usually most requests are urgent, but not very important, so it is possible to defer those to avoid time slippage of the important project priorities. 

Planning and timing

During development we are working with sprints, which are iterations of two weeks. The scope of those two weeks is mainly fixed because we are focusing a goal. The planning of all issues happens during the first day of the sprint. So if a stakeholder is late with communicating his requests, chances are low that your issue will get important enough to switch scope with an already planned issue.

To avoid that and increase the chance to get those issues planned is easy: be on time. This means stakeholder need to communicate their issues at least one week before each sprint (depending on size of the issue), so that the team is able to refine the issues (break it down, get it ready, get it understood).

Policies

  1. The only person who is ordering the list of issues for the sprint is the Product Owner.
  2. As a stakeholder to get your issues on the planning list, the only counterpart is the Product Owner.
  3. Talking to development team members is about clarification, not planning. Stakeholders should not waste their time trying to sneak into a sprint. This only creates waste and delay.

SVNWNK