Pages Navigation Menu

Agile Portfolio Planning

Senior managers — the people who make strategic product decisions — need to know when they can expect those products to release. The organization of current product releases against a timeline is a project portfolio. And, planning the project portfolio in an agile environment is different — but not harder — than planning the project portfolio in a non-agile environment.

With non-agile projects, we tend to plan and use the portfolio as an ordered list of projects slotted into timeslots. But with agile projects, we have the opportunity to replan the portfolio as we understand the projects and the market. Instead of planning a series of projects, we can slot a series of features into a particular iteration and estimate the number of iterations required before a release.

The hardest part of the portfolio work is making sure we (the managers, project managers, and product owners) have gathered all the work. The work in an organization consists of project work, ad hoc work, periodic work, ongoing work, and management work. I want to make sure our portfolio reflects all the work we do, including the unstaffed work, so we can make good decisions about when to start which work.

I use these questions when organizing an agile portfolio:

  1. How strategically important is this set of work? I want to make sure we’re planning and completing the strategically important work first.
  2. Do all these things look like they’ll fit into one iteration? I’m not asking the project teams for an unbreakable commitment but a ballpark estimate. One of the problems I’ve seen with teams new to agile is that they overestimate what they can finish in an iteration. So as soon as one iteration is complete, the portfolio is incorrect.
  3. How does this iteration fit into all the releases we’d like to do? Although each iteration is releaseable, I want to choose when to allow the customers or users to take a release. 4. Is there anything preventing us from completing a particular iteration? Or is there a reason to order feaures in a particular order? This is where I’ll hear about obstacles to starting or finishing an iteration or completing a customer release.

Once I have the answers to these questions, I can rank the different sets of work into the iterations and slot them roughly into their expected dates. If I’m working as the senior software manager, I make sure I work with the product owners and the project managers. Sometimes other people (but not the product owners), such as salespeople or marketing communications or technical support are also affected by the project portfolio work, so I invite them to participate in the meeting. (More often, I invite them to see what we’ve done and let us know if that doesn’t work for them.)

If I’m working as a program manager, someone who integrates several projects or releases into one coherent whole, I’ll work with the project managers — the people responsible for each piece of the deliverable — to make sure we have an integrated plan.

I expect to use the project portfolio as a guideline and to change it as each project’s requirements for each iteration changes. I use the same principle the project teams use: nothing can change during an iteration but we can move things around as often as we want for the time after this iteration.

When I’m working in a large organization, where many of us have project portfolios, I do the same kind of work on my own, for my part of the organization. In addition, I meet with the other portfolio owners on a regular basis. We review the work we’re all doing to see if we share priorities. I tend to meet once in an iteration.

This review works best if we’ve synchronized our iterations so we can always meet at the same time relative to our iterations, but we can’t always do that. So we look at the risks if we have to change our meeting time and act based on those risks.

I tend to have multiple views of the portfolio, from a yearly view without much detail for what’s in each iteration, down to a rolling wave four- to six-week portfolio. I also have quarterly views, especially if we’re trying to plan customer releases.

Agile portfolio planning helps senior managers react quickly to changes in the projects and replan the portfolio. I find that agile portfolio planning reduces the number of surprises and allows the organization to release products close to or on time, even if we choose to reduce the number of iterations.

© 2006 Johanna Rothman.

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

One Comment

  1. Hi Johanna,
    thank you for the good information. Could you please suggest how the project charter should be used in Agile environment? Who is the audience? Should it be approved by a senior management? Everybody is saying that we don’t need to include Cost information in the Agile project Charter. Where we need to include this information then? Should we have a different document with this information ( and all other relevant informaton) for senior management to apparove and create a project charter without cost information after senior management approval?

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>