When defining the constraints of a project, the classical Iron Triangle defines three concurrent constraints: Resources, Scope and Time. Some more complex models (see the Project Constraint Model) add Quality to the above list.

I understand that view in a classical waterfall view, where quality is a separate process. It makes perfect sense at some level when QA team is some independent entity. The QA team spend time to test product, count defects or missing features and ask for product changes to development team.

But I wonder if it is meaningful to see Quality as an adjustment variable inside an Agile team. As I understand it, Quality should be on par with Velocity. Some structural property of a team that you can measure and try to improve but never really control.

In the past I've seen managers trying to use it as a lever and that lead to unpredictable results. In some cases trying to lower Quality lead to higher Costs, Resources and Development times (defects were caught later in the process, and that has a well known cost). I've also seen exactly the opposite: well meaning teams trying to get higher Quality which translated to heavier processes (more code reviews for instance, or more tests written), and more complex definitions of done... but without any observable positive relationship with customer value reached in the end.

In the end I believe Quality is not a true adjustment variable of Agile process inside of a team, as you can neither control it nor measure it, but merely something like Velocity that can be used for it's predictive power (how many bugs will there be in the final product?) but not really use as an adjustment variable.

Is Quality a legitimate constraint in Agile teams? How should it be measured? Can it be used as an adjustment variable and how?

  • 1
    I wonder of the intent of the question downvoter ? Would he enlighten me ? Does it means such questions should not be asked ? I understand people may disagree with what I see and that's why I ask this. If they disagree I expect them to explain how they use quality (inside an Agile team, not from a separate QA team) as an adjustement variable.
    – kriss
    Commented May 6, 2014 at 22:31

2 Answers 2



Quality is a widely-recognized project management constraint. To the extent that one can modify the quality controls applied to a project, one can impact the quality of the deliverables. In addition, by adjusting quality, one can impact other constraints that affect (or are affected by) the quality control process such as schedule or budget.

Agile processes should have explicitly defined quality controls. A well-defined control is measurable, even if the measurement is simply pass/fail, so agile frameworks certainly support the ability to measure "quality" as defined within the project.

Quality Defined by "Definition of Done"

By definition, "quality" is a qualitative assessment. From a purely pragmatic point of view, it means that quality controls are what you should measure against.

Within an agile framework like Scrum, quality should be defined by the Definition of Done. The organization or the team generally defines "quality" in terms of fitness for purpose, and the Definition of Done should therefore describe the steps necessary to certify a potentially-shippable increment as fit for that purpose.

Constraints and Sliders

Within project management, constraints and sliders are generally used to focus a project and to define the trade-offs inherent in a system. The Iron Triangle is an example of such a constrained system, and the paradigm posits that the third side of such a triangle is determined by the other two sides. If your sides are Scope, Schedule, and Cost, then:

  • You can control Cost by modifying Schedule and Scope.
  • You can affect Schedule by modifying Scope and Cost.
  • You can impact Scope by modifying Schedule and Cost.

While a useful concept, the theory of constraints doesn't limit you to exactly three sides, nor does the paradigm insist that the constraints be the same across all projects. In fact, the Project Management Book of Knowledge currently advocates a model with six constraints:

  • Scope
  • Quality
  • Schedule
  • Budget
  • Resources
  • Risk

Perhaps a more agile alternative is Mike Cohn's Project Success Sliders, which provides a less-geometrical way to visualize the trade-offs inherent in the theory of constraints. Among other reasons, I personally recommend this approach over the more traditional triple-constraint precisely because it sidesteps definitional arguments about the commonly-accepted constraints.

Measuring Quality

Quality within an agile process is both measurable and adjustable, and fitness for purpose is tightly bound up with a project's scope. One measures quality against the Definition of Done, and by the metrics associated with any process controls created to meet that definition. For example, a partial Definition of Done for a software project may state that:

  • Unit tests shall provide at least 60% code coverage.
  • Each feature shall be accompanied by measurable acceptance tests.
  • All integration and acceptance tests shall be 100% green at the end of each iteration.
  • A build must run without error on a continuous integration server before being added to the iteration's release.

Each of these quality controls can be measured and adjusted to suit the needs of the project. For example:

  • Code coverage requirements could be increased to improve long-term maintainability at the expense of higher labor or infrastructure costs.
  • The requirement for continuous integration could be sacrificed for speed or budget reasons.

By modifying the quality controls within the process, one can therefore impact other constraints. In addition, by feeding the results of the quality controls into the inspect-and-adapt cycle, the organization gains the ability to gauge the quality of the product and the sustainability of the project itself.

  • at least an actual answer. More or less what I did in the past. I still have one trouble with this way of controling Quality, Changing this cursor practically means adding or removing additional processes (steps before things are Done). But it's not obvious it capture any customer value, not that it will actually result in code easier for maintenance, etc. On the other hand a too permissive DoD it obviously not a good thing. It probably means that cursor is not linear and it can only be changed between narrow limits (and existance of limits is also true for other constraints).
    – kriss
    Commented May 7, 2014 at 6:55
  • @kriss You're correct: constraints and sliders within a system are not free-form. They impact each other, and may require re-balancing the project when any given constraint is changed.
    – Todd A. Jacobs
    Commented May 7, 2014 at 14:14

Quality has to be a constraint, whether or not it is measurable by itself or is so intrinsic to scope is another question.

I disagree with your assertion that you can't control quality and that it cannot be measured. The key is that you have to define what you mean by "quality" up front, in other words how well does a piece of functionality have to work in order to be acceptable to the client. That will not only inform your assignment of story points to a deliverable, but will also give you some level of predictability in terms of effects if taking shortcuts.

The challenge is to get the client to define quality objectively. The easy ones are quality measures like "No more than X defects reported in Y transactions during UAT" or "Processing time of less than Z seconds", these can be measured and can give you the opportunity to use them as adjustment variables. But you will also need to consider inherently more subjective metrics like how intuitive the UI is or how pretty the formatting of output is, though if you can turn them into a yes/no type metric you could possibly use those as adjustment variables.

  • I'm not sure we are speaking of the same kind of "Quality". Your "Processing Time" example is clearly a feature constraint (common enough in real time software). And the other one is what I described as "external quality", and I completely agree that it can be both measured and controlled. It translates well to time et such "bug fixes" can easily enough be treated as feature inside the Agile team.
    – kriss
    Commented May 6, 2014 at 22:21
  • The trouble is that it does not give any hint on how to adjust Quality inside the team. Giving more time, more ressources or changing the scope all have a simple enough meaning. I see no simple translation for "giving more quality". More code coverage ? Better automated metrics ? More peer reviews ? More pair programming ? More code smell assessment and refctoring ? None will guarantee better quality and worse some of the above methods are contradictory. For instance more code review usually means less refactoring, because of the weight of the process.
    – kriss
    Commented May 6, 2014 at 22:25
  • @kriss - I think your focus is too much on process when thinking about your metrics and not enough on results. What matters is customer acceptance of the functionality developed in a sprint. Your client won't care how many peer reviews you did, they will only care if the sprint (a) delivers the desired functionality to (b) what they consider to be acceptable quality standards. Get them to define those standards up front and you should be well on your way to controlling quality and managing it in your sprint.
    – Doug B
    Commented May 7, 2014 at 12:39
  • what actually happen is that I manage a dev team in a project setting where we have another dev team working on another part of the product (each team provide an API to the other) and an independant QA team. Interaction between teams say between my team and QA team is tenfold the time of interaction inside team. Henceforth it's important to minimize defects in product delivered to QA team, or there will be time to market issues. The only parameters I actually control regarding quality is my team processes (or DoD), customer acceptance is just too far away.
    – kriss
    Commented May 7, 2014 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.