🔒 Licensed customer? Enter any InSite Suite key to unlock the full playbook.
PlanInSite — Practitioner Playbook

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.

6 modules covered 3 role-specific guides Jira · Advanced Roadmaps · Any CSV 100% browser-based, no install
🚀

Getting Started

All Roles

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

Step-by-step guide

How to run your first PI planning session

1
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.

2
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.

3
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.

4
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.

5
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 →
🎭

Roles Guide

All Roles

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

All Roles

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.
CSV
Import format
Auto
Column detection
Live
Preview before import
Items per import
🔑 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

Scrum Master Programme

Teams & Capacity is where you define each delivery team, their average velocity (story points per sprint), and your PI configuration. PlanInSite calculates the total PI capacity for each team automatically — this number drives the capacity bars in Backlog Refinement and the utilisation view in PI Loading.

PI Capacity formula
PI Capacity = Velocity × Sprints per PI × Capacity Factor

Key fields in Teams & Capacity

  • Team name — must match exactly how the team appears in your CSV's Team or Component column for auto-assignment to work
  • Average velocity — story points the team completes in a typical sprint. Use the last 3–6 sprint average from SprintINSite Web for accuracy.
  • Sprints per PI — how many delivery sprints in this PI (not counting the IP sprint). Default: 5.
  • Capacity factor (%) — how much of theoretical capacity the team can actually commit. Accounts for leave, ceremonies, and unplanned work. Typical range: 70–85%.
👥

Teams & Capacity screenshot — coming soon

📊 Use SprintINSite Web for velocity

SprintINSite Web calculates your trailing average velocity from Jira sprint data automatically. Export the team velocity report and use those numbers directly in PlanInSite's capacity configuration.

⚡ Capacity factor matters

A team with 40 pts/sprint × 5 sprints = 200pt theoretical PI capacity. At 80% capacity factor, their real PI commitment ceiling is 160 pts. Over-committing the remaining 40 pts creates sprint 4–5 burnout.

🔍

Backlog Refinement

Scrum Master Product Owner

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

Programme Scrum Master

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.

Reading the PI Loading grid

1
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.

2
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.

3
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.

4
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 Playbook
📊

Dashboard

Programme Reporting

The 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

1
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.

2
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.

3
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.

4
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 Playbook
🗂️

CSV Field Guide

All Users

PlanInSite'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.

⚠️ Hard rule: Every item must have a Sprint value to appear in the capacity calculations. Items without a Sprint field value load as unassigned and contribute zero to the capacity bar — even if they have story points.
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.
Common Import Failures
❌ 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.

Recommended Jira JQL for PI Planning Export
JQL starter — active and planned sprints
project = YOUR_PROJECT AND sprint in openSprints() ORDER BY created ASC
JQL — include future planned sprints
project = YOUR_PROJECT AND sprint in openSprints() OR sprint in futureSprints() ORDER BY created ASC
📋 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

Admin

Configuration controls your PI structure — sprints per PI, sprint duration, capacity factor defaults, and the capacity colour thresholds. These settings flow into every capacity calculation in the tool. Set them before importing data and avoid changing them mid-session.

Key configuration settings

1
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.

2
Sprint duration (weeks)

Length of each sprint — typically 1 or 2 weeks. This is used for date range display in the PI Loading view.

3
Default capacity factor (%)

Applied to new teams as a default. Typical range 70–85%. Individual teams can override this in Teams & Capacity.

4
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.

🔒

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