Reinventing Project Management for AI-Driven Development

For years, the team at XB Software ran Time & Materials (TM) projects the way most experienced PMP-certified leaders do. They started with a draft scope. Their business analysts detailed each module, split it into features, and submitted tickets to Jira. Then the project manager and tech lead built a Work Breakdown Structure (WBS), mapping tasks, estimating effort, and creating the backbone for forecasting and change control.

With AI coding assistants, WBS started to feel like a straitjacket. In search of something more suitable, the team discovered the Value Breakdown Structure (VBS) and the concept of functional slices. This article describes how XB Software moved from a legacy VBS + WBS + Manual Development model to a modern VBS + Functional Slices + AI-assisted Development framework adapted for Time & Materials engagements.

Traditional Manual Development with VBS and WBS

How the Team Used to Work

In the traditional TM model, the team layered two structures:

• Value Breakdown Structure (VBS), a strategic decomposition of the project into stakeholder outcomes, used for client alignment and high‑level roadmapping. It was largely a planning artifact, fixed early and updated infrequently. Feedback came late, and course correction was expensive;
• Work Breakdown Structure (WBS), a decomposition of features into component‑level tasks. This was the commercial backbone, driving estimates and tracking.

The old development process required the team to follow this path each time they developed features:

1. BA Detailing. The BA detailed a module, split it into features, and submitted tickets to Jira;
2. WBS Creation. The PM and tech lead broke each ticket into granular tasks, estimated hours, and mapped dependencies;
3. Manual Development. Developers implemented tasks in parallel with integration overhead routinely added 20-30% to estimates.

This worked when development was the primary constraint and WBS tasks reflected actual effort. For TM clients, it gave clear visibility into where hours were going.

Read Also Time and Materials (TM) Contract vs Fixed Price (FP). Which One Is Better?

Where It Broke with AI

When XB Software integrated AI coding tools into their tech stack and tried to keep the WBS, several problems emerged:

• Mismatched Granularity. A WBS built for manual coding breaks work into pieces sized for a developer's day. AI completes those same pieces in minutes;
• Unstable Velocity Metrics. A task estimated at 10 days might be completed in 2, while a similar task might still take 5 due to AI's unpredictability. Hour-based velocity metrics became unstable. Clients began asking why everything couldn't be delivered just as fast;
• Bottleneck Migration. Jira showed development as "green" (implemented early), but the overall project timeline didn't shrink proportionally. The bottlenecks had simply shifted to specification, integration, and validation areas that the WBS didn't adequately track;
• Administrative Drag. The team was creating dozens of granular tickets for work that AI was handling in minutes. Project managers spent more time maintaining the WBS than managing client value;
• Forecasting Collapse. Historical hour-based data became unreliable. The team could no longer predict project timelines based on component-level effort estimates because AI's impact was inconsistent across task types;
• Commercial Transparency Distortion. Clients saw detailed hour estimates, but those hours no longer reflected actual effort distribution.

In AI-assisted development, the constraint shifts away from coding toward decision-making, validation, and alignment. The WBS, designed to manage labor, begins to hinder both delivery and transparency as implementation accelerates.

XB Software's New Project Management Approach: VBS with Functional Slices and AI-Assisted Development

The new framework developed by the XB Software team keeps the strategic clarity of VBS, but replaces component‑level WBS with Functional Slices as the primary unit of execution. The shift is from managing work to managing value flow.

What is a Functional Slice?

A Functional Slice is a complete, end‑to‑end piece of user‑facing functionality that delivers measurable value. It is:

• Vertically integrated. Cuts through UI, business logic, and data layers with no hidden integration work between layer;
• Independently valuable. Can be demonstrated and, if needed, deployed alone;
• Bounded. Clear completion criteria, typically sized for 1-3 days of AI‑assisted effort;
• Testable. Can be shown to stakeholders immediately upon completion.

How Do VBS, Decomposition, and Execution Change?

Strategic (VBS)

The VBS shifts from a fixed, upfront promise of future value to a living, continuously reprioritized backlog. It is no longer a contract to be fulfilled, but a hypothesis tested every few days. Priorities are set at project start only as a starting point. After each demo, real stakeholder feedback reshapes what comes next. Value is realized incrementally from the first week, misalignment is caught in days at trivial cost, and the question driving the backlog becomes "What value should we deliver next?" instead of "What value did we promise to deliver by the end?"

Tactical (Decomposition)

The unit of decomposition changes from pieces of work (WBS tasks) to units of value (Functional Slices). Deliverables are no longer a collection of horizontal components, they are vertically complete capabilities that a user can interact with.

Execution (Implementation)

Development moves from manual, component‑level coding to AI‑orchestrated, slice‑level implementation. Developers write fewer lines themselves; their role becomes orchestrating AI, reviewing generated code, integrating slices end‑to‑end, and validating the outcomes.

How XB Software Put the New Approach into Practice

Defining and Estimating Slices

BA detailing shifts from tasks to slices. Instead of breaking a module into WBS tasks, the Business Analyst defines Functional Slices, each a deliverable value unit with clear acceptance criteria (AI‑ready), design references, and non-functional requirements. A PM reviews them for VBS alignment. QA and the tech lead review the feasibility, consistency, and integrity.

Let's look at an example of how a task like "Enable secure client onboarding" would be solved using the old and new methods:

• Old approach: 7 tasks, 10 days total (registration form, database schema, Stripe integration, email verification, API docs, admin notification, integration & testing buffer);
• New approach: 3 Functional Slices, 4.5-6 days total (Account Creation & Verification, Billing Setup, Onboarding Wizard).

Estimates move from task‑hours to slice‑days. Forecasting now uses slice‑days, calculated as:

Slice Estimate = Traditional Story Estimate × AI Efficiency × Exploration Tax × Experience Factor

• Traditional Story Estimate: What this scope would have taken with manual development;
• AI Efficiency: How much AI accelerates this specific type of work (ranges from 0.6x for AI-friendly tasks to 1.2x for tasks requiring extensive human judgment);
• Exploration Tax: Time needed to verify AI outputs, fix AI-generated issues, and navigate ambiguity in requirements;
• Experience Factor: How proficient the developer is with AI tools.

The team continues tracking actual hours per slice for TM transparency, but forecasting relies on slice throughput, which is a much more stable metric.

Managing the Slice Flow

Jira becomes a Slice Flow Manager. The workflow was redesigned to reflect the new reality while preserving TM visibility:

• Epics: Represent VBS items;
• Stories: Represent Functional Slices;
• Tasks per slice are limited to three types (Spec & Design, AI Implementation, Validation & QA). The "AI Implementation" task is not broken into component subtasks. Only actual hours of BA, UI/UX Designer, Software Developer, and QA are tracked. Clients see slices completed vs. remaining, actual hours per slice, and throughput trends.

Dynamic VBS prioritization and change control. With slices delivering value in days, the team now uses VBS differently:

• Before each demo the VBS is reviewed with the client to confirm priorities;
• After each demo feedback is captured and the VBS is adjusted immediately;
• *Every 1-2 weeks* the VBS is refined based on what has been learned.

Change requests are handled at the slice level. No more re‑estimating dozens of WBS tasks. A new feature becomes 1-3 new slices added to the VBS backlog. A modification means revising or splitting affected slices, and scope removal simply deletes them.

Example: Client requests a new "Social login" option after seeing the demo.

Forecasting switches from effort to throughput. Before: "We have 200 hours remaining, and our team velocity is 100 hours/week, so we will finish in 2 weeks." The problem was that AI volatility made hour-based velocity unstable. Now: "We have 12 slices remaining. Throughput is 4-5 slices/week. We'll deliver in 2.5-3 weeks, with each slice demonstrated as it's done." Hours are still reported, but the planning horizon is governed by slice throughput.

Adapting Processes and Roles

Agile practices evolve from time‑boxed sprints to flow‑based delivery. When slices deliver value in days, fixed two‑week Scrum sprints become less meaningful. Sprints become arbitrary containers for work rather than meaningful delivery cadences. If a slice takes up to 3 days, that's fine—the client sees working software when it's ready, not on a fixed calendar date.

Team roles redefined. Every role reorients from managing activities to orchestrating value flow:

Conclusion: From Managing Labor to Managing Value Flow

In this approach, VBS becomes a living backlog, reprioritized after each demo, aligned with stakeholder feedback. Value is decomposed into shippable slices, throughput is measured, and working software is delivered every few days. In the era of AI-driven development, the real question is how quickly management models can be reshaped to harness its potential.