Summary
Traditional project management with Work Breakdown Structure (WBS) fails in AI‑assisted development because hourly estimates become volatile, administrative overhead spikes, and value is delivered too slowly. The solution replaces WBS with Functional Slices (complete user value delivered in 1-3 days).
For years, we ran Time & Materials (TM) projects the way most experienced PMP-certified leaders do. We started with a draft scope. Our 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, we discovered the Value Breakdown Structure (VBS) and the concept of functional slices. This article describes how we 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 We Used to Work
In our traditional TM model, we 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 our commercial backbone, driving estimates and tracking.
The old development process required to follow this path each time we develop features:
- BA Detailing. Our BA detailed a module, split it into features, and submitted tickets to Jira;
- WBS Creation. Our PM and tech lead broke each ticket into granular tasks, estimated hours, and mapped dependencies;
- 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 we integrated AI coding tools into our 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. Our hour-based velocity metrics became unstable. Clients began asking why we couldn’t deliver everything 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 our WBS didn’t adequately track;
- Administrative Drag. We were creating dozens of granular tickets for work that AI was handling in minutes. Our project managers spent more time maintaining the WBS than managing client value;
- Forecasting Collapse. Historical hour-based data became unreliable. We 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
Our new framework 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 or Horizontal 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 We 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, our 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).
Read Also Lost in Translation: How to Overcome Miscommunication Between Clients and Business Analysts
Estimates move from task‑hours to slice‑days. We now forecast using 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.
We continue tracking actual hours per slice for TM transparency, but forecasting relies on slice throughput, which is a much more stable metric.
Read Also AI as a Co-Pilot, Not an Autopilot: Guidance on Risk Management and Realistic Performance
Managing the Slice Flow
Jira becomes a Slice Flow Manager. Our 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). We do not break the “AI Implementation” task 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, we now use VBS differently:
- Before each demo we review the VBS with the client to confirm priorities;
- After each demo we capture feedback and adjust the VBS immediately;
- Every 1-2 weeks the VBS is refined based on what we’ve 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.
| Old WBS Approach | New Slice Approach |
| Add tasks: OAuth integration (2d), UI modifications (1d), testing (1d), documentation (0.5d) | Add a slice to VBS: “Social Authentication (Google/LinkedIn)”. Estimated 1.5-2 days |
| Total: 4.5 days of effort, hours of analysis | Total: 2 days of effort, 15 minutes of analysis |
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 is 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 Our 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.
Read Also AI as a Co-Pilot, Not an Autopilot: Guidance on Risk Management and Realistic Performance
Team roles redefined. Every role reorients from managing activities to orchestrating value flow:
| Role | Old Focus | New Focus |
| Business Analyst | Requirements collection, ticket writing, WBS decomposition | Value hierarchy (VBS), AI-ready acceptance criteria, slice definition, VBS refinement, continuous stakeholder alignment |
| Developer | Manual coding, task-level execution, component integration | AI orchestration, prompt engineering, code review, system integration, validation of AI outputs |
| Project Manager | Hour tracking, WBS maintenance, resource allocation, component-level forecasting | Slice flow management, bottleneck identification, VBS-driven client communication, throughput forecasting |
| Tech Lead | Task decomposition, dependency management, manual code reviews | Slice technical boundaries, integration architecture, AI tool coaching, quality standards for AI-generated code |
Conclusion: From Managing Labor to Manaslging Value Flow
In our approach, VBS becomes a living backlog, reprioritized after each demo, aligned with stakeholder feedback. We decompose value into shippable slices, measure throughput, and deliver working software every few days. In the era of AI-driven development, the real question is how quickly we can reshape our management models to harness its potential. If you’re ready to move beyond hour‑based reports and start seeing working software delivered incrementally, contact us to put this framework to work on your next development project.
