Fidelity – The Lost Dimension of the Iron Triangle

One the topics that I find a lot of people find particularly interesting and useful is that of Fidelity in software. This generally comes up while I’m talking about incrementing and iterating, and the difference between the two. I’ve already touched on this when discussed whether a Kanban System eschews iteration. This post will build on that, and describe what I mean by Fidelity.

The Iron Triangle of Project Management is a well known concept. There are a number of basic variables to project delivery; scope, cost and time. Not all these variable can be fixed, and generally quality is in the middle as another non negotiable variable.


This can be related to a typical Agile Burndown, in that the Horizontal Axis is Time, the Vertical Axis is Scope, and the burndown slope is a function of cost and time. Keith Braithwaite and Joseph Pelrine both blogged about this after a conversation we had in Zurich earlier this year. I like to add a 3rd variable into that function that determines the slope – fidelity.


Fidelity is similar to concepts I picked up from a number of places. One is Dimensional Planning where a number of different solutions are planned, each with a different level usability. A Dirt Road solution is the most basic, a Cobble Road solution is intermediate, and a Tarmac Road solution is the best.


Another source is Jeff Patton’s work, and in particular his approach to grading features. Similar to school or college work, each feature can be graded from A to F, where A is the best solution, and F is the least acceptable. Understanding how our customers perceive features in these terms, along with what the minimum acceptable grade is, helps with knowing when to continue working (and maybe come back later) or when to stop and move onto another feature. My colleague Simon Bennett refers to this a Balanced Scorecard technique.


So fidelity refers to the finesse of the feature, or solution. A low fidelity solution will be low in things like precision, granularity, or usability, but will still solve the original problem. As fidelity increases, so does the precision, granularity, usability etc. I prefer to make a distinction between fidelity and quality to avoid getting into discussions about compromising on quality. One recent project I was involved with talked about fidelity in terms of Rich, Richer and Richest.

Fidelity, as I have described above, can be useful when understanding the difference between incrementing and iterating, and how they can be effectively combined. We can consider 4 distinct approaches; Big Bang, Incremental, Iterative and Agile.

Big Bang

A Big Bang approach is neither iterative or incremental. Architectural components are built to full fidelity, for the full scope, and are fully integrated once at the end.

Big Bang 1

Big Bang 2

Big Bang 3


The purely incremental approach builds each feature, across all components, to full fidelity, one by one.

Incremental 1

Incremental 2

Incremental 3

Incremental 4


The purely iterative approach builds all the features, across all components, to the lowest fidelity, and then increases the fidelity to the highest level.

Iterative 1

Iterative 2

Iterative 3


An Agile approach combines the incremental and iterative approach by building each feature, one by one, at a low fidelity, and then both gradually adding features and increasing their fidelity until the right combination is achieved. Full fidelity is not always necessary.

Agile 1

Agile 2

Agile 3

Agile 4

Agile 5

Agile 6

It is by adding the Fidelity dimension into the mix that Agile projects can achieve the flexibility required to deal with typical scenarios where scope, cost and time become fixed, without resorting to cutting on quality. Fidelity provides a mechanism to effectively vary scope, while still meeting all the customers needs and solving their problems.

Rating: 4.8. From 49 votes.
Please wait...

14 comments on “Fidelity – The Lost Dimension of the Iron Triangle

  1. Awesome post Karl!

    No votes yet.
    Please wait...
  2. Pingback: Dew Drop – December 23, 2009 | Alvin Ashcraft's Morning Dew

  3. Wow, nice post.

    I wonder if there is value in developing an exercise to practice building low fidelity solutions. It seems to me that it’s generally easier to visualize / design a full fidelity solution than a low fidelity one. But in general, you can save the business both time and money by providing a low fidelity solution first. In some cases you may be able to use the low fidelity solution to pay for development of a high fidelity one.

    Anyway, those are just stray thoughts. Thanks for the great post!

    No votes yet.
    Please wait...
  4. Great post Karl!

    Nice job distinguishing the concept of Fidelity and its usefulness across the spectrum of development approaches. I think the visuals really help.

    In the last project on which I was a Scrum Coach, Fidelity was especially important in defining a new UI paradigm. Lower fidelity models built in an Agile fashion really help to educate customers and stakeholders on the important design elemens being presented without unnecessary debates about visuals elements that come with higher fidelity implementations.

    No votes yet.
    Please wait...
  5. Love this post and it hits on something that I think a lot of people don’t think about. I definitely think i’ll have to work up some exercises around this concept.

    No votes yet.
    Please wait...
  6. Pingback: agile project management

  7. I love this post, and refer to it frequently when folks struggle with trading off the dimensions of the iron triangle.

    However, one suggestion I would make (especially is this is going into Karl’s upcoming book) is to pivot the 3D charts so that scope remains the horizontal axis; architecture becomes the vertical axis; and fidelity becomes the depth axis.

    This new layout would then be consistent with the “slicing” terminology we use when advocating for Lean-Agile, i.e., “vertical thin-slicing” scope over “horizontal slicing” architecture, and “depth” (fidelity) of software feature / scope.


    No votes yet.
    Please wait...
  8. Great post!!!

    No votes yet.
    Please wait...
  9. Pingback: Agile, incremental and iterative development |

  10. Very Nice post Karl..! Got a very fair idea on how things are different and gradually how the market got changed from One Phase of Model to Another.

    Thanks Again.>! Nice reading this content.

    No votes yet.
    Please wait...
  11. Pingback: AGILE | garrettgingell

  12. Brilliant!

    No votes yet.
    Please wait...
  13. Pingback: B2B - Project Management Methodology - The Puzzled Premed

  14. wonderful explanation without creating any ambiguity around the topic and beautiful diagrammatic explanation.

    No votes yet.
    Please wait...

Comments are closed.