Traditional project management has relied on the foundations of triple constraints to plan and control projects. It has always stood like a rock for projects to be planned and executed around it. With the advent of agile project management methodologies, what happens to the principle that once defined project management?

Cost, time and scope are the triple constraints of project management. They are represented as the sides of a triangle, indicating that the variance of any of the constraints will impact the other two. Quality is often considered as an outcome of the management of triple constraints, usually represented within the three sides of the triangle. And it is loosely considered as a fourth constraint as well. However, in this blog post, I will consider the original three constraints only.

Agility in Triple Constraints

Traditional or waterfall project management is accused of being rigid and slow to change directions. However, its rock, the triple constraints are truly agile and flexible. If one of the constraints was to change, the other two have no problem whatsoever to make up for the change. They either go up or down depending on the other constraints.

For example, if the scope was to increase, it would come at an additional cost and requires additional time. The triangle can also be adjusted to pump in more costs for meeting the additional scope without impacting the schedule. There are a few permutations and combinations that are possible with the use of triple constraints – some practical and most aren’t.

Exploration in Agile Projects

Often, we don’t talk about triple constraints in Agile project management. We thrive on a fluid scope and the time is often controlled in iterations – called sprints.

The cost of a project is often an outcome of the scope and schedule. It need not be actively managed as long as the other two constraints are well managed. The number of resources in a project come at a cost, and they represent the cost of a project (plus the usual indirect additions).

I will make a case for why we can probably put the triple constraints on the back burner for Agile projects.

Diving Deeper into Triple Constraints in Agile

As I mentioned earlier and one of the primary thumb rules of Agile project management is to never firm up the scope. The scope is a mega set of various epics and user stories that often gathers dust in a product backlog. During every sprint (often two or three weeks long), a fixed set of these user stories and epics are picked up and delivered.

The scope, therefore, exists as a superset but it really comes into play only during the respective sprints.

In Agile project management, we don’t like to tinker with the people who work on the software. We like to keep it stable with no chopping and changing. So, the cost constraint, represented as the resource constraint in the figure is more or less a constant.

The time constraint is fixed for an iteration and is generally believed that a project can run perennially as the changes to it are introduced in bits and on a regular basis. So, the time of a project (more so iteration) is more or less a constant.

The third and final constraint, the scope is what changes on a fairly regular basis. The sprint backlog represents the scope of the iteration and once it is locked in a sprint, it stays true to itself and remains constant.

To summarize what I have just stated, within an iteration, the triple constraints remain constant, without much variance between sprints. It represents the standardization of work items and predictability of delivery, which is a yearning that defines the health of a project.

When the focus of triple constraints is widened to an entire project consisting of multiple iterations, triple constraints give an interesting read. While the scope increases progressively, so does the time and the cost. The triangle retains its shape and the ratios and proportions that exist between them pretty much stay in an acceptable range. This represents the stability that Agile projects bring to the table by delivering software through iterations and keeping a firm control over the project costs, schedule and yet delivering the software where the scope keeps singing a different tune on a fairly regular basis.

The Case for Triple Constraints’ Irrelevance

The consistency that’s shown in Agile projects where scope, time and cost remain constant and in proportion for a significant portion of projects. It makes a boring read for an analytics major because probably there isn’t anything much to read into the straight lines.

This consistency between the three constraints makes the tracking of triple constraints irrelevant. So, although in essence, triple constraints are very much inherent to projects, be it Waterfall or Agile projects, they are usually never tracked and compared in Agile project management because they remain in balance for the most part. In Agile, the parameters that really matter are velocity and rework among others. Tracking them and its associated trends make more sense as they represent the real health of a project.