Where Plans
Are Forged.
Everything you need to import your Jira backlog, configure team velocity, run backlog refinement sessions, and load your PI with real capacity data — from Import Data to PI Loading dashboard.
PlanInSite is a fully browser-based PI Planning and capacity management tool. Import your Jira CSV, define your teams and velocity, run a backlog refinement session, and see exactly how much of your PI capacity is committed — all without leaving the browser. No install, no database, no accounts to manage.
What you get out of the box
- CSV import from Jira, Advanced Roadmaps, or any standard sprint board export — field auto-detection included
- Team velocity configuration with sprints-per-PI and capacity factor — calculates PI capacity in story points automatically
- Backlog Refinement workspace — inline editing of items, sprint assignment, and capacity bar per team per sprint
- PI Loading view — colour-coded capacity utilisation per team across all sprints in the PI
- Sprint Summary and Team Summary views — see workload distribution at a glance
- Local storage persistence — your last PI planning session is always waiting when you return
- Dark and light theme
Getting Started walkthrough
Video coming soon
⏱ ~2 minutes · Import, configure teams, load PI
How to run your first PI planning session
Export your sprint backlog from Jira
In Jira, navigate to your board, filter to the items you want to plan, and export as CSV (all fields). Include Issue Key, Summary, Type, Status, Story Points, Assignee, Sprint, Epic Link, and Component for best results.
Import into PlanInSite
Click Import Data, drag-drop your CSV or click to browse. The tool auto-maps Jira's column names. Review the preview table before confirming the import.
Configure your teams
In Teams & Capacity, add each delivery team, set their average velocity (story points per sprint), the number of sprints in your PI, and the capacity factor (%). PlanInSite calculates PI capacity automatically.
Assign items in Backlog Refinement
Use Backlog Refinement to assign items to teams and sprints. The capacity bar for each sprint updates in real time — green means under capacity, amber means approaching limit, red means over-committed.
Review PI Loading
Switch to PI Loading to see your full PI visualised as a grid — teams on rows, sprints in columns, with colour-coded utilisation. This is the view you share with the PI planning room.
💡 Set your PI config first
Before importing items, configure your sprints-per-PI and sprint length in the config sidebar. This ensures capacity calculations are correct from the start — don't change these mid-session.
💡 Items must have story points
Capacity calculations require story points. Import a CSV where all items (or at least all Stories and Tasks) have story points set. Unpointed items count as zero capacity load — they'll hide over-commitment.
Full setup guide is in the licensed playbook
Unlock the complete PI planning workflow, Jira export configuration guide, capacity factor guidance, and multi-team planning tips.
Unlock Full Playbook Module overview →PlanInSite serves three roles in the PI planning process. Each role interacts with the tool differently — understanding your role prevents you wasting time in modules that aren't yours to manage, and helps you ask the right questions during planning sessions.
Scrum Master / Agile Coach
Your home is Teams & Capacity and Backlog Refinement. Configure team velocity, facilitate the sprint loading conversation, and use the capacity bar to keep the team honest about what they're committing to.
Programme / Release Train Manager
PI Loading is your primary view. Across all teams and all sprints, you're ensuring the PI is achievable — no team is overloaded in Sprint 1 and empty in Sprint 5. Use the Dashboard for executive reporting.
Product Owner / Product Manager
Your role is in Import Data and Backlog Refinement — get your prioritised backlog in, assign items to sprints, and work with the Scrum Master to fit them within team capacity. The scoring from PortfolioInSite Web flows directly in.
Shared capabilities across all roles
- Real-time capacity bars — visual commitment indicator per team per sprint, updates as items are assigned
- Sprint Summary and Team Summary toggle — switch views without losing your context
- Inline item editing — update story points, sprint assignment, team, and status without a modal
- Sort and filter across type, team, sprint, and status in the Backlog Refinement table
Import Data is the entry point for every PI planning session. Drop in a CSV from Jira or Advanced Roadmaps and the tool auto-detects your columns. A preview table lets you verify field mapping before committing — preventing silent mismatches that corrupt capacity calculations.
Supported import sources
- Jira board CSV export — standard Jira backlog or board export with all fields. The most common import path.
- Jira Advanced Roadmaps CSV — includes team assignments and sprint planning fields. Best for multi-team PIs already using AR.
- Azure DevOps query export — maps Work Item Type, Title, State, Assigned To, Story Points, and Area Path automatically.
- Any standard CSV — as long as it has an ID/key column, a title/summary, and story points. Use the field mapper for non-standard headers.
🔑 Sprint field is critical
Items without a Sprint value cannot be assigned to a sprint automatically. Either pre-assign sprints in Jira before exporting, or assign them manually in Backlog Refinement after import.
⚠️ Re-importing replaces data
Re-importing a CSV replaces the current dataset. If you've made manual changes in Backlog Refinement, export first or note your assignments before re-importing an updated file.
Teams & Capacity is where you define each delivery team and set the velocity baseline that drives PI capacity planning. Velocity is calculated directly from your imported Jira data using a configurable sprint window — not entered manually. PlanInSite calculates PI capacity per team automatically, driving capacity bars in Backlog Refinement and utilisation in PI Loading.
Team table fields
- Team name — auto-detected from your CSV's Team Name or sprint prefix. Must match the CSV exactly for items to be assigned correctly.
- Avg Velocity — calculated from the Velocity Baseline panel below and shown with its sprint count and "done items only" note. To override it for a team, use Edit — enter the velocity manually and tick Lock so Apply Baseline won't overwrite it. Locked teams display a "✎ manual" marker.
- Sprints per PI — number of delivery sprints in this PI (not counting IP sprint). Default 5, set globally in Config and overridable per team via Edit. This is the planning horizon — it is independent of the velocity sprint divisor below.
- Members — click the 👤 badge to expand the member chip list. Use × to remove cross-team noise. Use + Add to manually include missing members.
Setting the Velocity Baseline — Selected Sprint Window
Choose your sprint window
In the Velocity Baseline panel, enter the sprint names you want to use as your velocity baseline — one per line. Use exact names as they appear in Jira (e.g. FY27-Q1-S3). Aim for 4–6 normal delivery sprints. Exclude practice sprints, Kanban buckets, and IP/planning sprints.
Choose a sprint assignment rule
Select how multi-sprint items are attributed: Latest matching sprint (default — most recent sprint the item appeared in), Earliest matching sprint, or All matching sprints (counts the item in every sprint it was active). Latest is the most defensible for velocity planning.
Set the sprint divisor
The sprint divisor is the denominator for the velocity calculation — the historical averaging window. Default is 6. If you entered 4 sprints in the window but want to express velocity as a 6-sprint average (to be conservative), keep the divisor at 6. If you want raw average across only the sprints you entered, match the divisor to your sprint count. Note: the divisor only affects the calculated velocity — it does not change your PI capacity sprint count, which is set separately by Sprints per PI in Config.
Click Apply Baseline
The preview table updates immediately, showing completed story points per team per sprint and the calculated average velocity per team. Review the numbers before applying — the preview is your quality check. Once satisfied, Apply Baseline writes the velocity to each team and saves it.
Baseline persists without the CSV
Once applied, the velocity baseline is saved to browser storage. If you reload the tool without re-importing the CSV, the saved baseline is used for the preview — your team velocities are retained. To recalculate from fresh data, re-import the CSV and apply again.
⚡ Load QP Validation Window
The Load QP Validation Window button preloads 6 specific sprints spanning the most recent quarter-plus period (FY26-Q4-S4 through FY27-Q1-S4) as a one-click starting point for quarterly planning reviews. Adjust for your specific organisation's sprint names after loading.
🔄 Use Recent Sprints
Use Recent Sprints auto-detects the last 6 sprints from your imported data and populates the sprint window for you. This is the fastest path if your sprint naming is consistent and you just want the most recent completed window without specifying names manually.
⚙️ Advanced velocity filters
Expand Advanced velocity filters to control which issue types count toward velocity (delivery types), which are excluded as planning overhead (Epic, Feature, SAFe Epic by default), which team source to use (Team field, sprint prefix, or both), and an optional allow-list of teams to include in the baseline.
📊 Cross-check with FlowInSite
PlanInSite velocity is aggregate team throughput — the right baseline for forward planning. Use FlowInSite to validate whether the current named team can support that number. If FlowInSite shows new joiners, absent contributors, or falling individual trends, discount the PlanInSite baseline before committing.
📐 Setting a reliable planning velocity
Before committing the baseline:
- Use 4–6 normal delivery sprints. Avoid practice sprints, Kanban buckets, IP/planning sprints, and holiday-affected periods.
- Check the preview table — if a team's sprint-by-sprint numbers look inconsistent, investigate before applying.
- If the team composition has changed materially since the historical window, discount the baseline accordingly.
- The most defensible approach: apply the baseline, validate with FlowInSite, adjust for current team reality, then commit.
Backlog Refinement is the planning workspace where items are assigned to teams and sprints. The capacity bar for each team and sprint updates in real time as you make assignments — giving immediate visual feedback on whether the sprint is green (within capacity), amber (approaching limit), or red (over-committed).
What you can do in Backlog Refinement
- Assign any item to a team and sprint using the inline selectors — no drag-and-drop friction
- Live capacity bar per sprint per team — green (<85%), amber (85–100%), red (>100% of PI capacity per sprint)
- Sprint Summary toggle — see all items grouped by sprint with aggregate story points and team breakdown
- Team Summary toggle — see all items grouped by team with sprint-by-sprint loading
- Filter by type, team, sprint, status, or keyword to focus on specific planning scenarios
- Inline story point editing — adjust estimates directly in the table without a separate modal
- Sort by any column to find unassigned items, high-point items, or specific work types quickly
Backlog Refinement screenshot — coming soon
🚦 Watch the amber zone
Sprints at 85–100% capacity look fine on paper but collapse when an unplanned item arrives. Build a buffer — aim to plan each sprint to ~80%, leaving 20% for emergent work and bugs.
🔢 Unpointed items are invisible
Items without story points show as 0pt in the capacity bar — masking over-commitment. Before your PI planning session, ensure all Stories and Tasks have story point estimates in Jira.
🔄 Sprint distribution matters
Avoid front-loading Sprint 1 with all the hard work. A well-loaded PI builds confidence early (Sprint 1–2 manageable), delivers peak value in the middle (Sprint 3–4), and has capacity buffer for surprises (Sprint 5).
🏷️ Filter to Unassigned first
Start every refinement session by filtering to unassigned items. Work through them systematically before adjusting already-assigned items — this prevents the common trap of endlessly re-shuffling the same items.
PI Loading gives you the helicopter view of the entire PI — all teams on rows, all sprints in columns, with colour-coded capacity utilisation in each cell. This is the view you project in PI planning rooms and send to stakeholders as the committed PI plan. Only planning-level issue types (Feature, Epic, SAFe Epic by default) are eligible for PI Loading — delivery items such as Stories, Tasks, and Bugs remain in the backlog for velocity tracking only. The eligible levels are configurable: in Config → PI Loading Levels you can add levels above (Initiative, Theme, Portfolio Epic) or below (Story, Task, Bug, Sub-task) the default planning band if your organisation plans at a different altitude. This affects PI Loading only — it never changes velocity.
Before you load — set your levels and sizing
Confirm eligible levels and sizing mode
In Config → PI Loading Levels, confirm which hierarchy levels are eligible (default Feature, Epic, SAFe Epic). In Config → T-Shirt Sizing, pick Story Points or PI Planning (sprint-based). In sprint-based mode, each size loads as sprints × that team's velocity, so capacity stays honest without forcing hour estimates.
Reading the PI Loading grid
Green cells — healthy commitment
Team is committed within their sprint capacity for this sprint. Aim for all cells to be green by the end of PI planning — this means no team is over-committed and there's sprint buffer for emergent work.
Amber cells — approaching limit
Team is 85–100% loaded for this sprint. Acceptable if the work is all Must Have, but be careful — a single unplanned item tips this sprint red. Consider shifting one story to the next sprint.
Red cells — over-committed
Team has more story points assigned than their sprint capacity allows. This will cause missed sprint goals. Return to Backlog Refinement, filter to the over-loaded team and sprint, and move items out.
Click to drill down
Click any cell to see the items contributing to that team-sprint's load — a quick way to identify what to move when a sprint is over-committed.
PI Loading guide is in the licensed playbook
Unlock PI Loading interpretation, rebalancing strategies, and export templates for stakeholder reporting.
Unlock Full PlaybookThe Dashboard provides an executive summary of the current PI plan — total story points committed, team utilisation percentages, sprint loading distribution, and item type breakdown. Designed for PI health checks and weekly status reporting during execution.
Dashboard panels
PI summary cards
Total items, total story points, teams configured, sprints in PI, and overall capacity utilisation across the PI — the five numbers you report to leadership every week.
Team utilisation chart
Bar chart showing each team's committed points vs available PI capacity — sorted by utilisation. Over-committed teams show above the 100% line in red.
Sprint loading chart
Line chart of total story points per sprint across the PI — ideal shape is a smooth curve peaking in Sprint 3–4. Spikes in Sprint 1 or valleys in Sprint 5 indicate rebalancing is needed.
Item type breakdown
Donut chart showing the distribution of stories, bugs, tasks, and features in the planned PI. A healthy PI has a mix — a bug-heavy PI signals quality debt that will impact velocity mid-PI.
Dashboard guide is in the licensed playbook
Unlock Dashboard interpretation, PI health benchmarks, and weekly reporting workflow templates.
Unlock Full PlaybookPlanInSite's import engine auto-detects Jira's standard column names. Understanding which fields are critical and which are optional prevents the most common import failures — especially the "0 rows loaded" scenario caused by missing sprint data or unrecognised column names.
| Field | Requirement | Recognised column names | Notes |
|---|---|---|---|
| Issue Key | Required | Issue key, ID, Key, Number, Ticket |
Used as the unique row identifier. Must be present in every row. |
| Summary | Required | Summary, Title, Name, Subject |
The display title of the item. Truncated in the table at 80 chars. |
| Sprint | Required | Sprint, Iteration, Sprint Name |
Items without a Sprint value cannot be placed in the capacity bar. Must be present. |
| Story Points | Required | Story Points, Story point estimate, Points, Effort, Size, Estimate |
Drives all capacity calculations. Items with no story points count as 0pt — hiding over-commitment. |
| Issue Type | Recommended | Issue Type, Type, Work Item Type |
Used for type-filter in Backlog Refinement and type breakdown in Dashboard. |
| Status | Recommended | Status, State, Resolution |
Used for status filter and done/in-progress/to-do grouping. |
| Team / Component | Recommended | Team, Component/s, Component, Squad, Area Path |
Auto-assigns items to teams if the value matches a configured team name exactly (case-insensitive). |
| Assignee | Optional | Assignee, Owner, Assigned To |
Used for assignee filter in Backlog Refinement. |
| Epic Link | Optional | Epic Link, Epic, Parent, Epic Name |
Used for epic filter grouping in Backlog Refinement. |
❌ Zero rows imported
Most common cause: Sprint column is missing or uses a non-standard header (e.g. "Iteration" not auto-detected). Check your CSV header row — rename the sprint column to Sprint before re-importing.
❌ All items show as 0 pts
Story points column header not recognised. Common culprits: story_points (underscore), SP, or a custom field name like T-Shirt Size. Rename to Story Points in the CSV before importing.
⚠️ QA/SIT boards — zero sprint items
Test boards in Jira often have no sprint assigned (items sit in a testing workflow, not a sprint). These export with blank Sprint fields. Pre-filter your export to only include sprint items, or assign sprints in Jira first.
⚠️ Custom team field not mapping
If your team name is in a custom Jira field (e.g. "Fixed By", "Squad"), it won't auto-map to the Team column. Export the field and rename its column header to Team or Component before importing.
📋 Export all fields
When exporting from Jira, choose "Export to CSV (all fields)" not "current fields" — this ensures Sprint, Story Points, and Component are included even if they're not visible on your current board view.
🔄 Advanced Roadmaps export
If you're using Jira Advanced Roadmaps, use the AR CSV export which includes team and sprint planning fields in the correct format. This is the cleanest import path for multi-team PIs.
Configuration controls your PI structure — sprints per PI, sprint duration, capacity factor defaults, and the capacity colour thresholds — plus which hierarchy levels PI Loading accepts, how T-shirt sizes convert to points, and your Jira Site URL. These settings flow into every capacity calculation in the tool. Set them before importing data and avoid changing them mid-session. Open Configuration from the ⚙ Config button at the top right.
📐 T-Shirt Sizing — choosing a mode
PlanInSite supports two sizing approaches, set in Config → T-Shirt Sizing. Both feed the same capacity bars — the difference is how a size becomes points.
Story Points
Each size XS–XXL maps to a fixed point value you set (defaults 1 / 2 / 3 / 5 / 8 / 13). Use this when teams already estimate planning items in story points and you want a single shared scale across all teams.
PI Planning (sprint-based)
For ART-level planning a 5-size scale — XS, S, M, L, XL — gives enough spread to compare relative size without false precision. Each size is defined as a sprint range, and PI Loading converts it to points per team:
The default scale:
- XS (≈0.5 sprint) — very small; likely finished inside a sprint or less.
- S (≈1 sprint) — small; roughly one sprint.
- M (≈3 sprints) — medium; about 2–4 sprints.
- L (≈5.5 sprints) — large; about 5–6 sprints.
- XL (≈6 sprints) — too big for comfortable commitment; split before PI Planning. PI Loading flags any XL item with a "split before PI" warning.
Worked example:
Vanguard's velocity is 60 SP/sprint. An M feature (3 sprints) loads as 3 × 60 = 180 points against their capacity. The COPS team, at 85 SP/sprint, would load the same M feature at 3 × 85 = 255 points — the size stays relative to scope while the points stay honest to each team's throughput. No hidden conversion to hours.
Using it well in the room:
- Keep the scale local and relative — compare scope, complexity and risk against other items in the same PI, not against a clock.
- Size for comparison, not exact estimation. The goal is to spot the big items and the misfits quickly.
- Treat XL as a prompt to split. If it can't be split before PI Planning, flag it as a risk and plan the spike to break it down.
- Adjust the per-size sprint values in Config to match how your ART actually delivers — the defaults are a starting point.
Key configuration settings
Sprints per PI
How many delivery sprints in this Program Increment — not including the IP sprint. SAFe standard is 4 or 5. This drives the PI Loading grid column count.
Sprint duration (weeks)
Length of each sprint — typically 1 or 2 weeks. This is used for date range display in the PI Loading view.
Default capacity factor (%)
Applied to new teams as a default. Typical range 70–85%. Individual teams can override this in Teams & Capacity.
Capacity colour thresholds
The amber threshold (default 85%) and red threshold (default 100%) can be adjusted to match your organisation's risk tolerance for sprint over-commitment.
PI Loading Levels
Choose which backlog hierarchy levels PI Loading can search and commit. The default planning band is Feature, Epic, SAFe Epic. Tick levels above (Initiative, Theme, Portfolio Epic) or below (Story, Task, Bug, Sub-task) only if you plan at that altitude. This controls PI Loading eligibility only and never alters velocity, which is driven by your delivery issue types.
T-Shirt Sizing mode
Switch between Story Points (each size maps to a fixed point value) and PI Planning (sprint-based) (each size is a sprint range that loads as sprints × the team's velocity). See the dedicated walkthrough below.
Jira Site URL
Enter your Jira base URL (e.g. https://yourco.atlassian.net). Every issue key in the tool then becomes a clickable link straight to the issue in Jira. The value persists in browser storage and applies across all tabs.
Configuration guide is in the licensed playbook
Unlock capacity factor guidance, PI structure recommendations for SAFe vs Scrum, and organisation-specific calibration templates.
Unlock Full Playbook