← All Posts
Resource Management

Forecasting a Mixed Agile and Traditional Portfolio

By Jim Cox ·

Forecasting a Mixed Agile and Traditional Portfolio

When Can the Next Project Start?

Portfolio managers get asked two questions every month: when will this finish, and when can we start the next one? With sprint teams and traditional projects sharing the same people, most can only guess. Here is a monthly routine that turns one resource pool into forecast finish dates and a defensible start sequence.

The two questions a portfolio manager can't answer today

Every portfolio review comes back to the same two questions.

  1. When will current work finish?
  2. When can new work start?

Both depend on the same thing: how much of the shared resource pool is committed, month by month, and to what. In most organizations that picture is split. Agile teams run sprints and plan four weeks ahead. Traditional Project and Resource Management (Traditional PM from here on) teams run detailed schedules out to the end of the horizon. Nobody holds the combined view, so start dates get set by optimism and finish dates by hope.

Our companion article, Why Agile and Traditional Managers Lose Sight of Resource Supply and Demand, and How to Fix It, explains why managers lose sight of supply and demand, and how one shared pool in Timebars Ltd. tools fixes it. This article turns that pool into dates.

The setup: one pool in Costbars

Costbars, our portfolio management tool, is the master. One Costbars dataset holds:

  • The resource pool. Every named person and every generic role, each with a start and finish date, so joiners and leavers change supply in the right month.
  • The master schedule. One bar per project, in flight or proposed, so portfolio-level demand sits against that pool.

There is one pool, and it is maintained in one place. Detailed schedules elsewhere use the same resource IDs, so their demand lines up with it.

Feeding the pool: three kinds of team

Demand only counts when it is a resource allocation. Each kind of team gets its allocations into the picture differently.

  • Traditional PM projects in Timebars. The project manager schedules in Timebars, our resource scheduler. Early on, allocations use generic roles ("two developers, one tester"). Named people replace them as the work firms up.
  • Agile teams running sprints in Timebars. Each sprint is a bar with the team allocated to it. The current sprint carries named people in detail, and later sprints carry summary allocations by role. Demand flows straight into the grid with no extra step.
  • Agile teams running sprints in Agilebars. Agilebars keeps sprints light: it has no resource allocations, so its work never reaches the supply and demand grid. Instead, the squad gets a summary bar in the Costbars master, with high-level allocations by role. That bar can be broken down into sprints, and it is updated by hand each month.

Users have the flexibility to choose. The trade-off is simple: Agilebars gives the team the Kanban board and burndown, at the price of a monthly update in Costbars.

Forecasting finishes

  • Traditional PM projects. Each status update in Timebars moves work across the Report Date. Completed work becomes actual, remaining work is rescheduled, and the forecast finish moves with it. The forecast finish is a calculation, not a guess.
  • Agilebars teams. Velocity and the burndown chart give a forecast finish for the backlog. Set the end of the squad's summary bar in Costbars to that date, and the portfolio sees when the team frees up.
  • Small teams that want one file. Bulk Manage Bars can transfer a project's current update to Costbars as a transferBars file, which you drop on the import panel. It suits small projects. For larger ones, use the Enterprise Dashboard below.

Seeing it all together

Each team publishes its data to Timebars Cloud as a pubset. In the Enterprise Dashboard, a Dashboard Source combines pubsets from Costbars, Timebars and Agilebars into one portfolio view.

  • Capacity vs Demand shows supply and demand by week and role across every pubset in the source.
  • Burndown reports include the Agilebars sprints, so agile progress sits beside the schedules.
  • Agilebars pubsets add progress, not demand. That comes from the squad's summary bar in Costbars.

Forecasting starts

New projects start when the pool can carry them. Costbars works through that in three steps on its PPM page.

  1. Score. Each proposal gets a Strategic Value score and an Ability to Execute score, from 0 to 100, plus a recommendation to approve, review or reject.
  2. Level. Open the Leveling view, then drag project bars and watch the variance recalculate live. Keep going until demand sits within supply, with high-priority projects placed first. Leveling is manual: there is no automatic leveler, because the trade-offs are business decisions.
  3. Sequence. The Portfolio Status and Balancing Report lists each approved project's readiness, its Earliest Start (from its dependencies) and a recommended start sequence (from priority, dependencies and readiness).

The result is a start date you can defend. "Project B starts in September, because that is when the platform squad's bar ends and senior backend variance turns positive" is a plan, not a promise.

The monthly routine

  1. Status update. Project managers update their Timebars schedules to the Report Date.
  2. Agile capacity. Each Agilebars team lead updates the squad's summary bar in Costbars, from velocity and the burndown.
  3. Publish. Every team publishes its pubset.
  4. Review variance. The portfolio manager reads Capacity vs Demand by role and month.
  5. Level. Drag proposed and in-flight project bars in the Costbars Leveling view until the variance is acceptable.
  6. Approve starts. Approve the highest-priority projects that are ready to start and fit the pool, in the recommended sequence.

The rules teams must agree to

  • No allocation, no demand. Work that isn't allocated to a resource doesn't exist as far as the pool is concerned.
  • One pool, maintained in Costbars. Teams don't keep their own versions of the pool.
  • Agilebars teams commit to the monthly update. If they won't, they should run their sprints in Timebars instead.
  • Leveling is a decision, not an algorithm. The grid shows the consequences. People with authority choose between hiring, descoping and moving dates.

Where to start