Portfolio Management

Making sense and value-driven are undoubtedly the most used two words in Agile. All the people aspects (PX), customer-centric issues (CX), and process optimizations (SX) are well documented. But in a business context, you find a lot of incoherence when considering budgeting, funding and return-of-investment.

One of the most common misleading assumptions I meet in my consulting is that a line of business is a service for the organization. That idea is one of the oldest and most resistant beliefs in enterprises. It assumes that those lines are at the service to the “real” value creation flow or to clean up the enterprise from all risks and threads. That’s a valid argument. The problem comes when the budget run starts.

Budgeting is a weird process if you are looking deeply on it. You have to know much you spend a year to run. You have to plan projects, and you have to know how much people you need to cover both activities. Once you finished negotiating that budget (mostly your headcount), then you start your year until next quarter. Every quarter, controlling is coming back to you and asks to reduce your budget by x %. In between, you have new customers, and board demands to fulfil. So, you are cutting all the necessary budgets, starting with third parties. But, on the other hand, you keep the pressure on your team to meet the plan you designed with additional demands and less budget than expected. And because the team is agile and that you learnt that Less is More (fewer people for more work), you believe that the magic happens.

This example sounds quite harmful, and I’m feeling sorry about that. But it is 99% the reality.

Why portfolio management matters?

Portfolio management is part of the Enterprise Experience (EX) aligning the metrics from Organizational Experience (OX) with the Enterprise business strategy: The strategy is deployed top-down from EX to OX. OX design tactics to enable the approach.

The portfolio management approach collects data from such strategies and all other initiatives like transactions or Platform activities to address adequate funding for the right investments. Like any investments, you need to know actuals, expected outcomes, ROI and time-to-market at least.


Some of my customers had very detailed metrics in their portfolios like the names of all sponsors during the whole project/program lifecycle, multiple stages, multiple KPIs. An example from a governmental portfolio was: 

  • Key Success Factors 
    • Critical Success Factors: manage capacity, identify outsourcing candidates (projects, tasks)
    • Possible Success Factors: workflow consolidation, workflow optimization, set up a governance model
  • Necessary conditions
    • Workflow has be visible and known by the whole stakeholders
      • All work is made explicit
      • Visualize flow
    • Measure and remove constraints

Another example of portfolio management in Finance:


  • Adapted right resource allocation to the most value-added initiatives: weak business cases, capacity dissolution along the year (service mindset), never-ending maintenance budgets, lack of product lifecycle management
  • Budget allocation and negotiation based on facts: the absence of arbitrage
  • Highlighting where value is generated: lack of project structures harming value creation
  • Increase early and often deliveries
  • Control budget: rigid budget control, need for adaptive and responsive budget approach, Controlling decoupled for strategy

Points of attention:

  • Strategical project selection (sorting): strategic alignment, investment value, project risk control, project prioritization
  • Maintenance optimization: maintenance budget lead through strategy deployment, consolidation of maintenance budgets
  • Projects optimization
  • Dynamic leadership and governance: right resources at the right time, portfolio governance, regular projects follow-up

In 2008, I discovered the work of Tamara Sulaiman and Brent Barton on AgileEVM. The idea was to use the old concept of Earned Value Management and to adapt it to agile projects (AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle, InfoQ, T.Sulaiman 2007). It has been designed to:

  • “Be lightweight. AgileEVM leverages already existing work metrics, adding little to no work to the current processes.
  • Add value to Agile teams and stakeholders by providing data for decision making.
  • Be cost-effective to implement.
  • Be at least as accurate as current methods.”

In the agile context, most of the team are using artefacts which are “native agile indicators” like:

  • Product Backlog: a list of functional requirements delivering value for the customer, and experience for the users.
  • Velocity: the amount of work that a team delivers during a sprint (iteration, feedback loop).
  • Backlog Size: the sum of all functional requirement estimated in “business value”. “Business value” is an empirical number usually from 999 to 0, helping the customer to prioritize from the must-haves to the nice-to-have.
  • Backlog Size/Velocity = number of sprints needed to deliver the project.
  • Story: stories are “user stories” or a reduced form of a functional requirement from a user perspective. Non-functional requirements like TechStories (technical development), Support, Tasks are never counted; they consume the velocity (sum of delivered stories).
  • Story points = allocated team effort to a story.

The objective of Agile Portfoliomanagement is:

  • To measure outcomes and not outputs
  • To optimize business value creation
  • To prioritize work to maximize business value
  • To organize the delivery for effective shipping to minimize costs
  • To redistribute resources when costs are too high or profit too low

Using key earned value management concepts

  • Integrating costs and schedule performance
  • Financial forecast based on actual costs: consumed costs, consuming rate, time allocation, etc.…
  • Unlike the velocity, the Actual Cost is the cumulative Team Cost
  • Release dates are based on average velocity (velocity = estimate at complete)
  • We assume that (velocity/(total of story points for release) is a good measure for Actual Percent Complete


  • Number of sprints to complete = (backlog size) / (velocity)
  • Expected per cent complete = (Number of complete sprints)/(Number of planned sprints)
  • Planned value for a sprint = (Expected percent complete) x (Total Budget)
  • Actual per cent complete = (Total story points completed)/(Total planned story points)
  • Earned Value = (Actual percent complete) X (Total budget)

I’m quite sure that the Portfoliomanagement purist will have a chock, but the concept is to keep things as simple as possible. Most of these data are available and doesn’t need more than to add the simple formulas in an Excel sheet. If you are smart, you can easily program a query in a tool like Jira to generate those data automatically. It should not be time-consuming but help to see where you have to improve your workflow.

From my experience, here are some simple points to take care of:

  • Stable sprint length: never change the sprint length; it helps nobody. A sprint is a feedback loop and not a release date. You release when the work is complete and don’t wait.
  • Stable teams: if your team members are not fully assigned to the team, and they are distributed through a lot of projects, this is making all your portfolio measures weak. Works flow into teams in agile and not to individuals like in matrix organizations.
  • Don’t add people during a sprint or before the end of a Release Cycle. This action will influence the velocity of your team. Maybe you will have the feeling that you will achieve more, but Conway´s law highlighted that adding people late in a project makes it later. 
  • Have a budget
  • Estimate in Business Value and Story points

Crowd or organization or even program is the upper level of portfolio management. In the Agile portfolio management approach, Product backlogs or Team backlogs (multiple projects, swarms, transactions) are considered like Portfolios.

The “Simple rule” approach inherits the idea to use precisely the same spelling and same format each level. 

From an AO perspective, the experiences can also be visualized in those boards. That visualization will cluster the activities through swim lines to measure the efforts in:

  • Customer experience: mostly swarms and projects
  • Service experience: projects, classes of service
  • Organizational Experience: at “Crowd” to distinguish team activities

Published by PierreENeis

Certified Agile Coach & Trainer, Organization Developer & Advisor

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: