StrataTree is a web-based hierarchical planning application that enables easier and more effective project scoping and planning.
StrataTree helps teams transform large or complex backlogs into clear, structured delivery plans by organizing work around users, value, workflows, and delivery increments. StrataTree is typically used before and alongside execution tools such as Jira or Azure DevOps.
StrataTree enables teams to perform project scoping and planning in ways that are easier to understand, easier to collaborate on, and more effective at producing executable delivery plans.
By allowing teams to plan directly in a structured environment that can synchronize with execution tools, StrataTree eliminates the common two-step process of planning in spreadsheets, whiteboards, or graphical tools and then re-entering the same information into execution systems such as Jira or Azure DevOps. In practice, this can save teams hours of manual effort per sprint while also reducing transcription errors and structural drift.
Most planning, project management, and work execution tools present work as flat lists or workflow states.
StrataTree enables the planning-first lifecycle by providing a multi-dimensional view of your project plan that helps teams prioritize effectively and clearly distinguish required functionality from optional functionality.
This allows teams to reason about scope, priority, and release viability in one place, before committing work to execution systems.
Yet, StrataTree is more than just a planning tool. It is the first tool to enable the planning lifecycle by removing the barrier to structured planning across the organization. It is suitable for any type of project or event planning, and it lets your organization standardize around a proven, generally applicable approach.
Planning rarely feels difficult when work is small. As scope expands across teams, Features, and releases, list-based planning begins to fail because it removes structural context.
At scale, backlogs become large collections of loosely related items. This makes it difficult to reason about sequencing, dependencies, and release viability. Prioritization becomes subjective because relationships between work items are not visible.
Most backlog tools are optimized for tracking execution rather than designing work structure. They answer questions like:
They are less effective at answering structural planning questions such as:
StrataTree addresses this by allowing teams to organize work hierarchically, enabling planning decisions to be made with full visibility into scope, relationships, and delivery sequencing before execution begins.
StrataTree is built around the StrataMap®, a hierarchical planning artifact that represents work organized around intermediate goals and user value.
StrataTree is not a replacement for execution tools such as Jira or Azure DevOps. It is used to design and validate work structure before execution begins.
Typical layers include:
These definitions are optimized for planning clarity and delivery decision-making.
BusinessReason) — the user-story-sentence "why": the purpose a user or stakeholder has for wanting this Story delivered. Business Reason is the analogue of the "so that" clause in traditional user story format.StrataTree planning progresses from users → benefits → Features → workflows → Storys.
The objective is to define:
Before defining implementation work.
Planning begins by identifying anyone who directly interacts with the system. Teams brainstorm broadly and avoid filtering ideas.
Brainstorming typically continues until the time between new role suggestions increases noticeably (often more than about five seconds). This usually indicates it is time to stop brainstorming and begin consolidation.
Using patterns such as X is-a Y, similar roles are grouped into meaningful user categories.
Example (Drill Instructor Educational Game): Initial brainstorm may include Child, Student, Girl, Boy, Adult, Illiterate Adult, Teacher, Dog.
Using X is-a Y allows refinement into roles such as Student, Teacher, or Parent. If the primary behavior is playing a game for enjoyment, Student may be refined to Player.
Define the primary reason each user would use the product.
Example:
| Role | Key Benefit |
|---|---|
| Player | Have fun |
| Parent | Ensure child meets grade level |
| Teacher | Monitor student performance |
An aggregate of functionality that delivers a desired benefit to a specific user.
Features are defined by asking a simple question:
If this user wants this benefit, what functionality must exist to deliver it?
For example, if a Player's primary goal is to have fun, the product must allow them to play the game. The Feature that delivers that benefit is Play the Game.
Features describe how the product delivers the benefit, not how the system is implemented.
This helps teams avoid designing technical solutions too early and keeps planning focused on value delivery.
Steps represent major workflow phases required to obtain the benefit. Steps should describe the user workflow, not implementation layers.
Example (Play the Game):
Storys represent specific capabilities required to complete each Step.
Example (Game Setup Step):
Product planning should define delivery intent, not implementation details. This allows engineering teams to design the best solution based on current constraints, rather than being locked into solutions designed months earlier during planning discussions.
Minimum Marketable Feature (MMF) is used in StrataTree to identify and visualize the minimum set of functionality required to deliver meaningful user value within a Feature for a given release.
A Feature is typically implemented through multiple Steps, which are implemented through multiple Storys. MMF represents the minimum subset of those Storys required for the Feature to deliver usable value in the release.
StrataTree visualizes MMF scope using an MMF waterline.
Key characteristics:
The waterline makes scope boundaries visible without requiring queries, filters, or alternate views.
To maintain a clear scope boundary, StrataTree enforces a continuous MMF block within each Step:
These rules keep the waterline meaningful and defensible.
MMF supports backlog refinement by making scope decisions visible and enforceable.
Instead of refining items in isolation, teams refine against:
This helps teams avoid a common failure mode where items become "well written" but the release plan still lacks coherent value delivery.
StrataTree integrates release assignment directly into the StrataMap so teams can evaluate scope, sequencing, and release viability in one place.
Releases are assigned at the Story level, where scope and delivery risk are most visible.
When All is selected:
In this view, MMF indicators are shown only for the first release to keep the visual focus on the immediate delivery boundary.
When a specific release is selected:
This view is useful for validating scope and completeness for a release without cross-release noise.
When Unassigned is selected:
This view is useful for finding work that has not yet been assigned to a delivery target.
When working with a backlog downloaded from Azure DevOps or Jira, two view filter checkboxes appear in the toolbar next to the release selector:
View filters work with any release view (All, single release, or Unassigned). They do not modify the project data — they only control what is displayed on the map. Filter settings are saved with the project and restored automatically on your next session.
StrataTree maintains release consistency during drag/drop and paste operations.
Common behaviors include:
The goal is to keep release grouping coherent without requiring manual cleanup after common planning edits.
Execution tools are optimized for delivery tracking. StrataTree is optimized for structural planning.
Execution tools answer operational questions such as:
StrataTree answers planning questions such as:
Many teams struggle when trying to describe all work using a User Story format. User Stories are effective for user-visible behavior, but they often get forced to describe technical or system-level work that users never perform directly.
This leads to backlog items like:
As a computer, I want to send a POST request to a server in order to receive a JSON response.
Retrieve a list of projects from the Azure DevOps server so users can select a project for backlog download.
For simplicity and tool compatibility, these are typically represented as Features in StrataTree and in execution tools. The distinction exists to improve planning clarity and prioritization, not to create additional work item types.
Product planning should define delivery intent, not implementation details. This allows engineering teams to design the best solution based on current constraints, rather than being locked into solutions designed months earlier during planning discussions.
StrataTree makes maintaining order in execution backlogs simple and efficient. It eliminates the two-step planning process where structure is designed in one place (spreadsheets, whiteboards, sticky notes, Miro) and then manually recreated in Jira or Azure DevOps.
Teams can create and refine backlog structure collaboratively in StrataTree in a meeting room or online meeting. When the planning session is complete, the execution tool can be updated quickly and consistently based on the validated structure, without losing context or introducing transcription errors.
StrataTree treats each map as a snapshot of the backlog at the moment of download. The upload pushes your map back to the tool, comparing against the snapshots stored at download time to detect what changed inside the map itself. There is no merge step against the live backlog at upload — StrataTree does not reconcile your map with whatever has changed in Jira or Azure DevOps since you last downloaded.
This is safe under two practices that StrataTree is designed around:
Developer work below Story level — Jira Subtasks, Azure DevOps Tasks — is out of StrataTree's scope. StrataTree does not download or modify those, so engineers can manage their own task hierarchy in the tool freely without ever conflicting with a planning session.
If you've made changes to a map, upload them or discard them promptly, if others may also be modifying backlog items. A held map with un-uploaded modifications is the one case where StrataTree's snapshot model can overwrite a teammate's work: when you eventually upload, your map's values replace any change a teammate made to those same items in the tool meantime — whether they were implementing the work, refining the description, correcting a field, or anything else that touched the item record at User, Feature, Step, or Story level. The safe pattern is download → organize → upload as one continuous session. (Tasks and Subtasks below Story level are out of scope and unaffected, as noted above.)
If you haven't made changes and you're returning to plan, download fresh rather than continuing to work on an older snapshot — there's no benefit to uploading a stale map.
To preserve a planning artifact independent of the live backlog — a template for similar projects, a historical reference, or a shareable plan — save the map as an XML file via Save Map. That gives you a portable snapshot you can reuse without re-syncing.
| Tier | Access | Save XML | Download from ADO/Jira | Upload to ADO/Jira |
|---|---|---|---|---|
| Explorer | Free | — | ✓ | — |
| Planner | Paid | ✓ | — | — |
| Product Owner | Paid | ✓ | ✓ | ✓ (one tool) |
| Portfolio | Paid | ✓ | ✓ | ✓ (multiple tools) |
| Enterprise | Custom | ✓ | ✓ | ✓ |
Explorer is free and designed to let you experience StrataTree with your real data before committing to a paid plan. All paid tiers include a 60-day money-back guarantee.
Subscription note: Downloading from Azure DevOps or Jira is available on Explorer and all paid tiers. Uploading back to ADO or Jira requires Product Owner tier or above. If a menu item appears grayed out, it is not included in your current tier — visit the Pricing page to compare plans.
Multi-org / multi-site note: If your organization has multiple Azure DevOps organizations or Atlassian sites, use the URL for the specific organization or site that owns the backlog you want to download.
New users are provided with an initial sample StrataMap. This allows you to explore the interface and planning concepts before connecting StrataTree to external systems.
Users can explore:
To see how StrataTree works with a real backlog before entering your own credentials, use the Try the Demo feature in the Download Backlog dialog.
Typical workflow:
Demo backlogs are available for both Jira Cloud and Azure DevOps. No credentials are needed — the demo uses pre-configured accounts.
The demo backlogs include some unstructured items (work items without a parent at the expected hierarchy level). This lets you see how StrataTree handles these items by placing them in containers such as "Unassigned work items" or "Unassigned Stories." See Section 10 for details on how backlogs map to the StrataTree hierarchy.
Backlog download is accessed through the hamburger menu.
Typical workflow:
After selecting a project, StrataTree asks how much of the project to download. Choose one of three modes. The mode determines which work items are downloaded; the Release level option determines how the downloaded backlog is organized in the StrataMap.
Select a team and StrataTree downloads the work items on that team's Azure DevOps backlog. You do not need to reproduce the team's settings: StrataTree uses the team's own Azure DevOps configuration automatically, including its area or team-field values, its backlog iteration, the backlog levels it shows, and its bug setting. Completed and Removed items are not on a team backlog and are not downloaded. If the team shows bugs together with tasks, bugs are treated as tasks and are not downloaded.
Parents owned by other teams. If a work item on the team's backlog has a parent that the team does not own, StrataTree also downloads that parent so the hierarchy is complete. These parents are marked Context on their cards. Context items are shown for orientation only: an upload never changes or reorders them, and edits you make to a context item stay in the map and are not uploaded.
Very large backlogs. Azure DevOps limits how many items it reports for each backlog level. If a level reaches that limit, StrataTree stops the download and tells you the level, the item count and the limit, rather than giving you a partial team backlog. Use the Custom download to narrow the scope in that case.
StrataTree does not try to match the view toggles in your own Azure DevOps web session, such as Show Parents or showing completed child items.
Custom download keeps the detailed filters. They apply to requirement-level work items — User Story, Product Backlog Item, Requirement, or Issue, depending on your Azure DevOps process — plus Bugs. Portfolio-level items (Epic, Feature, any custom level such as Initiative, and your own User and Step types when registered as portfolio levels) are exempt from those filters and are initially downloaded so StrataTree can reconstruct the hierarchy above the matching items. The Hide Features and Users with no matching stories option described below can then remove branches that contain no matching requirement-level items. Throughout this section, the items affected by the filters are called requirement-level items.
The Custom filters can be combined. The modes are exclusive: Team backlog and Whole project ignore the Custom filters.
In every mode, items that come from Azure DevOps appear in your Azure DevOps backlog order at each level. Items with no order value come after the ordered ones, by ID. There are two exceptions. When you download a map that StrataTree previously uploaded, StrataTree keeps that map's own order rather than the current Azure DevOps order. And items nested under another item of the same kind have no guaranteed order.
The default setting uses the last part of each Iteration Path, preserving the behavior of earlier StrataTree versions. Numbered levels are counted from the first segment below the Azure DevOps project root, not relative to the Iteration Path selected above.
For example, given the Iteration Path ProjectName\2026\Release 1\Sprint 5:
Sprint 5.2026.2026\Release 1.2026\Release 1\Sprint 5.Which levels are offered: the menu lists only levels that are valid for the current iteration hierarchy and selection. When an Iteration Path is selected, its own-level entry shows the selected path. If a one-level-deeper entry is available, its label shows one child path as an example. Without an Iteration Path selection, each entry shows an example path from that level.
Levels that no part of the hierarchy could reach are deliberately not offered, because choosing one would place every downloaded item in Unassigned. If an individual item's Iteration Path does not reach the selected level, StrataTree places that item in Unassigned; an item assigned only to the project root is Unassigned for every numbered level. The control appears once the iteration hierarchy has loaded.
Because portfolio items are exempt from the filters, a narrowly scoped download would otherwise return correct leaves hanging beneath a project-wide parent skeleton. StrataTree therefore selects this option by default whenever a scope filter is active. Clear it if you intentionally want to retain parent-only branches.
If no requirement-level items match the selected filters while this option is enabled, StrataTree keeps the download dialog open and suggests which filters you can widen. Clearing this option allows you to download the parent-only hierarchy instead.
If Azure DevOps does not provide the project's team list, StrataTree displays a message and leaves the Custom download available as an alternative way to scope the download. A team-list failure does not necessarily mean that your Personal Access Token needs additional permissions.
If a selected team does not have a usable work-item scope in Azure DevOps, StrataTree stops the download and reports an error rather than silently downloading the entire project.
For regular, non-demo connections, StrataTree remembers successfully used download mode, Team, Area Path, Iteration Path, Release level, and other download preferences, and restores valid selections when you return to the same connection and project. Review the restored selections before starting a new download.
Upload safety: A download scoped by Team, Area Path, Iteration Path, Created After, or completed-item filtering is a partial view of the Azure DevOps backlog. StrataTree records that scope and suppresses deletion detection for items that may be absent because of the filters rather than because you intentionally removed them. Release level changes Release assignment only; it does not narrow the downloaded backlog.
A Personal Access Token is a secure, time-limited credential generated inside Azure DevOps that allows tools like StrataTree to access data without requiring your password.
PATs:
Team-selection note: Selecting a team during download does not require an additional PAT permission beyond the access already needed to load the project. If StrataTree can load the project but cannot load its teams, use the Custom download as an alternative; expanding the token's permissions may not resolve an organization-policy or conditional-access restriction.
Note: The token is displayed only once, immediately after creation. Once you leave the token-creation screen, the value cannot be retrieved again. Copy it to your password manager or a secure location before navigating away. If you lose the value, revoke the token and create a new one.
StrataTree can download backlogs from Jira Cloud (*.atlassian.net). Jira Server and Data Center are not supported.
Typical workflow:
A Jira API token is a secure credential that allows tools like StrataTree to access your Jira data without requiring your Atlassian password. API tokens are used together with your email address for authentication.
Note: The token is displayed only once, immediately after creation. Once you leave the token-creation screen, the value cannot be retrieved again. Copy it to your password manager or a secure location before navigating away. If you lose the value, revoke the token and create a new one.
StrataTree's credential forms use standard HTML password-input semantics, so modern browsers recognize them as login forms and offer to save your token in their password manager. When you save through your browser:
StrataTree itself does not store the token — only your browser's password manager does, encrypted at the OS level. If you decline browser save, you'll paste the token at the start of each session. If your organization forbids browser password managers, use your dedicated password manager and copy/paste each session.
Hard refresh may clear locally stored StrataTree data. If cleared, you will need to re-enter your connection details and token.
This is useful when using StrataTree on shared or public computers.
Safari (Mac): Cmd + Option + R (or Cmd + Shift + R depending on version)
Chrome: Cmd + Shift + R (Mac) / Ctrl + Shift + R or Ctrl + F5 (Windows)
Microsoft Edge: Cmd + Shift + R (Mac) / Ctrl + Shift + R or Ctrl + F5 (Windows)
If using a shared computer:
PATs can be revoked anytime from Azure DevOps. Jira API tokens can be revoked from your Atlassian account settings.
Round-trip in this section means: download a backlog into StrataTree, edit in StrataTree, upload back to the tool, then download again and get an identical map back. StrataTree is designed so this works without losing structure or content.
StrataTree uses a four-level hierarchy: User → Feature → Step → Story. When downloading a tool-created backlog (not previously generated with, or uploaded from StrataTree) from an execution tool, StrataTree maps the tool's work item types into this structure.
When an execution tool has fewer hierarchy levels than StrataTree, or when items don't have a parent at the expected level, StrataTree creates virtual nodes, such as "Unassigned work items," to maintain a complete hierarchy.
Virtual nodes are a download-only concept. When StrataTree creates a virtual node ("Unassigned work items," "Unassigned Step- and Story-level work items," "Unassigned Stories") to give an orphaned tool item a parent in the four-level hierarchy, that virtual node lives only in the StrataMap. It is never written back to the tool on upload. Items sitting under a virtual node retain their tool-side state (which had no parent at that level to begin with) unless you reorganize them under a real parent in StrataTree before uploading. If you move an orphan to a real parent and upload, the new parent link is written to the tool. If you create a new item under a virtual node, the new item uploads with the closest real ancestor as its tool-side parent (or top-level, if there's no real ancestor) — Embedded Mode metadata in the description preserves the StrataTree position so a re-download recovers the placement.
You can rename these virtual nodes in your map, reorganize them, or add Features, Steps, or Stories to appropriate virtual nodes in the map; if you do so these virtual nodes become real nodes and are uploaded back to the tool backlog where, depending on how your tool is configured (whether it supports the levels and work item types), they are represented in a manner that supports 'round-tripping' (downloading the uploaded backlog back into a different map that is identical to the map just before the upload).
Both Azure DevOps and the Jira Cloud Premium and Enterprise tiers support optional configuration to add matching hierarchy levels. We encourage you to create these hierarchical levels if your tool supports them to have a closer representation of the map's structure in your tool backlogs, but this isn't required. See the configuration sections below for details.
StrataTree works with all four Azure DevOps process templates — Agile, Basic, Scrum, and CMMI.
| ADO Work Item Type | StrataTree Level |
|---|---|
| Epic | Feature |
| Feature (Agile and Scrum templates), FCE (Capability — Agile-derived) | Feature |
| User Story (Agile), Product Backlog Item (Scrum), Requirement (CMMI), Issue (Basic) | Story |
| Bug | Story |
| Task | Not downloaded |
| Test Case, Test Plan, Test Suite, Shared Steps, Code Review / Feedback Request, and any other type not on a backlog level | Not downloaded |
What gets downloaded is decided by your project, not by a fixed list. StrataTree reads your project's backlog configuration and downloads only the work item types that sit on a backlog level — your portfolio levels (Epic, Feature, and any custom level such as Initiative), your requirement level (User Story, Product Backlog Item, Requirement, or Issue depending on the process), plus Bugs. Anything not on a backlog level is left behind, which is why test cases and test plans never appear in your map.
Bugs are always downloaded, regardless of whether your team shows bugs on the backlog or on the taskboard. Bugs are filtered like any other backlog item, so if you download a single iteration you get that iteration's bugs, not the whole project's.
If your process defines work item types named User or Step, register them as portfolio backlog levels (see the configuration section below). Types that aren't on a backlog level aren't downloaded, and their children will appear under a virtual parent instead.
Custom portfolio levels (for example an Initiative tier above Epic) are picked up automatically and map to the StrataTree Feature level, the same as Epic and Feature do. Anything your process places on a portfolio backlog is epic-like by definition — too large to finish in a single sprint by a single team — which is exactly what a StrataTree Feature represents. Your own User and Step types keep their own levels even when registered as portfolio levels.
Note on the word "Feature". ADO's built-in Feature work item type and StrataTree's Feature level both use the same name. The two terms refer to the same level on different sides of the integration — an ADO Feature work item maps to a StrataTree Feature node.
On download, StrataTree creates virtual User and Step nodes to complete the four-level structure.
This configuration is recommended, not required. StrataTree works on every ADO process template out of the box — Embedded Mode handles missing User and Step types automatically. We recommend adding StrataTree-style hierarchy types because they produce the closest correspondence between what your StrataMap shows and what users see in the tool, eliminating Embedded Mode's metadata-block-in-description workaround. But if you can't make these changes (you're using a default ADO process that doesn't allow modification, your tool admin won't approve the change, etc.), upload still works on every tier — the only difference is that User and Step identities live in description metadata instead of native typed work items.
Azure DevOps supports adding custom work item types at both the Portfolio and Requirement backlog levels. By adding types named User, Step, and Story, you enable the closest hierarchical representation between ADO and StrataTree.
Prerequisites:
Step 1 — Create an Inherited Process
Step 2 — Add StrataTree Work Item Types
Step 3 — Assign the Process to Your Project
Step 4 — Verify the Configuration
Your process's Backlog levels tab should look like this:
| Level | Backlog | Work Item Types |
|---|---|---|
| Portfolio | Epics | Epic (default), User |
| Portfolio | Features | Feature (default), Step |
| Requirement | Backlog items | Product Backlog Item (default), Story |
| Iteration | Tasks | Task (default) |
With this configuration, StrataTree maps directly:
| ADO Work Item Type | StrataTree Level |
|---|---|
| User | User |
| Epic | Feature |
| Step | Step |
| Story / Product Backlog Item | Story |
Note: Existing Epics remain functional — they map to the Feature level in StrataTree. ADO's built-in "Feature" type coexists with Step at the Features portfolio level; StrataTree maps it to the Feature level alongside Epic. You don't need to remove or migrate existing work items.
See Backlog Order and Hierarchy in section 11 for how StrataTree stores rank and hierarchy in Azure DevOps without requiring custom fields.
StrataTree uses alphabetical ordering of release names to determine backlog priority within each step. For backlog priority to match delivery order, name your releases so that alphabetical ascending order equals chronological release order:
v1, v2, v3 — or — 2026H1 Release, 2026H2 Release — or — 2026-03-21 Sprint, 2026-06-14 SprintMarch Release, April Release (alphabetical order does not match calendar order). Instead use 2025-03 Release, 2025-04 ReleaseStories without a release assignment always appear last within their step, after all named-release stories.
StrataTree automatically detects how many hierarchy levels your Jira project uses and maps accordingly. Jira Cloud Standard has three levels (Epic, Story/Task/Bug, Subtask). Jira Cloud Premium and Enterprise allow additional hierarchy levels above Epic. StrataTree handles each case:
Standard Jira (3 levels — Epic, Story, Subtask) — Standard mapping: Epics map to Features. Stories, Tasks, and Bugs map to Stories. StrataTree creates a project-named User node to hold all Features, and an "Unassigned Stories" Step under each Feature. Subtasks are not downloaded.
4 hierarchy levels (e.g., Initiative above Epic) — Partial mapping: The highest level maps to User. Epics map to Features. Stories map to Stories. StrataTree creates an "Unassigned Stories" Step under each Feature.
5 hierarchy levels (e.g., Theme, Initiative, Epic, Story, Subtask) — Partial mapping: The three levels above Story map directly to User, Feature, and Step. Stories map to Stories. This produces a complete four-level StrataTree map with no virtual nodes.
StrataTree-configured types (User, Feature, Step at hierarchy levels 3, 2, 1) — Full mapping: When StrataTree detects work types named User, Feature, and Step, it maps by type name for a direct one-to-one match. This is the recommended configuration — see Configuring Jira for Full StrataTree Support below.
Mapping names (Standard, Partial, Full) appear in StrataTree's mode-resolution indicator in the upload preview — see Mode resolution indicator in section 11.
In all scenarios, when Jira-created backlogs are downloaded into StrataTree, Jira-created work items without a parent are placed under virtual nodes ("Unassigned work items", "Unassigned Step- and Story-level work items", "Unassigned Stories") to preserve the four-level structure.
This configuration is recommended, not required. StrataTree works on every Jira Cloud tier out of the box — Embedded Mode handles missing User and Step types automatically. We recommend adding StrataTree-style hierarchy types because they produce the closest correspondence between what your StrataMap shows and what users see in the tool, eliminating Embedded Mode's metadata-block-in-description workaround. But if you can't make these changes (you're on Jira Cloud Standard or a Premium tier without admin permission, your tool admin won't approve the change, etc.), upload still works on every tier — the only difference is that User and Step identities live in description metadata instead of native typed work items.
Jira Cloud Premium and Enterprise support custom hierarchy levels above Epic. By adding work types named User, Feature, and Step, you enable direct one-to-one mapping between Jira and StrataTree — no virtual nodes needed. StrataTree detects these custom types automatically during download.
Prerequisites:
Step 1 — Create the StrataTree Work Types
Tip: Make sure your browser window is full-screen — the left settings menu pane may not appear in a narrow window.
Step 2 — Configure the Work Type Hierarchy
| Level | Name | Default Work Types |
|---|---|---|
| 1 | Epic | Epic |
| 0 | (Base) | Story, Task, Bug |
| -1 | Subtask | Subtask |
Your hierarchy should now look like this:
| Level | Name | Work Types |
|---|---|---|
| 3 | User | User |
| 2 | Feature | Feature |
| 1 | Step | Epic, Step |
| 0 | (Base) | Story, Task, Bug |
| -1 | Subtask | Subtask |
Note: Epic remains at level 1 alongside Step. This preserves existing Epic issues and workflows while adding the StrataTree hierarchy levels above them.
Step 3 — Add Work Types to Your Project
Step 4 — Verify the Configuration
Your project's work types should now include:
| Work Type | Hierarchy Level | StrataTree Mapping |
|---|---|---|
| User | 3 (highest) | User |
| Feature | 2 | Feature |
| Step | 1 | Step |
| Story | 0 (base) | Story |
Important: The StrataTree hierarchy is designed to be used as User > Feature > Step > Story. Using these work types in ways other than intended (for example, creating Steps without a Feature parent, or nesting types out of order) may lead to organizational issues within your backlog or interfere with Jira Planner functionality. Compatibility with Jira Planner has not been fully tested with custom StrataTree hierarchy levels.
See Backlog Order and Hierarchy in section 11 for how StrataTree stores rank and hierarchy in Jira without requiring custom fields.
StrataTree uses alphabetical ordering of release names to determine backlog priority within each step. For backlog priority to match delivery order, name your releases (Jira versions / fix versions) so that alphabetical ascending order equals chronological release order:
v1, v2, v3 — or — 2026H1 Release, 2026H2 Release — or — 2026-03-21 Sprint, 2026-06-14 SprintMarch Release, April Release (alphabetical order does not match calendar order)Stories without a release assignment always appear last within their step, after all named-release stories.
We recommend full mapping. The User, Feature, and Step hierarchy levels and work types can be added to existing Jira projects without affecting current issues or workflows. Once configured, you can download the backlog into StrataTree, reorganize the hierarchy visually, and upload the restructured backlog back into Jira. (See Jira Cloud Mapping above for the four scenarios StrataTree detects automatically and the mapping name each one resolves to.)
What if I Already Have Epics?
Existing Epic issues remain functional. Epic stays at level 1 alongside Step, so existing Epics continue to work in Jira. StrataTree maps them based on the scenario it detects:
You don't need to remove or migrate existing Epics.
Frequently Asked Questions
Q: Do the work type names have to be exact?
A: The matching is case-insensitive. "user", "User", and "USER" all work. But the name must be exactly "User", "Feature", or "Step" — not "Users" or "Steps".
Q: Can I use this with team-managed projects?
A: No. Team-managed projects in Jira do not support 4- or 5-level hierarchies. You must use an organization-managed project for the full StrataTree hierarchy configuration.
Q: What about Subtasks?
A: StrataTree does not download Subtasks. They remain in Jira but are not represented in the story map.
Q: Will this affect my existing Jira workflows?
A: Adding new work types and hierarchy levels does not change existing issues or workflows. You can use the StrataTree types alongside your existing configuration.
Jira Cloud Standard has a fixed three-level hierarchy (Epic, Story, Subtask). Both download and upload are fully supported on Standard out of the box, with no project configuration required:
If you have Premium or Enterprise and want direct one-to-one mapping (no virtual nodes, no embedded metadata blocks), see Configuring Jira for Full StrataTree Support above. Full Mode is an enhancement, not a prerequisite.
The "Minimum Marketable Feature" flag (set on Stories in StrataTree) round-trips through both tools:
Custom.IsMMF field if it can be created (or falls back to an MMF tag on System.Tags). On download, both carriers are read back and the StrataTree IsMMF flag is set accordingly.MMF to the issue's labels. On download, the MMF label (case-insensitive) is read back.To pre-mark a tool-side item as MMF before downloading, set the appropriate carrier in your tool: in ADO, set Custom.IsMMF = true (or add the MMF tag); in Jira, add the MMF label.
StrataTree can upload your story map back to Azure DevOps or Jira Cloud, creating new work items, updating modified ones, and optionally closing items you removed from the map. The upload process uses a three-phase workflow: Connect → Preview → Execute.
Works out of the box. Upload is fully supported on every Azure DevOps process template (Agile, Scrum, CMMI, Basic) and every Jira Cloud tier (Standard, Premium, Enterprise) — no custom work item types, custom fields, or admin configuration required. Adding StrataTree-named hierarchy types (User / Feature / Step / Story) is an enhancement that enables Full Mode direct mapping; without them, StrataTree uses Embedded Mode automatically and round-trips faithfully on download.
What StrataTree does NOT change in your tool.
- Status / state (To Do / In Progress / Done) — owned by the tool. Never written by StrataTree on upload, even if the StrataMap was edited in Project Management Mode.
- Existing description content — write-once. StrataTree appends a small machine-managed metadata block to the description (Embedded Mode) but does not overwrite text you or your team wrote in the tool's description field.
- Tasks (ADO) — never read or written. StrataTree's four-level hierarchy stops at Story; Tasks remain in ADO untouched.
- Assignees — never read or written. Assignment to people in the tool is owned by the tool.
- Custom fields outside StrataTree's specific carriers. Only the carriers StrataTree manages (Acceptance Criteria field, IsMMF field/tag/label, MapKey field where present) are touched. Other custom fields are left as-is.
After connecting, StrataTree fetches your available projects and auto-selects the matching one if the map was originally downloaded from that tool.
Once you pick an existing Azure DevOps project, two more choices appear under it: Team and Area Path. They decide where the work items from your map end up.
Jira tier compatibility: Uploading works on every Jira Cloud tier — Standard, Premium, and Enterprise. Standard tier uses Embedded Hierarchy Mode automatically (User/Step identities round-tripped through metadata blocks in issue descriptions). Premium and Enterprise can additionally use Full Mode if User/Feature/Step custom hierarchy levels are configured (see Configuring Jira for Full StrataTree Support in section 10). No project configuration is required to start uploading on any tier.
Before anything is written to your backlog, StrataTree analyzes your map and shows exactly what will happen. The preview displays:
Nothing is written until you click "Upload." You can review the preview, go back to change credentials or select a different project, or cancel entirely.
During preview, StrataTree shows a one-line message like "Will upload in Full Mode based on the target project's available types." or "Will upload in Embedded Mode based on the target project's available types." This tells you which path StrataTree will take before you click Upload:
See Configuring Azure DevOps or Configuring Jira for what enables Full Mode. Both modes round-trip without losing structure.
StrataTree uses two layers of duplicate prevention to help you avoid accidentally creating duplicate work items during upload:
Before the upload preview runs, StrataTree validates your map for duplicate titles at each hierarchy level. This is an advisory warning, not a blocker — you can acknowledge the warnings and proceed with the upload.
The uniqueness rules are:
When items lack tool connection metadata — for example, after saving to XML and reloading — StrataTree checks the target backlog for existing items with matching titles. If an unambiguous match is found (exactly one work item with the same title at the same hierarchy level), the item is reclassified from "new" to "modified" to prevent duplicate creation.
If multiple candidates match (ambiguous), the item stays classified as "new" and a warning is displayed so you can review it before proceeding.
This applies to both Azure DevOps and Jira uploads.
Same project: When uploading back to the project you downloaded from, StrataTree knows exactly what changed. It compares the current map state against the original download snapshots and detects precise field-level changes — including title, size, release, parent hierarchy, description, and MMF flag.
Different project: When uploading to a project other than the original source, StrataTree uses smart matching to find corresponding work items by title, type, and hierarchy position. Each match is shown with a confidence level:
Empty target project: If the target project has no work items, everything in the map is treated as new.
After reviewing the preview, click "Upload" to execute. StrataTree creates new work items, updates modified ones, and optionally closes deleted items. When complete, a summary shows:
What happens to deleted items — StrataTree never deletes work items in your tool. Items you removed from the map are detected by comparing against your original download. By default they are left untouched. If you tick "Close deleted items," StrataTree changes their status rather than deleting them: in Jira the issue is transitioned to Closed; in Azure DevOps the work item's state is set to Removed. StrataTree also skips deletion detection when your download was scoped — a team, an area or iteration filter, a date filter, excluding closed items, or uploading to a different project — because a missing item may simply have been filtered out rather than deleted. This prevents accidental closures.
Context items. Parents marked Context (downloaded from a Team backlog because the team's items need them) are left unchanged by the upload. The upload preview states how many context items were left unchanged. Edits you make to a context item stay in the map and are never uploaded.
After a successful upload, StrataTree updates the map with fresh tracking data. This ensures the next upload detects only new changes — you won't see the same modifications again.
StrataTree is the source of truth for backlog order. When you upload, StrataTree replaces the backlog order in your execution tool with the StrataTree map order. In Azure DevOps, a level where you have not moved an existing item and have not added a new item is left alone, so order changes you made only in Azure DevOps there are not overwritten; changed levels use the map order, and Context items are never reordered. This is intentional — if you've been managing rank in StrataTree, that order is what gets pushed back. The upload preview shows the same warning at the moment you click Upload.
Think of the StrataTree map as your planning canvas: the execution backlog is the mirror of the sticky notes you arranged in StrataTree, not a second place where a separate ordering system should evolve.
StrataTree no longer creates or requires any rank or hierarchy custom fields in your backlog tool. The previous StrataTree.Rank custom field has been replaced by mechanisms that already exist in every ADO and Jira project, and StrataTree.MapKey is now optional rather than required:
PUT /rest/agile/1.0/issue/rank). Sorting any Jira backlog or board by Rank shows StrataTree order. The Rank API is available on every Jira Software tier — Standard, Premium, and Enterprise.---[STRATATREE:MAP]--- / ---[/STRATATREE:MAP]---), to the end of each work item description. The format is identical for ADO and Jira — plain text was chosen because ADO's HTML sanitizer strips unknown XML/HTML elements from the rich-text description field post-PATCH, so the markers must survive both renderers untouched. The block is visible in both tools but obviously machine-managed, and round-trips through download.StrataTree.MapKey field already exists, or StrataTree can create it, StrataTree writes the current map identity there. If not, upload still succeeds and round-trips on download through the embedded metadata block.Full Mode is used when the target tool has the StrataTree-style hierarchy available. In Full Mode, backlog order will round-trip on download through the tool's native ordering mechanism, and structural identity will round-trip on download through the tool metadata StrataTree writes during upload.
Embedded Mode is used when the target tool does not have native User/Step hierarchy support. In Embedded Mode, backlog order will round-trip on download and hierarchy will round-trip on download through the machine-managed metadata block in the description.
Some older custom-field values from earlier StrataTree versions may still exist in the tool, but they are now inert. If a teammate manually edits or deletes the machine-managed embedded block, the hierarchy signal stored there will be lost on download until StrataTree refreshes it on a later upload.
Within each (Release, Feature) cell, StrataTree ranks Stories using the Feature's FCE attribute: Feature nodes (default) use row-major order — Stories are ranked across Steps before moving down; Capability nodes use column-major order — all Stories in Step 1 are ranked before any Stories in Step 2, and so on. In both cases, MMF Stories within the cell rank ahead of non-MMF Stories. Set the FCE attribute in the Feature Edit modal under View as: Feature / Capability.
To keep same-project upload recovery reliable, use these title rules consistently:
These are the operating rules StrataTree is designed around today, and future releases may enforce them more strictly in upload validation.
Legacy StrataTree.Rank and StrataTree.MapKey custom-field values from earlier StrataTree versions become inert — no data is lost on round-trip; the legacy fields are simply not read or written anymore.
On download, Story Release assignments are derived from Azure DevOps Iteration Paths. Use the Release level option during download to choose which depth of the Iteration Path becomes the StrataTree Release; see Azure DevOps Download Options in section 9.
See How StrataTree Represents Releases (section 7) for release naming conventions that ensure correct backlog ordering.
StrataTree currently supports one active external backlog sync context per map. You can download from ADO and upload to Jira (or vice versa), but maintaining simultaneous round-trip synchronization to both tools from the same map is not supported. In mixed-tool scenarios, some change detection (especially reorder/position-only updates) may be inaccurate.
Recommended workflow: use one tool as the active source of truth at a time, and re-download after switching tools.
StrataTree handles as much configuration as possible during upload:
StrataTree Acceptance Criteria custom text field is created on first upload to preserve discrete AC items. This is non-blocking — if the field cannot be created, AC content falls back to a sentinel block in the issue description.StrataTree works out of the box with default Azure DevOps and Jira project templates — no custom work item types, custom fields, or admin configuration required. The following are optional enhancements that enable Full Mode (direct one-to-one hierarchy mapping with no virtual nodes or embedded metadata blocks):
StrataTree stores acceptance criteria in a dedicated field when available:
Microsoft.VSTS.Common.AcceptanceCriteria field. This field is included by default on User Story and Bug work item types in most ADO process templates, but may not be present on custom work item types (such as User, Step, or Story types added for StrataTree).StrataTree Acceptance Criteria, created automatically on first upload. This field must be added to the relevant issue type's screen for Jira to accept it during updates.If you see a warning about acceptance criteria being embedded in the Description field, the dedicated AC field is not available for one or more work item types. The upload still succeeds — acceptance criteria are appended to the Description field instead. To use the dedicated field:
Microsoft.VSTS.Common.AcceptanceCriteria field. See Microsoft documentation on customizing fields.StrataTree Acceptance Criteria field onto the screen. If the field doesn't appear in the field list, ensure it was created (check Jira Settings → Issues → Custom Fields).Once a StrataMap exists, most planning work involves reorganizing structure rather than creating nodes from scratch. StrataTree is optimized for fast structural editing.
You can copy any node type. When you copy a node, all of its children are included:
Copy and paste using either method:
For multiple Storys, hold Ctrl (or Cmd) and click to select multiple items, or click and drag on the background to rectangle-select multiple Storys.
Each node type can only be pasted onto certain targets:
| Copied Item | Can Be Pasted Onto |
|---|---|
| Story | Step or another Story |
| Step | Feature or another Step |
| Feature | User or another Feature |
| User | Another User |
When you paste, all items receive new unique IDs. The pasted items are completely independent from the originals, so you can paste the same copied content multiple times.
Cut removes the original item and places it on the clipboard for pasting elsewhere. Use Ctrl+X (Cmd+X on Mac) or right-click and select Cut.
In Project Management mode, Storys that are In Progress or Done cannot be cut. This prevents accidental removal of work that has already started. Copy is always available regardless of state. See the Project Management Mode section for details.
Nodes can be copied between maps, including maps open in different browser tabs, windows, or browsers. This supports reuse of structural patterns without requiring export/import operations.
To copy across maps:
Important considerations for cross-map paste:
Note: Cross-map copy/paste may require an appropriate subscription tier.
| Action | Windows/Linux | Mac |
|---|---|---|
| Copy | Ctrl+C | Cmd+C |
| Cut | Ctrl+X | Cmd+X |
| Paste | Ctrl+V | Cmd+V |
| Undo | Ctrl+Z | Cmd+Z |
Drag and drop is the fastest way to reorganize work.
You can:
When you move a node, all of its children move with it. Storys retain their release assignments when moved within the same map.
StrataTree maintains structural rules, release assignments, and MMF continuity rules as you edit.
StrataTree organizes editing around three lifecycle stages — planning, refinement, and execution. Each stage has its own working mode, and each mode focuses the Edit modal on the fields that matter for that stage. Switching modes changes which fields are visible; it never deletes data.
A mode selector appears in the header bar, to the right of the hamburger menu. Switch modes at any time. The mode resets to Planning whenever you load a new map, download from an execution tool, or upload an XML file.
Mode switching never deletes data. Refinement fields, PM tracking fields, and base story fields all persist in the project XML regardless of which mode is active — switching modes only changes which fields are visible in the Edit modal and on the map.
The table below shows which fields are editable in the Edit modal in each mode. Open a node by double-clicking it, or right-click → Edit.
| Field (node type) | Planning | Refinement | Project Management |
|---|---|---|---|
| Title (all) | ✓ | ✓ | ✓ |
| Release (Stories) | ✓ | ✓ | ✓ |
| Story Size (Stories) | ✓ | ✓ | ✓ |
| MMF (Stories) | ✓ | ✓ | ✓ |
| Business Reason (Stories) | ✓ | ✓ | ✓ |
| FCE (Features) | ✓ | ✓ | ✓ |
| Description (all) | — | ✓ | — |
| Acceptance Criteria (Stories) | — | ✓ | — |
| T-Shirt Size (Features) | — | ✓ | — |
| State (Stories) | — | — | ✓ |
| Assigned To (Stories) | — | — | ✓ |
| Blocked (Stories) | — | — | ✓ |
| Estimated Days (Stories) | — | — | ✓ |
If you don't see a field you expect — for example, the Description box — switch to the mode that owns that field. Field values persist across mode switches; they're just hidden from the Edit modal in modes where they don't apply.
Software development teams aren't the only planners in an organization. People across the organization... Sales, Product Marketing, Operations, even Engineering leaders... often have several small independent projects or initiatives they're running and could benefit from StrataTree's coherent, structured planning approach.
The StrataMapping methodology used to create a StrataMap is equally effective in all domains, and is now available to people both inside and outside of engineering teams who do not have or do not need enterprise-level execution tools. Every project benefits from knowing what is in progress, who is working on what, what is done, and what is stuck.
Project Management mode is designed for teams running non-technical projects, or any project, where a full-scale execution tool like Jira or Azure DevOps isn't available or appropriate. It's not meant to replace these execution tools, but to fill the gap between physical or graphical whiteboard and sticky notes that don't offer structure or metrics, and full-blown execution tools.
Project Management mode gives you a lightweight way to manage execution directly within StrataTree, right alongside the story map you already use for planning. There's no separate tool to set up, no syncing to manage, and no learning curve beyond a few additional fields on each story. Your map becomes both the plan and the dashboard.
See Working Modes for an overview of all three modes and a field-availability table.
A mode selector appears in the header bar, to the right of the hamburger menu. If your account has the Project Management feature enabled, you can switch between Planning and Project Management at any time. The mode resets to Planning whenever you load a new map, download from an execution tool, or upload an XML file.
Your PM data is always preserved regardless of which mode you're in — switching to Planning just hides the PM interface; it never erases tracking data. PM data is also saved in your XML maps.
Use Project Management Mode when running a project directly in StrataTree without an external execution tool, or alongside an external tool when you want a single source of truth for state and progress across the map. Switch into PM Mode after the map structure is in place and items are sized — typically once Refinement Mode work is complete and execution is about to begin. The mode adds tracking fields to the Edit modal and progress badges to the map.
Each story gains four project tracking fields, accessible by editing the story (double-click or right-click → Edit Story):
The system automatically records key dates as you update stories:
Moving a story backward (e.g., Done back to In Progress) clears the forward dates appropriately. Moving back to To Do clears all progress dates.
In Project Management mode, story nodes on the map show three visual cues:
All three indicators are hidden in Planning mode, so the map stays clean for backlog refinement sessions.
Project Management mode provides progress rollups at two levels:
Each Feature node on the map displays a progress summary for the currently selected release:
The header bar displays project-wide progress for the selected release:
Both rollups update automatically as you change story states or switch releases.
Project Management mode adds safeguards to prevent accidental disruption of in-progress work:
Stories with no tracking data (new stories that haven't been edited in PM mode) are treated as To Do and have no restrictions.
When you multi-select stories (Ctrl+click, Shift+click, or rectangle select) and right-click → Edit, you can change State and Blocked for all selected stories at once. Assigned To and Estimated Days are only editable on individual stories, since they're typically unique per story.
PM tracking data is saved in the project XML alongside all other story data. Maps containing PM data can be opened by anyone — users without the Project Management feature simply won't see the PM interface, but the data remains intact in the file.
Refinement Mode shifts focus from structure to elaboration. Once your story map hierarchy is in place, switch to Refinement Mode to add detail: descriptions, acceptance criteria, and sizing. This is the bridge between "what are we building?" (Planning) and "how do we track it?" (Project Management).
See Working Modes for an overview of all three modes and a field-availability table.
Select Refinement from the Mode menu in the header bar. The mode resets to Planning when you load a new map. Refinement data is always preserved regardless of which mode you're in — switching modes just changes the interface, it never erases refinement data.
Use Refinement Mode after the map skeleton is in place and you're ready to add detail. Typical activities: writing a Description on a node to clarify intent for a future reader; capturing acceptance criteria during a refinement session with the team; assigning T-Shirt sizes to Features for early sizing; estimating Stories with Fibonacci point values once the team has discussed them. Refinement is the bridge from "what are we building?" (Planning) to "how is it going?" (Project Management).
Double-click any node to open the refinement editor:
In Refinement Mode, nodes on the map show two visual cues:
When viewing a named release, the header shows story point rollups: "MMF: Xpts · Release: Ypts". When viewing "All", the header shows total points across all releases.
Refinement Mode is designed to work as a shared screen during virtual refinement sessions. Team members can walk through stories together, write acceptance criteria in real time, and assign estimates — all visible on the map as they go.
For teams not using an execution tool, acceptance criteria in Refinement Mode serve as a lightweight definition of done. During Sprint Reviews, walk through each story's criteria and check off what has been demonstrated. The AC Count badge on the map (e.g., "2/4 AC") gives an instant visual of how close each story is to acceptance. Combined with Project Management mode's state tracking, this provides a complete plan-refine-deliver workflow without leaving StrataTree.
If a story is marked as done in an external tool (Azure DevOps or Jira), refinement fields become read-only. A green banner indicates the external status, preventing accidental modification of completed work.
Refinement data is saved in the project XML alongside all other story data. Descriptions and acceptance criteria sync with Azure DevOps and Jira on upload and download. Maps containing refinement data can be opened by anyone — users without the Refinement feature simply won't see the refinement interface, but the data remains intact in the file.
Azure DevOps — StrataTree reads and writes the built-in Acceptance Criteria field on work items. If a work item type does not have this field, StrataTree embeds acceptance criteria in the Description field instead and retrieves it automatically on the next download.
Jira — StrataTree looks for a custom field called StrataTree Acceptance Criteria. If this field exists on the issue type, acceptance criteria are stored there. If not, StrataTree embeds acceptance criteria in the Description field. See Section 10 for instructions on adding the custom field to your Jira configuration.
In both cases, StrataTree handles the mapping automatically — you write acceptance criteria once in Refinement Mode, and they appear in the right place in your execution tool after upload.
StrataTree AI features bring intelligent assistance directly into your planning workflow. You connect your own AI provider — Anthropic, OpenAI, or any compatible provider — and StrataTree handles the methodology, context, and conversation structure. StrataTree does not supply AI credentials; your API key is billed through your provider, not through StrataTree.
Your provider settings — including your API keys — are kept on your own device, never on StrataTree's servers. This is a deliberate security decision: a key we never receive cannot be exposed by a breach of our systems, so this is safer than holding your keys server-side, even in an encrypted vault. Paired with automatic expiry (see Expire Saved Settings), it keeps each key under your control and encourages regular rotation.
AI features are available on certain subscription plans. See your account or contact support to confirm what is available on your plan.
Before using any AI feature, you must configure at least one AI provider. Open AI settings from either location:
Click Add provider and fill in the following fields:
claude-sonnet-4-6 or gpt-4o. The value is case-sensitive and must match exactly — a display name like "Sonnet" will not work. StrataTree passes this value directly to the API with no modification.https://api.openai.com/v1 for OpenAI, or https://api.anthropic.com for Anthropic. For any other provider, enter the equivalent base URL from their API documentation — the format will be similar but point to their service.StrataTree verifies each provider by sending a small test prompt and confirming a valid response. Verification runs automatically whenever you save changes to a provider or close the AI settings panel after making edits. You can also click Verify on any provider row at any time — useful after a transient outage to confirm connectivity has been restored.
A green dot on the provider row means the provider is verified and ready. A red dot means the last verification failed — check that the API key is correct and that the provider's service is reachable.
Exactly one provider may be set as the default. Click the star icon on the row you want to use as the default. All AI sessions use the default provider unless you switch providers from the header bar. If you delete the default provider, the oldest remaining provider becomes the new default.
Your providers and keys live on the device you are using — they do not follow you to another browser or machine unless you move them yourself with the file options below.
stratatree-ai-settings.json file. This file contains your API keys in readable form — it exists so you can move settings to another machine, or so an organization can distribute a shared key for rotation. Store and share it with the same care as the keys themselves.stratatree-ai-settings.json. If you already have providers configured, StrataTree asks you to confirm before replacing them. The default provider is verified automatically after a load.Under Expire saved settings, choose how long stored keys survive without use — 30, 60, or 90 days (30 is the default). StrataTree clears the stored keys automatically after that period of inactivity, so a key left behind on a machine does not stay valid indefinitely. If you open AI settings after your saved settings have expired, StrataTree tells you and offers to load a settings file — it never discards your configuration silently.
Under Store session transcripts, you can allow session transcripts — conversation text only, never your map data — to be stored to help improve the AI. This is your choice and can be changed at any time.
The header bar button reflects your current configuration. It is only visible in Planning mode.
The AI Map Builder restructures a raw backlog into a well-formed StrataMap. It follows a built-in restructuring methodology: it scans your map, works through its restructuring stages automatically, and then presents a single, complete proposal for your review. You stay in control — nothing on your map changes until you click Apply, and you can refine the proposal in plain language as many times as you like before you do.
The AI Map Builder works with any map in Planning mode: a freshly downloaded Jira or ADO backlog, an XML file you built yourself, or a partially restructured map you want to continue working on. The AI scans the current state of the map and builds its proposal from wherever the work stands.
Click AI Map Builder in the header bar (or AI Assistance ▼ → AI Map Builder if you have multiple AI features). The map canvas shrinks to two-thirds width and the AI panel slides in from the right.
The first time you use it, a short disclosure screen explains what is sent to your AI provider. Accept it to continue; it is not shown again on later sessions. The AI then scans the current map and begins.
While an AI session is active, the map canvas is locked — node editing, drag-and-drop, and the right-click menu are disabled. This prevents conflicts between your manual edits and the changes the AI is proposing. Keyboard zoom (Ctrl + Plus / Ctrl + Minus) still works if you want to adjust your view.
Once the scan finishes, the AI works through its restructuring stages automatically — you are not asked to confirm each one. A checklist in the panel, headed "What StrataTree AI proposes", lists the stages and marks each one off as it completes:
When the run finishes, the panel shows the finished proposal: the restructured map the AI is proposing, a summary of what it did, and anything it could not resolve (for example, Stories it could not confidently place).
The proposal is a draft, not a final answer. Under Refine the plan, type an instruction in plain language — for example, ask the AI to move a Feature under a different User, split an oversized Feature, or reconsider where a group of Stories landed. The AI revises the proposal in place and the panel updates. You can refine as often as you like; each request is answered against the current proposal, and still nothing has touched your map.
Nothing on your map changes until you click Apply in the panel header. Apply stays disabled while the scan and the automatic run are still working, and becomes available once a proposal exists. Clicking it commits the entire proposal to your map in one step.
After you apply, the panel confirms the map was restructured and shows a written summary of the session — what changed and anything left unresolved. You can open the full summary and download it as a Markdown file for your records. Click Done to close the panel.
Click Exit in the panel header to close the AI panel and return to full-screen Planning mode. Exiting before you apply discards the proposal and leaves your map exactly as it was; anything you already applied stays. When you re-launch AI Map Builder, it rescans the current map and builds a fresh proposal from the current state — no map work is lost between sessions.
If your provider is unreachable mid-session, click Exit, update your AI provider settings (or set a different verified provider as your default), then re-launch AI Map Builder. The AI will rescan the current map and build a new proposal from the current state.
Thank you for trying StrataTree.
StrataTree is being built in close collaboration with the teams and practitioners who use it. Your feedback directly influences how the product evolves.
We would value hearing:
If you are using StrataTree as part of real planning work, that feedback is especially valuable.
Thank you for helping us improve StrataTree.