Some projects we run internally using are Scrum, while still being "fixed everything" to the customer. We're experiencing mixed success on our part (the customer likes the visibility of the burndown chart). Can the types of projects we work be successfully executed using the agile methods?

  • 18
    Can fixed scope + fixed deadline + fixed price contract ever be made to work? Commented Apr 9, 2011 at 22:21
  • 4
    Isn't this a way to rephrase: "Fast, Good or Cheap. Pick Two" ? Commented May 13, 2011 at 17:28
  • 3
    Isn't fixed an antonym of agile?
    – Matt Ellen
    Commented Jun 29, 2011 at 9:55

6 Answers 6


Well, I've worked mostly in "agile" environments (although we don't use the lingo), and I've done fixed cost things. Generally what it amounts to is cost-plus, since no company can afford to do everything for free, and requirements do change and evolve as the customer figures out more clearly what they want.

The initial requirements for the fixed cost portion have to be done much more carefully than they are done in a typical iterative environment, making the process somewhat less iterative. The "plus" part of the contract can be more iterative, provided we have fulfilled the fixed cost portion more or less satisfactorily to the customer.


I would like to pose a counter-question:

Can fixed scope + fixed deadline + fixed price contract ever be made to work, period?

The "good/fast/cheap - pick two" saying isn't just some silly engineering joke. Every project manager worth his salt knows about the Project Management Triangle:

Project Management Triangle

You're telling us that the cost, scope, and schedule are all fixed. That leaves no room for maneuverability or error. None. You could choose to view "Quality" as an attribute, but it's not a "real" attribute, it's more like a meta-attribute that's derived from the other attributes (cost/scope/schedule).

The problem is that this never happens in reality as long as your project is being planned and executed by humans.

  • Requirements and specifications never cover every edge case unless they've been drawn up in immense detail by qualified architects and designers, in which case the project is already half-done; and even then there's still the possibility of error.

  • Unexpected costs will pop up leading to budget overruns. A subscription expired. A manufacturer discontinued their support for a product you're using and you have to find a new one. An hourly contractor raised his rate under threat of departure. Your entire team just went on strike, demanding a 10% raise and an extra week of vacation.

  • Schedules slip. Unforeseeable problems crop up; that charting component you've been using for 5 straight years isn't compatible with Windows 95, which your client is still using. An obscure bug in 64-bit Windows causes serious UI glitches and you spend nearly a week tracking it down and developing a workaround (this actually happened to me). Your senior developer got hit by a bus and you have to go recruit and train a new one. Your estimated delivery date is always wrong. Always.

    See Hofstadter's Law:

    Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Agile methods are all about juggling around the cost, schedule, and scope. Most of the time, they're specifically about juggling around the scope and sometimes the schedule, which is why you start with nebulous user stories and plan revisions instead of full versions. Different methodologies use different terminology but it's all the same basic premise: Frequent releases and a rebalancing of the schedule and scope with each release.

This makes no sense with a project that is (or claims to be) either fixed scope or fixed schedule.

If one project attribute (cost/scope/schedule) were fixed, I would tell you that it might not be a good fit for agile methodologies.

If two project attributes are fixed, then your project is definitely not a good fit for agile methodologies.

If all three attributes are fixed, then your project is probably going to fail. If it actually ships, then either the original schedule was massively fudged, or the client has managed to delude itself into thinking that you actually delivered what was promised.

If this contract is still on the table, I urge you to reject it. And if you've already accepted it, may God have mercy on your soul.

  • 4
    +1 for Hofstadters law. I'm going to quote it at the next estimating session. Commented Sep 21, 2010 at 20:56
  • 2
    Note that if "fixed" doesn't really mean fixed (as implied in the comment to Todd's answer) then that changes the landscape somewhat, and the success of the project will partially depend on getting everyone to agree on the actual definition of the word "fixed" (or "must" or "required" or whatever the specific verbiage in the contract is). If the scope is really "fixed if we have time", then it starts to look a lot more like an agile project. :)
    – Aaronaught
    Commented Sep 21, 2010 at 21:03
  • 2
    I suspect that that's how the management have worked it with the client. Commented Sep 22, 2010 at 11:23
  • 3
    Fixed schedule / scope / price projects can work (I've done them), they just require really solid requirements, really good estimating and as you say these things are very hard in reality. +1 for a clear explanation of how Agile is basically contradictory to the whole fixed price mechanism though as one is all about (smart) trade-offs and the other precludes the possibility of trading off anything. Commented Nov 30, 2010 at 15:22
  • 3
    Just the amount of upvote on this answer shows how many are toiling away in Agile + Fixed price mess. Commented Nov 24, 2013 at 6:18

I love this quotation:

“Scrum is great for either fixed-date variable-scope, or "fixed-scope" (which always grows) variable-date. If you're doing fixed-date fixed-scope, I recommend waterfall or RUP, which will buy you a few months to look for a new job.” ~Michael James


Sure, as long as your quality bar is kept remarkably low. I'm a believer in the old iron triangle of "delivery time / quality / price" where you can pick two, but then the other one floats. It sounds like you've fixed the delivery time and price (and also the features) so really the only thing that can give is the quality.

That said, if you're using a burndown chart and you have the highest priority items being done first it might be acceptable to have a handful of the most important items done in the specified time-frame for the specified monetary amount. At the very least your client will see that you are controlling the process somewhat, with a deliverable at the end of each iteration and they have the ability to say what's most important.

Otherwise I think that committing to a fixed time, feature set and price is foolhardy and will lead to heroic efforts resulting in lower quality and less maintainable code. Agile is not magic fairy dust.

  • 2
    That's pretty much how we've handled it with our customer - let the scope slip and add it in the next version. Their prime motivators are deadline and price. We don't like to let quality slip - as this and the other comments note, we're fully aware the triangle - the business side has the fun job of making the customer aware of this too. Commented Sep 21, 2010 at 20:55

Fixed price / fixed deadline / fixed scope can be done at least as well agile as it can be in waterfall.

In waterfall, time estimations are inaccurate, and details end up being implemented differently than the original specifications. In other words, the deadline/scope can't be known exactly in advance.

In agile, you can do sprint zero to generate a backlog of user stories, and make some estimations. Then agree to meet the value stories for a fixed price, by a fixed deadline. The scope is fixed in terms of the value stories that you intend to fulfill, and no promises are made about user stories.

In other words, you promise to deliver what matters, and avoid making promises about specific design decisions that are unrelated to the revenue/savings/etc. that the project is supposed to deliver.

  • Old, but... it could be done infinitely better in Agile than it is in Waterfall, and the odds would not change. Zero is always going to be zero. If a single task on a single story encounters a single event that changes the cost or effort, you have failed.
    – EKW
    Commented Jul 4, 2016 at 19:30

I agree with Bruce to a certain degree. Though I am not too familiar with waterfall or RUP, and thus cannot comment on that.

What I read recently, and I thought was really well said, was that even in Agile we neglect planning. A thorough planning session once an iteration is great - no it's essential - but so is planning THROUGHOUT the iteration.

I work in the entertainment industry, where things are constantly changing. The team needs some degree of leniency / flexibility which will allow them to "re-plan" stories mid sprint in order to align with new goals or revised goals.

I love the idea of continuous planning, as too often developers will tell the product owner to go away when they're working on stories mid-sprint. This is excellent if your team works on stories which are still valid, and your product owner is just being a nuisance. But in some instances stories become redundant DURING the sprint, and it is imperative for the product owner to spot this, and for the team to re-align with changed goals / stories - isn't that what agile is about?

  • 2
    if you're doing constant planning, then Scrum really isn't for you. Kanban might be a more appropriate one to try. But what you say about Agile being about is spot on.
    – gbjbaanb
    Commented Aug 3, 2011 at 13:20

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