Relative complexity is a Software Development Lifecycle (SDLC) estimation framework that measures work based on volume, complexity, knowledge gaps, and uncertainty rather than fixed time estimates. A story may look small, but turn out to be hard because the architecture is fragile, the requirements are unclear, or the team has never touched a key dependency before. Relative complexity gives the team a shared language for why something is large, risky, or not ready to commit.
The relative complexity model evaluates software delivery work using four variables: volume, complexity, knowledge gap, and uncertainty.
Together these variables help the team separate "how much work is there" from "how hard is the solution," "how much still needs to be discovered," and "what could still surprise us."
The goal of relative story pointing in this model is to establish a human-only baseline. That is the amount of relative complexity a person or team can complete in a sprint using the current SDLC process before any agentic AI assistant is introduced. If one developer can complete 15 points in a sprint, that 15-point capacity becomes the reference.
Once established, the baseline stays fixed until the organization makes a deliberate choice to reset it. When an agentic assistant enters the picture, the human baseline doesn't change on its own. What changes is the total relative complexity the team can complete, because the assistant takes on or accelerates selected SDLC activities.
If the human-only baseline is 15 points per sprint, an agentic assistant may allow the same person to complete 30 to 40% more relative complexity. The work hasn't become trivial.
The delivery system has gained capacity because the assistant handles portions of execution, including code scaffolding, test generation, documentation drafting, defect analysis, and requirements summarization. Judgment, validation, review, integration, and accountability stay with the human.
| Scenario | Human Baseline | Assistant Uplift | Total Sprint Capacity | What Changed |
|---|---|---|---|---|
| Human-only SDLC | 15 |
|
15 | All work completed through current human process |
| Human + Assistant, Conservative | 15 |
|
18 | Limited drafting, analysis, repetitive work |
| Human + Assistant, Moderate | 15 |
|
20 | Meaningful support for coding, testing, and documentation |
| Human + Assistant, Strong | 15 |
|
21 | Assistant accelerates lower-judgment activities |
| Mature Human-Agent Pattern | 15 |
|
23+ | Repeatable workflows with guardrails and review patterns |
Agentic assistants don't eliminate relative complexity. What they do is increase the amount of relative complexity the team can complete in a sprint by shifting selected SDLC activities from human-only execution to human-plus-assistant execution. That distinction matters when you're trying to measure what changed.
A baseline is useful only if it stays stable long enough to compare results. Think of it like a reference point in a scientific experiment. If you keep adjusting the control every time you add a new variable, you can't tell which variable produced which result. The same logic applies here. If the baseline is recalculated every time a new assistant, automation, or AI-enabled workflow arrives, the organization loses its ability to measure whether assistants are increasing capacity, shifting work downstream, or creating new complexity.
The baseline changes only when the organization makes a point of establishing a new one. Until then, every assistant-enabled result gets measured against the original human-only baseline.
| Measurement Point | What It Tracks |
|---|---|
| Human-Only Baseline | Establishes the original sprint-capable complexity using the current human delivery model. |
| Human + Assistant 1 | Measures how the first assistant changes total sprint complexity capacity. |
| Human + Assistants 1-2 | Measures whether additional assistants increase capacity or add validation and orchestration work. |
| Human + Assistants 1-N | Measures cumulative impact on throughput, quality, governance, and flow. |
| New Baseline | Created only after the new operating model is stable enough to become the reference point. |
Recalibration should be deliberate, evidence-based, and rare. Don't reset the baseline because a pilot looked promising or a new tool went live. A new baseline is warranted only when the human-plus-assistant operating model has become repeatable under normal sprint conditions. And that takes longer than most teams expect.
| Signal | What to Check |
|---|---|
| Sustained delivery performance | Multiple sprints show stable capacity, flow, and quality, not a one-time spike. |
| Mature assistant workflows | Prompt patterns, guardrails, review steps, and exception handling are repeatable. |
| Reduced knowledge gap | Teams know where assistants perform well and where human judgment is required. |
| Stable governance and controls | Security, compliance, traceability, and approval paths work at delivery speed. |
| Quality remains acceptable | Defects, rework, and escaped issues do not increase as capacity rises. |
| Operating model adoption | Assistant use is no longer experimental. It is part of normal SDLC execution. |
A practical rule is to wait until the new human-agent model has held up for several sprints before recalibrating. At that point, the organization may decide the old 15-point human-only baseline should be replaced by a new one, say 20 or 21 points per sprint. Document the reset so future improvements can be measured against the new reference.
Each of the four variables is scored from 1 to 5. A higher score means the work is harder to complete and harder to predict. For knowledge gap, a high score means the team has less familiarity and more discovery ahead of them. Any score of 5 should be re-evaluated with the intent of lowering the complexity.
| Score | Volume | Complexity | Knowledge Gap | Uncertainty |
|---|---|---|---|---|
| 1 | Very small task | Familiar pattern | Team knows how to do it | Clear, low risk |
| 2 | Small scope | Minor logic or coordination | Most knowledge exists | A few open questions |
| 3 | Moderate work | Moderate technical or process challenge | Some discovery needed | Assumptions need validation |
| 4 | Large, multiple dependencies | High integration, architecture, compliance, or quality concern | Limited experience | Several unresolved risks |
| 5 | Very large, split recommended | Novel, cross-system, or high-risk | Critical knowledge missing | Feasibility, approach, or requirements unclear |
Start with human-only delivery. Measure the amount of relative complexity completed in a sprint before any agentic assistant enters the picture. The baseline should reflect normal sprint conditions, including existing skills, tools, ceremonies, review practices, dependencies, and quality expectations. Don't optimize for the baseline sprint. Use it as an honest picture of how the team delivers today.
To set the baseline, score completed work across the four variables, volume, complexity, knowledge gap, and uncertainty. Use several representative sprint items rather than a single story so the baseline captures the normal mix of work. If the team can complete 15 points of relative complexity in a sprint, that becomes the reference for measuring what assistants add.
Based on the definition of a score of 5 in volume, complexity, knowledge gap, and uncertainty, the likelihood of being able to complete this story is very low. When a 5 is encountered, you should reevaluate and identify what is driving this.
If you can identify the complexity, attempt to simplify it or split the story into what can be completed and what is causing the complexity. If you are not able to identify the complexity, you should consider returning this to the team backlog for further evaluation by the business owner, product owner, and solution architect.
| Relative Complexity | Volume | Complexity | Knowledge Gap | Uncertainty |
|---|---|---|---|---|
| 1 | 1 | 1 | 1 | 1 |
| 2 | 2 | 1 | 1 | 1 |
| 2 | 2 | 2 | 1 | 1 |
| 3 | 2 | 2 | 2 | 1 |
| 5 | 2 | 2 | 2 | 2 |
| 8 | 3 | 2 | 2 | 2 |
| 8 | 3 | 3 | 2 | 2 |
| 13 | 3 | 3 | 3 | 2 |
| 21 | 3 | 3 | 3 | 3 |
| 34 | 4 | 3 | 3 | 3 |
| 34 | 4 | 4 | 3 | 3 |
| 55 | 4 | 4 | 4 | 3 |
| 89 | 4 | 4 | 4 | 4 |
| 144 | 5 | 4 | 4 | 4 |
The table is not meant to create false precision. It supports a better estimation conversation by showing how multiple elevated variables compound relative complexity. Getting that calibration takes a few sprints of practice.
During backlog refinement or sprint planning, score each variable before assigning the final relative complexity value. The conversation that comes out of this is the real output. If one person scores uncertainty as 1 and another scores it as 4, the team has surfaced a hidden assumption that needs resolution before anyone commits to anything.
For assistant-enabled work, compare completed sprint complexity against the fixed human-only baseline. If the baseline is 15 and the human-plus-assistant team delivers 21 points, that's a 40% capacity increase.
The next question is whether that increase came with acceptable quality, security, compliance, and flow. Speed without that check is noise.
This is the core measure. Compare total sprint throughput against the fixed Human-Only Baseline.
Look for where the assistant absorbed repeatable or lower-judgment work.
Some of that added work is invisible until you look for it. Complexity shifted downstream still counts as complexity.
Capacity gains that come with rework, escaped defects, or compliance gaps are not gains.
A single good sprint is not evidence. Stability across several sprints is.
The most common mistake when measuring agentic AI productivity is resetting the human-only baseline too often. The baseline loses its value the moment teams start adjusting it to reflect every new tool or assistant that gets deployed. Keep it fixed. The whole point is to have something stable to measure against.
A related mistake is expecting complexity to drop as soon as an assistant arrives. Assistants may reduce human execution effort while adding validation, governance, or coordination work on the other side. That's not a failure. It's the normal shape of early adoption, and the model is designed to capture it if you hold the baseline still.
Teams also tend to focus on local task speed rather than completed relative complexity across the sprint. An individual story moving faster is encouraging. It's not the measure. The measure is whether the sprint as a whole delivers more, with quality and flow intact.
Treat the model as a guide, not a calculator. The scores exist to support a better estimation conversation, not to produce a number the team then accepts without discussion.
Relative complexity gives SDLC teams a practical frame for estimation and a reliable way to measure what agentic assistants contribute. The human-only baseline establishes how much relative complexity the team can complete before assistants enter the picture, and it stays fixed until the evidence supports resetting it.
In practice, most teams feel the pull to reset before the evidence is there. A sprint goes well, an assistant delivers real uplift, and the old baseline starts to feel like a low bar. That's when holding it matters most.
The baseline isn't a constraint on ambition. It's the only thing that tells the team whether their results are real.
If a 15-point human baseline reaches 20 or 21 points with consistent assistant support, and that holds across several sprints without quality or governance slipping, the team has earned a new baseline. Until then, the old number is doing its job.
Global Behavioral Change Management Lead
Chris Murphy is Coforge's Global Behavioral Change Management CoE Lead. He brings 40 years of IT experience, 18 years of Agile experience, and 12 years of Organizational Change Management experience to his work with clients. Chris started his AI journey in the mid 1990s, using Bayesian Belief Networks with Genetic Algorithm optimizers to predict persistent patterns in financial data. Chris holds SAFe Program Consultant and Certified Scrum Product Owner certifications. He led the Global Agile Center of Excellence at Mindtree before joining Coforge. Clients know him for asking the right questions and turning their needs into action that delivers real business value.