Author: Steve VanArsdale, CSM, PMI-ACP
CA Clarity Agile Architect, VanArsdale & Associates
Article previously published as “The Agile Theory of General Relativity” in the Agile Record magazine (August 2013, Issue No. 15, www.agilerecord.com)
Agile has a Manifesto. It’s about time Clarity users had a universal truth.
The results of [a] previous investigation lead to a very interesting conclusion, which is here to be deduced1 . It has been shown in several ‘previous investigations’ that inherent in Agile projects there are story points delivered over a progression of time with a relatively steady flow of money spent. What is worth considering is the nature of that relationship, and whether it is a predictable relationship.
If we imagine one factor is the cumulative duration of all the project time-boxes, and a second factor is the progressive expenditure that ultimately funds the work, then we can posit a third factor that represents the work being delivered.
TB can be the factor for the time-box for an iteration, as shown in Figure 1:
The sum of the time-boxes, or ∑TB is the total time value for the project as whole.
The funding pool, or $AGILE can represent the total amount of money allocated to pay for the story points (value) to be delivered.
The value delivered in an Agile project is delivered and accepted at the end of each iteration, and could be represented by vI for any specific iteration. Collectively, over the life of the project, the cumulative value delivered and accepted represents the total work or value of the project effort. This could be represented by ∑vN
In other words, over time the total duration of time-boxes expressed as ∑TB combined with the funding pool for development over this duration expressed as $AGILE ultimately suggests there is a sum of the values in the iterations, ∑vN
The concepts here represent three fundamental elements of any Agile project. It can be shown these elements form the basis of the relationship of Agile to the fundamental concepts of PMBoK2 defined-process projects.
From this equation it directly follows that:
if TB is the time-box for an iteration, then the sum of the time-boxes, or ∑TB is the time box for the project as whole.
This has been called T
and corresponds to PMBoK project Time.
Similarly, the Agile funding pool, or $AGILE is the amount allocated to pay for the stories (value) to be delivered. To the project Sponsors and Client, this is known as Cost.
In this context this is often labeled as C
and corresponds to Cost.
The principles of the Agile Manifesto dictate that the value delivered in an Agile project is delivered and accepted at the end of each iteration. Yet to the stakeholders, each delivered story includes more than simply the effort, and more than simply the relative value to the Product Owner. The value that is accepted includes the feature or features that meet the Client’s requirements, plus the specific aspects that make it useful, as well as the general ‘fit’ of the deliverable in appearance and functionality. In actual fact, it also inherently includes the technical mechanism, the risk of the technical and functional approach used, the effort and/or cost necessary to deploy the deliverable, and even the necessary administrative costs to support and maintain the deliverable over its useful life. All this is implicitly included in the value accepted at the end of the iteration. Collectively, over the life of the project, these cumulative “values” delivered and accepted represents the total work or value of the project. In the conventional context of the stakeholders’ project expectations, this is the PMBoK Scope, and is often labeled as S.
Together, these represent a special relationship in all projects. It is often expressed using the terms as “Time plus Cost yields Scope”, or T+C=S.
This relationship is most often graphically expressed as three intersecting vectors, constrained at their intersections, in a triangle. If we imagine one of the angles of the triangle to be a 90-degree right angle, there is a well-known rule about such relations. Specifically, with appreciation to Pythagoras, that rule is a2 + b2 = c2.
Recognizing T plus C yields S with the rigor of a2 + b2 = c2
-while accepting the equivalency of the three Agile factors ∑TB and $AGILE and ∑vN
-and applying the transitive relation “A=B and B=C then A=C”
-implies a recognition of ∑TB + $AGILE > ∑vN with equal validity.
A small mental experiment will illustrate:
Time is always considered a steady progressive vector. There is little argument on this. It can be marked in time periods or in time-boxes, but Time can be seen to be a fundamental project dimension in both Agile and defined-process projects. It is generally agreed to be linear, and is depicted in project graphics and Agile information radiators as a straight line with a steady cadence, as shown in Figure 2.
Cost is also typically depicted as a steady line. But as we know from our own personal experience, this is a simplifying assumption. Expenditures are observed to be made in incremental steps, as shown in Figure 3.
For project planning and progress tracking purposes, however, cost is most often established in budgets and allocated to a project as a single number, Cost, whether as a defined-process budget, or as an Agile iteration funding pool, and therefore depicted as a straight line.
Likewise, value, or Scope is also most often mapped as a steady progression as indicated on the triangle. Similar to the Cost, however, it is readily recognized that progress on the scope of work is not typically steady, but more often observed and measured in an incremental “progressive elaboration” (PMBoK) as shown in Figure 4.
The Agile scope or ∑vN can therefore be considered a method of incremental but iterative “progressive elaboration” of value (Scope), as shown (figure 5),
But otherwise it can observed progressively and measured exactly as in defined-process projects.
In other words: Agile projects can be shown to exhibit the same fundamental factors of defined process projects. These fundamental factors are bound by a predictable rule. The rule of T+C=S, often called the “Iron Triangle” or “Triple Constraint”, has applied to all project efforts for dozens and arguably thousands of years.
Therefore, because we have shown this special relationship can be applied to Agile projects with the same rigor as applied in all defined-process projects, this can be called the general relativity of Agile to legacy PMBoK “defined-process” project principles.
”In every project Cost and Time are immutably linked by Scope” or (T+C=S)
“In every Agile project the sum of values in the iterations are constrained by the sum of the time-boxes and the size of the funding pool. ∑vN = ∑TB + $AGILE
Afterword: So What?
Well, this deduction simply says that it has been established that there is a relationship between a project’s time, cost, and scope. If this relationship is expressed as a triangle, then the relationship can be expressed in mathematical terms. We often hear this expressed as T+C=S.
It may be presumptious to make a comparison, but in at least one way this T+C=S approximation can be compared to the Theory of General Relativity when it is expressed as E=mc2. Although this relationship is most often verbalized as “E equals ‘em’ ‘see’ squared”, instead of being a rigorous mathematical equation, the expression is taken to mean simply that there is a predictable mathematical relationship through which a quantity of energy “E” is related to the multiplication product of some specific amount of mass and the square of the speed of light… or a similarly extraordinarily BIG number.
Likewise, the shorthand for the famous PMBoK Triple Constraint is verbalized as “T plus C equals S”. But it actually means “T plus C yields S” …because we know that although the Triple Constraint is being expressed mathematically, one cannot necessarily calculate time or cost or scope from the other two factors. Indeed, the three factors are typically expressed in different units of measure, and the whole equation would have go through a variety of transformations just to get all three factors into like quantities that could be equated. And even then, as a mathematically-inclined friend politely pointed out, there could be lots of T’s and C’s that yield a specific S. So the really useful aspect of the Iron Triangle principle of T+C> (“yields”) S is that there is a relationship. Which (thanks to a legendary gentlemen named Pythagoreus who proved that there is a known relationship of T2 + C2 = S2) is an immutable, inescapable relationship. Or, in other words, a predictable relationship. The “So What” is that the fact that there is such a relationship is used somewhere every minute of every day, when a project manager explains that when one factor changes, such as time or scope, you can confidently predict that there will absolutely be a corresponding change to one or both the other factors.
This article simply makes the argument that the same thing applies to Agile projects.
With all that that implies.
So what it implies is that one can measure Agile projects like defined-project projects. And one can predict that, just like waterfall projects or nuclear fission, changing one factor or another could result in a uncomfortably large explosion with a Sponsor. And by monitoring any two of the factors, we can reliably predict when that is going to happen. And maybe the size of the explosion.
With humble appreciation to:
the good humor of A.Einstein
About the Author:
Author: Steve VanArsdale, CSM, PMI-ACP
CA Clarity Agile Architect, VanArsdale & Associates
Affiliations: Agile Alliance, Scrum Alliance, ISACA, Project Management Institute
Mailing Address: 414 S. Can-Dota Avenue, Mount Prospect, Illinois 60056-3612
1 From Albert Einstein’s “Does The Inertia Of A Body Depend Upon Its Energy-Content” – ref: http://www.fourmilab.ch/etexts/einstein/E_mc2/e_mc2.pdf
2 Project Management Institute – “A Guide to the Project Management Body of Knowledge (PMBOK Guide)” Fifth Edition (2013) – ANSI/PMI 99-001-2008 – http://www.pmi.org/