Frequently Asked Questions

StrataMapping is a structured approach to backlog planning developed by John Clifford in 2009 and refined over the following five years through active client use. It evolved from Jeff Patton's user story mapping by centering planning on user problems and needs, defining features as solutions that deliver benefits through a structured workflow, and introducing a strict four-level hierarchy with defined rules that make planning repeatable, teachable, scalable, and actionable. Where story mapping is a facilitation craft, StrataMapping is a repeatable planning process, one that keeps backlogs organized and understandable even when they grow to hundreds or thousands of items across multiple teams. The approach was introduced publicly at the Scrum Gathering in New Orleans in 2014, where it drew a standing-room-only crowd.

StrataMapping's track record comes from John Clifford's consulting engagements: project rescues, often combined with agile transformations. Combined with effective estimation practices, StrataMapping makes delivery forecasts accurate and precise enough to be useful.

A team that had been stalled for six months StrataMapped its v1 release in an afternoon and forecast delivery at the end of that session. It released two months later, on time and with zero defects.

In 2013, a 100-person team was rewriting a released v1 medical device software application that was missing functionality and had many known defects. The StrataMap for the entire product was created incrementally and iteratively, elaborating features to stay ahead of the teams. A changing competitive market doubled the scope, and the map let everyone see where scope had to be added and existing functionality tested. Delivery was forecast continually, and after six months, a third of the way through, the forecast was accurate to within a month of the actual ship date. The product went through the FDA-mandated verification and validation (V&V) phase in two months, the minimum needed to grow the cell cultures required for testing; V&V phases typically took nine months because of rework. The product still shipped six months ahead of its target date, taking 18 months. The original v1 took 4.5 years with a larger team.

An IT team planned a major Oracle upgrade with StrataMapping in an afternoon. The upgrade took six weeks, half the time of previous upgrades, with no scope surprises.

A StrataMap is organized into a hierarchy with four levels:

• User — the specific user role (not a single persona) interacting with the product to accomplish a goal and receive a benefit by doing so.
• Feature, Capability, or Enhancement — the aggregate of functionality that delivers the benefit to the user. Capabilities deliver functionality across Features and may only be indirectly perceptible to users, e.g., multi-tenant support, SSO. Enhancements are subsets of Features or Capabilities used to define extensions of functionality to the original Feature or Capability.
• Step — the ordered sequence of actions in a workflow the user follows within a Feature or Capability.
• Story — the specific, discrete increment of functionality required to partially implement each Step.

This structure is not optional or suggestive. It is enforced. That consistency is what makes StrataMap-based backlogs understandable and consistent across releases, products, and organizations, actionable by one or many teams, and readable by stakeholders with simple explanation when they weren't in the room when the map was built.

MRF, or Minimum Releasable Functionality, is the point at which every Feature or Capability in a planned release has reached its MMF threshold. In projects with multiple teams working in parallel, releasing when MRF is achieved lets you deliver value quickly without waiting for every story to be complete. In environments where customers won't accept frequent releases, MRF still provides value as a planning milestone: it defines the earliest point at which an internal or staged release is viable, and it gives leadership a quantitative delivery target rather than a judgment call. Together, MMF and MRF replace informal release debates with clear, objective criteria that any stakeholder can read directly from the map.

In combination they provide a clear release strategy: on new product introductions, get each Feature or Capability to MMF as quickly as possible, ideally by having different teams take a Feature or Capability and implementing it to MMF. This strategy shortens the delivery time to that of implementing the largest Feature or Capability.

One important distinction: on a first release, you typically need to reach MRF before shipping anything, because there is no existing product to build upon. On subsequent releases, individual Features, Capabilities, and Enhancements can be released as each reaches its own MMF threshold, since customers already have a working product.

Yes. StrataMapping was practiced for over a decade using physical sticky notes and large walls in team war rooms before StrataTree existed, and proved to be extremely effective. The limitation of physical maps is that the work to keep them continually synchronized with digital work item tracking tools like Jira or Azure DevOps can be onerous to where teams lose the discipline to do so. StrataTree was built specifically to solve that problem by removing the friction of syncing StrataMaps with their underlying backlogs in Jira or Azure DevOps.

StrataTree is a web-based planning tool built specifically to create and manage StrataMaps. StrataTree, and StrataMapping, comprise the planning layer that runs on top of your execution tools, a structured environment for turning a messy or oversized backlog into a clean, ordered, and actionable delivery plan that your team can actually execute. While it has project management capabilities for teams using StrataMapping without Jira or Azure DevOps, it is not a general-purpose whiteboard or a project tracking tool for teams that don't and won't use StrataMaps.

Miro and Mural are open canvases intended for freeform collaboration. They are designed around the absence of enforced structure, and that philosophy is central to their appeal and directly at odds with what StrataMapping requires. There are Miro templates that superficially resemble a StrataMap, but without enforced hierarchy they function as user story maps at best, with structure that depends entirely on team discipline rather than the tool.

Out of the box, these tools have limited support for uploading structured backlog data to Jira or Azure DevOps. This is not a criticism of Miro or Mural, which are general-purpose visual whiteboarding tools that do that job well. They are simply not designed for what StrataTree is built to do: project planning and scoping, and creating, refining, and organizing product backlogs with a defined, enforced methodology.

Think of using Miro or Mural for StrataMapping the way you would think of doing it physically on a wall or whiteboard: effective for the planning conversation, but with the same limitations when it comes to transferring that structure completely and accurately into your execution tools. StrataTree enforces the hierarchy, validates structure, and handles the Jira/Azure DevOps sync automatically.

StrataTree never deletes work items in your execution tool. When you remove an item from the map, StrataTree detects it during the upload preview by comparing against what you originally downloaded. By default it leaves those items alone; if you choose to close them, StrataTree changes their status rather than deleting them — Jira issues are transitioned to Closed, and Azure DevOps work items are set to the Removed state. If your download was filtered or scoped (by date, iteration, or excluding closed items), or you're uploading to a different project, StrataTree does not flag deletions at all, since a missing item may simply have been filtered out. Your execution tool always stays the source of truth for what actually gets closed.

Unlike other tools that require a license for each person on your team, StrataTree can be used in onsite and online meetings by one team member. The scribe model is a meeting approach where one person, typically the Product Owner or Scrum Master, operates StrataTree while the rest of the team contributes verbally. The scribe projects their screen for in-person meetings, or shares their screen over Zoom, Teams, or Google Meet, adds and moves map items, and adjusts structure based on the team's discussion.

At the end of the meeting, the scribe syncs the finalized map back to Jira or Azure DevOps, or saves the map to their local file system or a network file share. The rest of the team sees the organized result directly in Jira or Azure DevOps, with no StrataTree account required.

Yes. StrataTree works as a standalone planning tool for teams that do not use enterprise tracking systems. You can plan, refine, and track delivery directly from your StrataMap, making it a practical option for small teams, independent product owners, and anyone who needs structured planning without the overhead of a full enterprise tool setup.

StrataMapping has been applied successfully across a wide range of project types: software and hardware development, IT initiatives such as system upgrades, office relocations, and home remodeling projects. The methodology's structured approach to identifying users, defining features, and sequencing work translates across domains wherever a project has scope that needs to be organized, prioritized, and executed.

Yes — AI Map Builder is included free during early access on Explorer, Product Owner, and Portfolio (and available on Enterprise). It uses your own AI provider key, so we never sell or mark up tokens. If that ever changes, we'll give existing customers advance notice.

The Explorer tier is free indefinitely with no credit card required. You can connect your Jira or Azure DevOps instance, pull in an existing backlog, and build your first StrataMap in a single session. If you decide StrataTree is right for you and upgrade to a paid tier, your current StrataMap from the Explorer session will be available to continue working with immediately. The Documentation covers the setup process step by step. If you want to see the tool in action first, the demo video on the home page walks through the core workflow from import to sync on a sample Jira backlog.

No. Only the person managing the map needs a paid StrataTree account. One team member acting as scribe shares their screen during planning meetings while the rest of the team contributes verbally. After the session, the scribe syncs the updated map to Jira or Azure DevOps, and the entire team sees the organized, structured backlog directly in their existing tools.

StrataTree exists to solve a specific problem: creating and organizing product backlogs in a way that creates the optimal path to delivery by removing the friction between planning, organizing, and syncing to execution tools like Jira or Azure DevOps.

If your current backlogs stay clean, your maps in Miro or Mural stay synchronized with your execution tools, and you can easily build on them as the project progresses or for future releases, then you may not feel the need to change. Most teams using a mapping approach in tools that do not enforce structure find that eventually the drift between their maps and their backlogs grows to where the map stops reflecting reality. StrataMapping's strict rules prevent that drift from happening in the first place. If your team spends time after every planning session manually cleaning up the board or re-entering data into Jira or Azure DevOps, or starts from scratch with a blank canvas for each release, switching to StrataTree will provide immediate and lasting benefits.

A spreadsheet gives you rows; a mind map gives you branches. Neither enforces planning structure, handles release boundary logic, or integrates to your execution tools. StrataTree gives you a planning environment that knows the rules of the StrataMapping methodology, applies them as you work, and connects your map to your execution tools like Jira or Azure DevOps. It fills a specific gap that general-purpose tools, spreadsheets, mind maps, and whiteboards were not designed to address.