--- title: "Forecast a Single Team’s Work on Shared Epics" canonical: "https://support.55degrees.se/space/SP/3964863332/Forecast%20a%20Single%20Team%E2%80%99s%20Work%20on%20Shared%20Epics" format: markdown --- 🔵 **From a configuration lens:** Forecasting Epics with child items filtered to include only work from a specific team. ***Note: ****This works at any level of the hierarchy as long as the correct item types are chosen: eg. Initiatives → Epics* --- ![Screenshot 2025-07-15 at 09.26.36.png](media://de92e1ed-30e5-4081-a129-c1813121e3dc) ### ✅ Scenario You want to forecast **only the portion of work** that a specific team is responsible for—even though the **Epic itself is shared across multiple teams**. Your goal is to understand when **your team’s contribution** to the Epic will be done, not when the Epic is fully complete. This is common in cross-functional work where several teams contribute to the same Epic but manage their delivery independently. **📌 Example** You have Epics in a shared Jira space, and both `TIS` and `CS` teams have stories within the same Epic(s). Team TIS wants to forecast **only their work** to understand when their contribution will be finished. --- ### 🧭 Step 1: Choose the Efforts to Forecast - **Forecasted item type**: Epic - **Where they live (Data Source)**: Usually in a shared Jira space or per-team spaces* *(e.g., `Teams in Space`) - **Why**: You still want to track and forecast at the Epic level—even if multiple teams contribute to the work. ![Screenshot 2025-12-04 at 16.01.41.png](media://5dc0baf1-e31b-42ef-8672-63af739bb216) **You can optionally:** - Customize the fields shown in the forecast table (e.g., *Team*, *Fix Version*, *Owner*) - Use advanced mode to: - Filter the Epics further (e.g., only those tagged with a specific label or initiative) - Override the default status category mapping to define custom “in progress” or “done” states --- ### 🔗 Step 2: Define How Work Is Connected We need to identify the **child items** that represent the remaining work for each Epic. These are often *Stories, Tasks,* or *Bugs*. - **Default connection**: Use the **Parent field** to connect stories/tasks to their Epic - **Work item type**: *Stories, Bugs, Tasks, etc.* - **Scope**: These items may live in the same space as the Epic or in other spaces. > ⚠️ **Important mindset shift** > In Step 1, you selected the Epics to forecast. > In Step 2, we are not drilling into those Epics directly—we are scanning **all Jira items** to find work items whose **Parent field matches one of the forecasted Epics**. **📌 Example** If Team TIS owns three stories in a shared Epic, we want to find only those three stories when calculating the forecast—not the full set of child items in the Epic. #### 🔍 Required: Filter to the Team's Work To ensure you are only forecasting **Team TIS’s** portion of the work, you **must apply a filter** that identifies which child items belong to that team. Example JQL filter: ``` space IN (TIS) ``` ![Screenshot 2025-12-04 at 16.05.26.png](media://de093953-d262-4d09-8e85-255107e4a696) > ℹ️ Read more on how to use JQL filters in Portfolio Forecaster [here](https://55degrees.atlassian.net/wiki/spaces/SPP/pages/3964864540) **This filter will:** - Limit the remaining work counted in the forecast - Ensure historical throughput only includes work done by the team **You can additionally:** - Combine multiple link types if needed (e.g., `implements`, `relates to`) - Redefine what counts as “done” for these child items (e.g., treat “Ready for Test” as complete) --- ### 📈 Step 3: Use Historical Data We’ll now look for **completed work** that matches the same pattern used in Step 2 to calculate throughput. - **Default behavior**: Uses the same filters as Step 2, but finds completed child items instead of in-progress ones - **Lookback window**: Set the appropriate number of days (e.g., 90, 180, 365) based on your team’s pace - **Goal**: Ensure that we’re comparing **Team A’s work** to other completed work from Team A—not to all work in shared Epics **You can optionally:** - Override the historical data source (e.g., use another space where Team A has more finished work) - Expand the time window if your team has slower throughput > ⚠️ **Known Issue** > ⚠️ Step 2 overrides are not being applied to Step 3. ![Screenshot 2025-07-15 at 09.33.29.png](media://d8884b6f-9940-42c9-b7f3-d8b02630b3fe) > ✅ **Workaround** > ✅ Use the override to pull what you want in the meantime. > ✅ > ✅ *In the example below, the override will ensure that you’re pulling Bugs, Stories, Tasks that are finished from the TIS space but only if the parent of those items is also in TIS. If you don’t include this JQL query override then you’ll get all of TIS stories, bugs, and tasks and not just ones required to complete Epics in TIS.* > ✅ > ✅ 📔 Read more on how to use JQL filters in Portfolio Forecaster [here](https://55degrees.atlassian.net/wiki/spaces/SPP/pages/3964864540). ![Screenshot 2025-07-15 at 09.34.44.png](media://5e7676cf-eb79-4d82-8c7f-d9205b522d97) --- ### 💡 Tips & Watchouts - Make sure **team ownership is clearly defined** (e.g., with a `Team` field, label, or component) - Filtering by team is essential—without it, you’ll forecast the **entire Epic**, not just one team’s portion - This pattern works best when team work is not too tightly interwoven (e.g., minimal dependencies across teams) - Be clear when communicating the results: this forecast answers *“when will this team’s work on the Epic finish?”*, not *“when will the whole Epic be done?”* --- ### 👀 Verifying the 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.