I’ve been exploring the new “Implementation Plan” capability in Pega Infinity '26 and I’m trying to better understand its intended purpose and design philosophy.
Initially, I assumed it was something similar to a lightweight agile project management tool, where teams could manage Product Backlogs, Sprint Backlogs, Story Points, Velocity, Burndown Charts, etc.
However, after actually using it, I noticed that it seems intentionally much simpler. From what I can see, a task (story) mainly contains:
- Status (To Do / In Progress / In Review / Done)
- Owner
- Due Date
- Description
- Associated Feature
- Attachments
I could not find concepts such as:
- Product Backlog Items (PBIs)
- Epics
- Sprint planning
- Story points
- Velocity
- Burndown charts
- Release planning
This made me wonder about the original vision behind Implementation Plan. Is the expectation that teams will continue using dedicated agile/project management tools such as Jira or Azure DevOps for planning and estimation, while using Implementation Plan only for execution within Infinity Studio? Or is Implementation Plan intended to gradually become the central work-planning experience inside Infinity Studio?
Also, is there any particular reason why estimation-related concepts (Story Points, Velocity, Capacity, etc.) are absent? Was the feature intentionally designed to focus on implementation activities and AI-assisted development rather than agile project management?
I searched the documentation but could not find much information regarding the design goals or recommended usage patterns. Any insight from the product team or members who have already adopted it would be greatly appreciated.
Hi Cloe, thanks for your question! The Implementation Plan feature is Pega’s way of ensuring that the validated business outcomes established during Blueprinting are carried forward into the Authoring phase of the Blueprint Delivered Methodology. There is a strong prioritization of value from working software over extensive, exhaustive documentation. The Implementation Plan makes this concept seamless with the new AI Assistant capabilities.
Why are we making this change now? The modern AI-native SDLC has uncovered many gaps within the traditional way of building software. Going back to Alistair Cockburn and Ron Jeffries when the Agile Manifesto was first written, user stories were intended solely as “a promise for a conversation” - serving as placeholders to ensure project stakeholders and users talk about what needs to be built, and more importantly, why. In Pega the “why” is already answered by the Blueprint, and the conversations have already occurred by the time we reach the Authoring phase.
Over the last 20+ years since the inception of Agile, user stories have instead strayed to endlessly detailed, upfront requirements that were out of date before the team even started to build. This is simply no longer viable with new AI capabilities that allow for rapid iteration.
Jeff Gothelf just wrote a great article that alludes to the direction Infinity Studio is taking. In the article he outlines scenarios in which a feature planning session is immediately derailed because an engineer built the feature to be planned before the meeting started. The planning suddenly becomes a lot less important when the timeslot could instead be used to discuss, iterate, and refine what has already been built.
In the interim, teams are still able to use whatever project management tools are needed, and they can still document requirements to whatever extent their organization requires. We are purposefully not putting this administrative overhead into Infinity Studio. This allows it to maintain focus on building software, accelerated by AI.
Great observations - I think you’ve actually reverse-engineered the design intent correctly.
The absence of PBIs, story points, velocity, and burndown charts reads as deliberate, not immature. Those constructs exist to manage a scarce resource: developer time. Implementation Plan seems built for a world where that assumption is weakening.
A few things I’d highlight:
It’s anchored to the application model, not the project model. Tasks associate to Features — the same Feature objects that trace to your Blueprint and your case types. Jira and ADO have Feature/Epic hierarchies too, of course, but there they’re work-tracking artifacts describing the application from the outside; keeping them in sync with what’s actually built depends on naming discipline, ticket hygiene, or integration connectors. In Implementation Plan the traceability is native to the platform. As a BA, the chronic pain was never tracking sprints — it was reconciling the backlog with the real application, and that’s the gap this closes.
AI-assisted development changes what estimation means. When Blueprint and agentic development can stand up a working draft of a flow in hours, story points and velocity lose their meaning as a prioritization denominator. Jeff Gothelf made this argument well in a recent piece: when everything is cheap to build, effort-based models like RICE stop sorting anything, and the useful questions become what a piece of work teaches you and how reversible it is. A simple To Do / In Progress / In Review / Done model with an owner and a due date fits that world better than sprint ceremony does.
It’s not trying to replace Jira/ADO — yet. For enterprise programs with PMO reporting, capacity planning, and cross-team dependencies, I’d still expect the heavyweight tooling to own planning, with Implementation Plan owning execution traceability inside the Studio. Whether it grows into the central work-planning experience probably depends on adoption, but the current scope looks intentionally focused on keeping build activity connected to the application design rather than recreating an agile PM suite.
So in short: I’d treat it as an execution and traceability layer purpose-built for AI-assisted delivery, and keep your estimation and release planning where they are for now.