Aug 102009

If agile methods are to achieve the position of strategic organizational capability rather than tactical engineering capability, then one of the key factors in achieving that position is changing the way we measure success. Many agile teams are now caught in a dilemma. On one hand they are told to be agile, flexible, and adaptable, but on the other they are told to conform to pre-planned traditional Iron Triangle framework of scope, schedule, and cost. In essence they are being told “be flexible in a very small box.” Agile teams are striving to meet one set of goals and managers and executives are measuring against another set.

Measuring success it tricky. Motorola’s ill-fated, multibillion-dollar satellite-based Iridium project was a spectacular failure in the market. Meanwhile, the movie Titanic, which was severely over budget and schedule–and viewed by early pundits as a $200 million flop awaiting release–was the first movie to generate over $1 billion in worldwide revenue. By common constraint-based project management measures of success–scope, cost, and schedule–Titanic was a failure and Iridium was a success. Maybe organizations are using the wrong measuring stick.

My proposal for a new measurement framework is the Agile Triangle: Value, Quality, and Constraints. The measures are value, to the customer in terms of a current releasable product; quality (to deliver continuous value to the customer, in terms of a reliable, adaptable product); and constraints (the traditional scope, schedule, and cost). Constraints are still important project parameters, but they are not the project’s goal. Value and Quality are the goals and constraints may need to be adjusted as the project moves forward to increase customer value. Schedule might still be a fixed constraint, but then scope could be adjusted to deliver the highest value within the schedule constraint.

The focus of value on a “releasable product” is important. Every iteration we what to ask, “Does the product have enough capability to release today?” We want to focus on this strategic value question, not on whether every detailed requirement (scope) has been implemented. By focusing on detail requirements we lose strategic focus. By focusing on a releasable product, we focus on gaining the most value for the least cost.

Admittedly it is harder to measure value and quality than it is to measure cost and schedule. However, it’s much better to have fuzzy measures of really important things that precise measures of less important things.

For more details on the Agile Triangle, see my Agile Project Management, 2nd Edition, or attend my Agile 2009 conference session, “Zen and the Art of Software Quality.”


Jim Highsmith

Jim Highsmith was the founding director of Cutter Consortium’s Agile Product & Project Management practice.


  22 Responses to “Beyond Scope, Schedule, and Cost: Measuring Agile Performance”

  1. Great points, but can you point us to a “fuzzy measure” of value? And one that can be estimated a priori?

    Is there a method for estimating value? Jim York (agile consultant) advocates the IRACIS model – increased revenue, avoided cost, improve service. But, even “-IS” is unitless, and one can imagine other “values” where it is very hard to translate (without many assumptions) into IRACIS, such as, increased market share, defend reputation, etc..

  2. avatar

    Calculating overall value (such as ROI) I’ll leave to others like Bob Benson. However, in the new edition of my APM book I advocate allocation of value points to individual features such that a team understands the “relative value” of features to help with priority decisions. These allocated value points can be turned into monetary value points if the ROI calculation has been done for the project overall.

    So overall project value (ROI) impacts portfolio management, while feature value (which can be relative) impacts release and iteration planning.

  3. These allocated value points can be turned into monetary value points if the ROI calculation has been done for the project overall.

  4. avatar

    Yes they can.

  5. I have one tool for calculation value here:

    Jim talks about getting a team focused on delivering results in his APM book. I’ve found the use of dollar values for each feature an extremely effective tool for doing this.

  6. I have one method of value calculation here:

    Jim talks about getting a team focused on delivering results in his APM book. I’ve found the use of dollar values for each feature an extremely effective tool for doing this.

  7. A rethink is required in 4 dimensions:
    – Project Funding
    – Method of Interaction
    – Definition of Defect
    – Measure of Success

  8. avatar

    In our enterprise, the most significant impediment to value-based prioritization is the massive inventory of expectations that the annual/strategic feature-based planning creates. In lean terms, these processes create WIP that often dates as far back as 18-24 months. Making even small changes to this inventory, based on market conditions or customer feedback, is extraordinarily difficult, requiring countless meetings to explain the deltas. It seems that IT has indeed forced business into feature-based planning by failing so consistently to engage and deliver alongside the business, does anyone have any creative/successful tips on how to begin to shrink this inventory?

  9. Your examples on project success (motorola’s iridium project, the titanic) echo very well with an article I published a while ago: Differentiating between Project Success and Project Management Success.

    Both the iridium and the titanic projects are mentioned, in addition to the Concorde project.

  10. If you’d like to continue this discussion live on Thursday, Sept. 10, register for Jim’s webinar, Measuring Agile Performance: Beyond Scope, Schedule and Cost — . Jim will delve into the details of the Agile Triangle and then open the webinar up for questions and comments.

  11. avatar

    To Jim Miller’s comment: Don’t know if your customer community has a product manager, but that role, even in an internal IT environment seems essential to keeping the backlog reasonable and managing change.

  12. I like the simplicity of your proposal for the “Agile Triangle: Value, Quality, and Constraints” and agree that to many companies, shipping a product us the Value point.

    It is possible to define and measure value and use it to help manage an agile project. See my article on “Measurable Value with Agile” for details on how to –

    I’m glad you are speaking out on the lack of value focus in many agile teams (and especially non-agile ones). We need to better educate management to focus on the benefits and value, not just the cost and schedule. It is easy for even agile teams to lose sight of the true goals of a project, and management to fail to clearly define what they mean.


  13. […] a recent article of Jim Highsmith’s discussing an Agile alternative to the Iron Triangle ( The first four sliders showed Scope, Cost, Time and Quality and the slider indicated how fixed or […]

  14. […] the Agile Triangle depicted in Figure 2,  presents in a single ”dashboard” the three dimensions […]

  15. […] several times in the last few years. There’s Jurgen Appelo’s Iron Square, Jim Highsmith’s Agile Triangle, Max Pool’s Iron Line, and any number of other variations. At first glance, these seem like good […]

  16. […] in Agile Project Management: Creating Innovative Products. See the Cutter Blog post entitled Beyond Scope, Schedule and Cost: Measuring Agile Performance for a short summary of the distinction between the two. Possibly related posts: (automatically […]

  17. […] debt does not guarantee that the customer will find the code valuable. I would suggest reading Beyond Scope, Schedule and Cost: Measuring Agile Performance in the Cutter Blog for a more detailed analysis of the distinction between the two. Possibly […]

  18. The traditional Iron Triangle from project management almost always has “Quality” in the middle (at least implicitly), with the default setting of “High” – since what customer would desire less? One could argue it should really be an Square, whose dimensions (Scope, Time, Cost, Quality) trade off against each other. Although this can be difficult for some to visualize in our 3D world.

    The subtle difference explicitly introduced here is the disambiguation of the definition of “Quality”, intrinsic vs. extrinsic, the latter being defined as Value. Value is the domain of Product Management, and can easily be overlooked in the complexity and rush of managing any project of real significance. A product can be of high (intrinsic) Quality, but of zero Value to the customer. I.e., somewhere along the line, a disconnect occurred between what the market wants in the product and what the project actually produced (is producing).

    In an agile world, Value can change rapidly base on how the existing product output addresses the current and fluctuating customer needs. Customer Value is really why we are doing anything at all. It makes sense to manage agile projects with Value as a key driver.

    So perhaps we need an Iron Square with Value in the middle to signify its ultimate importance of having a default setting of “High”. But then that would really be a Pentagon. 😉

    Or maybe an Iron Hexagon to include the dimension of Customer Satisfaction, since it is possible to produce a high-Quality high-Value product for the market, but still have unsatisfied customers.

    Or maybe an Iron Nonagon to separate *kinds* of Value found in product management (Buying, Using, Visionary, Competitive)…

    So the “Agile Triangle” described above is really not as different as the author seems to be implying (although I admit I have not read the book mentioned). Using Business Intelligence terminology, we would say that he has merely re-sliced and pivoted the hypercube (OLAP). But really, if more Value is added to the understanding of project management, is that a bad thing? 🙂

    To provide the “right” product to meet the market/customer expectations, ideally there will be full and timely traceability from front to back. I think it really depends on how much of the *product* management dimensions you feel need to be explicitly tracked/controlled in the *project* management processes used in product realization.

    Adding a Value dimension to the traditional Iron Triangle is definitely a great place to start… and perhaps a great place to stop as well!

  19. […] Jim Highsmith, Michael Mah and I have been thinking about and contributing to for sometime now (see Beyond Scope, Schedule and Cost: Measuring Agile Performance and Quantifying the Start Afresh Option). The heart of both the technical debt service and the […]

  20. […] a comment » The Agile Triangles was introduced by Jim Highsmith as an antidote to the Iron Triangle. Instead of balancing […]

  21. Quick Link: The DevOps Triangle…

    Quick aside: Normally I dislike getting this semantically picky, but frankly I find the term “DevOps” almost an entirely semantic concept in the first place, so it seems like it might be important to get it right: has anyone else noticed that lately,…

  22. avatar

    Maybe instead of “fuzzy” measures, we could use “accurate” measures?


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>