---
title: "Forecast Program-Level Work"
canonical: "https://support.55degrees.se/space/SP/3964863247/Forecast%20Program-Level%20Work"
format: markdown
---
🔵 **From a configuration lens:** Forecasting items in one space with the work to be done for those items spread across many spaces.

---

### ✅ Scenario

You want to forecast high-level efforts—like **Initiatives, Features,** or **Goals**—that are all tracked in a **single Jira space**, while the work to be done for those efforts lives in **multiple other spaces**.

This is a common setup when a central team (like Product Management) owns the planning and tracking of key deliverables, but the actual delivery work is distributed across many teams or departments.

**📌 Example**

You have **Initiatives** tracked in a Jira space called *Product Management*, and the related **Epics** (the work to be done) span multiple spaces such as Design, Engineering, Marketing, and Sales Enablement.

![Screenshot 2025-07-14 at 16.39.53.png](media://fb29e722-d9dd-43ff-bced-6a64deca3c6f)

---

### 🧭 Step 1: Choose the Efforts to Forecast

- **Forecasted item type**: Any high-level planning item (e.g., *Initiative*)
- **Where they live**: A single Jira space (e.g., *Product Management*)
- **Why**: Narrowing the scope to one space helps keep the configuration clean, especially when using space-based filters instead of boards.

![Screenshot 2025-12-04 at 15.14.57.png](media://e44b727a-987a-4f05-8725-d5ce4409b8b4)

**You can optionally:**

- Customize the fields shown in the forecast table (e.g., *Fix Version*, *Owner Team*)
- Use **Advanced Mode** to:
  - Filter forecasted items further (e.g., only Initiatives with a certain *component* or *label*)
  - Adjust what counts as **“in progress”** or **“done”** by overriding default status categories with specific workflow statuses

> ℹ️ Read more on how to use JQL filters in Portfolio Forecaster [here](https://55degrees.atlassian.net/wiki/spaces/SPP/pages/3964864540)

---

### 🔗 Step 2: Define How Work Is Connected

Now that you’ve selected the items to forecast (e.g., Initiatives), it’s time to define how to find the work to be done for each of them—this is the remaining work that drives the forecast.

- **Default connection**: Use the **Parent field** to link each work item (e.g., Epic) to its corresponding forecasted item (e.g., Initiative)
- **Work item type**: The item type representing the remaining work—e.g., *Epics*
- **Scope**: These work items can be in *any Jira space*, as long as their **Parent field matches** one of the forecasted items

> ⚠️ **Important mindset shift**  
> In Step 1, you selected the items to forecast.  
> In Step 2, you are **not** looking inside those items to find linked items.  
> Instead, we scan all Jira items and pull in any that match your selected connection type (e.g., Parent field or item link) **and** are linked to one of the forecasted items.

**📌 Example**

If you selected Initiatives in the *Product Management* space as your forecasted items, then by default we find all Epics across Jira that list those Initiatives in their **Parent field**.

![Screenshot 2025-12-04 at 15.15.38.png](media://a6972395-6d0f-400d-8005-f9e351d5956a)

**You can optionally:**

- Use other connection types (e.g., `implements`, `relates to`) in addition to or instead of the Parent field
- Refine the included work using filters (e.g., only Epics with `component = Marketing`)
- Customize what counts as “done” (e.g., treat “Ready for Launch” as complete instead of the default status category)

---

### 📈 Step 3: Use Historical Data

- **Default behavior**: We reuse your Step 2 configuration, but instead of looking for in-progress items, we look for **completed** items that match the same structure
- **Lookback window**: Specify how far back to search for completed items (e.g., 90 days, 180 days, etc.) - *The higher up in the hierarchy you go, the more time you may need to get enough completed items as they normally are completed at a slower rate than lower-hierarchy items.*
- **Goal**: Find past, completed work that matches the same pattern as your current remaining work—ensuring your forecast is based on representative historical throughput.

![Screenshot 2025-12-04 at 15.17.43.png](media://67f269e3-74fa-4252-a73c-d40959e3ed6d)

**You can optionally:**

- Override this to use a different historical source (e.g., if the current space is new or lacks finished work).

![Screenshot 2025-12-04 at 15.19.04.png](media://0967795d-760d-462b-9529-1600354ba26e)


---

### 💡 Tips & Watchouts

- Using a **space filter** (instead of a board) in Step 1 keeps dropdowns clean and easier to manage
- Parent/child relationships are controlled by your hierarchy setup in Jira. If your hierarchy is Intiative -> Epics → Standard Work Item Types → Subtasks then you’ll need to make sure you choose a relevant item type if you choose the Parent link.
- You don’t need to limit where child items live—they can be scattered across your Jira instance
- This pattern is great for *program-level forecasting* that spans functional areas or departments

---

### 👀  Verifying your forecast configuration

- Open the info box on the forecast and read about what’s been configured for
  - the items to forecast or “parents” (step 1),
  - the work to be done or “children” (step 2) and
  - the historical throughput (step 3).
- Ensure the table rows only show expected items that match the configuration.   
Please note that items matching these conditions will be excluded:
  - not started or completed items (although if you’re in Scenario Planning mode then you can see not started items)
  - items with no remaining work found.
- Validate the right work to be done is selected (especially if you used a non-default configuration) by clicking on at least a few of the numbers in the “To Do” column to see the items reflected there.
- Click on the open new window icon next to Historical Throughput in the info box OR export the throughput data from the action menu to see what throughput has been used for the simulation.