The Golden Triangle in Scrum – Scope vs Time vs Cost Trade-off

Anyone who has had any formal project management training would be familiar with the golden triangle concept. In one of my articles on the PMP Exam prep series we had reviewed the topic of controlling the project Scope, Cost and Schedule. Click here

A project usually has competing demands from these 3 aspects - Scope, Time and Cost. When there is change in one aspect the other two sides of the triangle need to adjust in order to keep the project under control. But, that’s for a traditional waterfall type project. Do we have a Golden Triangle for Scrum? That is the question we are trying to answer in this article.

Does Scrum Also have the Golden Triangle?

All projects Agile or Waterfall or whatever be the methodology they follow, will have competing demands from these 3 aspects – Scope, Time and Cost.

Let me ask you a question: If you have 5 members in your team and have a 3 month schedule, do you think I can keep adding more and more scope items to the backlog and you will still finish on time?

You may think of an answer like, I can if I add 2 extra developers or if I get 1 month extra time but you already answered my question – No, you cannot. If you fix the team size and the schedule, the amount of software features the team can produce is limited (assuming you don’t make your team work 16 hour days)

Get the picture? But, I haven’t explicitly answered the question, have I?

Does Scrum also have the Golden Triangle – Explicitly No.

Surprised?

In Scrum the Product Backlog is not a fixed entity like waterfall. The scrum team makes a best effort attempt at building as many features of the product (in priority order of course) but there is no commitment that the team will build all of the features in the backlog. We have a dedicated Product Owner who takes the responsibility of adjusting the product scope based on priority and the teams velocity. Hence we don’t have a Golden Triangle in Scrum. We only have a Time vs Cost Trade-off in Scrum because scope is always variable.

The Time vs Cost Trade Off (With Scope Being the Evolving Constant)

The easiest way to reduce a project duration is by adding more people – this has been the motto of managers since project management became a profession (this is also the reason why software developers hate project managers)

Anyways, in most organizations, every product has  a roadmap of features and also has timelines to hit the market with those set of features. So, Time aspect of development is almost always fixed and does not change unless something drastic happens. When time cannot change (and scope is evolving), cost has to change to adapt to the situation – there is no other choice. We add more people to the project in order to meet the projects’ needs.

For example, suppose a project would take 1 year for 1 person to finish, adding an extra person could probably result in an overall schedule of around 7 months. Adding another person may bring the schedule to around 4-5 months and adding more people may further shorten the schedule but not exactly by a mathematical factor because we also have to take into account overheads on communication and coordination between the different parties involved. Anyways, adding more people means the project becomes more costlier and this where the trade-off between schedule and cost comes into picture.

In real life, Senior Managements across all businesses & organizations push for lowering of cost or expenses. So, it may not be practically feasible to have an endless budget. But, having said that, a company that wants to bring a product to market cannot be solely focused on the cost of building it because, releasing the product with maximum features and within committed timelines is much more important that saving cost. If you are wondering why, think of this – Todays market is highly competitive and a few weeks delay could be the difference between a product being a success or a failure. If our competitor releases a similar product a few weeks ahead of us wouldn’t clients choose their product over ours?

This is why, experienced scrum masters will try to get the various different stakeholders in the scrum project like Architects, UI Designers and so on to work seamlessly together to keep the delays due to overhead as minimal as possible and keep the schedule as short as possible. Even in organizations where cost is not really an issue, scrum masters still try to optimize the team size and not depend on endless hiring just to meet the competing schedule or scope demands.

What is your experience with regards to handling competing scope or schedule needs in your agile projects? Sound off in the comments section…