Skip to content


  • Add this article to your LinkedIn page
  • Add this article to your Twitter feed
  • Add this article to your Facebook page
  • Email this article
  • View or print a PDF of this page
  • Share further
  • Add this article to your Pinterest board
  • Add this article to your Google page
  • Share this article on Reddit
  • Share this article on StumbleUpon
  • Bookmark this page

Running portfolio planning as an Agile initiative

Most organisations still run the traditional annual cycles of crystal ball gazing, translating strategy into strategic objectives and then planning the portfolio to deliver them, along with budgeting for resources and forecasting costs. This takes a good two to three months and a lot of effort across the organisation at times of rapid change, and major shifts in their industries, customer behaviour and markets. However, it is far from clear that this is the best approach for portfolio planning.

By their very nature, portfolios are collections of projects and programmes aimed at delivering specific strategic objectives. Some of them are multi-year, some multi-functional and, in bigger organisations, they span countries and continents. The number of variables influencing them at any point is huge, and quite unpredictable.

So how can a predetermined process, designed to give a snapshot in time, still create meaningful portfolios? The answer is simple: it can’t. What is needed is agile planning and forecasting at the portfolio level. 

Although strategic objectives do not change significantly, the way they are achieved can alter over time. New technologies, changing market dynamics or significant internal change can mean the approach has to be completely different. This, in turn, means that the portfolio initiatives need to be broken into bite size chunks and developed in a dynamic way, with the end users, internal clients and other stakeholders having a greater say during the process. The ability to switch initiatives on and off, as the end client needs to change things or finds a better way, has to be preserved throughout the delivery cycle.

That means portfolio planning could and should be run as an iterative Agile initiative where:

  • planning efforts focus on the planning itself as a process, the analysis and interaction that goes into it – the plan is then a by-product 

  • good planning creates go/no go/stop/start/continue decisions, trade-offs and assignments – not just plans

  • lean agile budgeting ensures that value stream owners can use the funds assigned to them in a far more flexible way, without the need to tie exact amounts to named projects but still get the functionality they require

  • portfolio backlogs are reviewed and slimmed down, and items deleted as more detail emerges throughout the year. This avoids sprints that will not create value

  • cross-functional stories are developed with the business over time, as the specialist functional knowledge on how to scale a particular challenge grows.

One assignment we are working on illustrates the challenge. It comprises 27 projects and programmes of varying sizes and spend, with running times between 10 months and three years. Only one of them is run as an Agile programme, the rest use classic waterfall methods with varying degrees of success and relevance. As we are approaching the annual planning cycle and subsequently, the shaping of the portfolio, we have realised that some of them are not going to contribute to the organisation’s strategic objectives (directly or indirectly). 

Many of these have significant cost overruns and some are delivering solutions that will be automatically obsolete at the point of implementation. The question is why the organisation is persevering with them. The simple answer is: “We are so close to delivery, we already paid for bespoke bits of software to be written, and invested three years’ worth of resource – we couldn’t possibly throw all of it away and reinvest elsewhere.” 

Counterintuitive as it sounds, it could and should be thrown way. An Agile approach can help organisations address these issues and provide a way to re-plan and reshape their portfolio to deliver more relevant, cost efficient solutions that users feel engaged with and connected to. To do this they need to:

•only attach monetary values to quarterly estimates and keep the budgets at value stream owner level, encouraging collaboration and seamless transfers of unused funds amongst value streams where it makes most sense 

  • carry out the benefits tracking exercise at quarterly intervals and adjusting the programme backlog to fit the needs at that point  
  • estimate the effort to write the programme backlog in a focused timeframe, in weeks not in months, and start the analysis early to ensure that the urgent and time-sensitive programmes are worth including in the portfolio, based on benefits they deliver 
  • invite suppliers, functional specialists and scrum teams to go through the planning exercises together – this would certainly bring much more reliable estimates across the portfolio
  • start to use release plans and iterations, aiming for more granularity as the details emerge. 

This approach brings real benefits by creating a culture that thinks on its feet, questions the well laid out but stale plans and focuses time and effort on achievable, near-term results. 

Portfolios planned in an Agile way stand a better chance of delivering more relevant, timely and cost efficient outputs and deliverables. That means we need to embrace Agile right at the start of the portfolio planning and budgeting cycle, and not be bound by the traditional annual approach to business planning. 

Find out more about the author of this article, Maya Bankovich.

Contact the Agile team

By using this website, you accept the use of cookies. For more information on how to manage cookies, please read our privacy policy.