Considering that we work on a project with fixed deadlines and fixed budget and we use Scrum: what are best practices we should use to make this setup successful? Since Scrum wasn't directly designed to deal with such projects, what changes we should apply to standard by-the-book approach?

8 Answers 8


Scrum works best when there are known quantities because you can easily compare expected's to actual's. With the scope and deadline already determined, you can basically list out all the features, break them up into 2-week iterations, then as you move forward, you'll be able to gauge whether you're scheduled to complete the project before the deadline.

For the folks signing the checks, this can be a HUGE benefit because they will be able to see progress every step of the way, and be able to make immediate adjustments as necessary to get the project done within those constraints. If the project is falling behind, they'll be able to see that almost immediately, and determine if they need to allocate more resources, cut features, or scrap the project altogether (hopefully before they've lost 100% of their investment).

I am currently working on a project with similar constraints, and the business loves the Scrum model because although the requirements for the product we are building haven't changed much since Day 1, they are still involved at every step, and they feel confident that what we are building will meet their needs.

The key is really just to keep them involved, and show them how their money is being spent. Then, if the project does end up a bit over-budget or over-time, they will feel more comfortable making adjustments, instead of writing a blank check for an unknown delivery.


A good approach to managing this is suggested in Steve Tockey's Return on Software - You should initially prioritize all the stories that are envisioned before the start of the first sprint. Now for each story come up with its best and worst (story point) estimate. Also have some estimate of the velocity - either use judgement (team based - you could use planning poker for this too :) or use past data - but be realistic. That should give you an initial guess as to how many story points can you deliver (PSPD = planned story points deliverable)

Starting from the most important story, in that order:

Take the sum total of all the 'worst' estimates - once that exceeds PSPD, Stop. (Remove the last story so that you are below PSPD. You need not but may). These set of stories are definitely "in" (= DIN i.e., will be developed).

Do the same for the 'best' estimates. Once you exceed PSPD, Stop. The stories left out (i.e., not considered by this step) are definitely "out" (= DOUT).

So the set {Best - Worst} (i.e., the stories that only belong to best, but not to worst. It's the minus set operator) are the ones whose 'fate is uncertain' for now. All you can say is that few of the highest priority features will be delivered and few of the low priority ones won't be. The rest is contingent upon (business/technical) knowledge gained at the end of each milestone. Re-estimation at subsequent milestones would then repeat the above process but on the Uncertain set = {Best - Worst} to know the new DINs and DOUTs (and of course the new uncertain set)

This should allow the management to see a realistic plan of action as well as gauge the level of uncertainty at every milestone (i.e, end of sprint) and see what is DIN/DOUT/Uncertain and decide accordingly!

This is by a book approach :) Hope this helps


You'll probably have to juggle the fixed scope part of your project (since fixed budget is usually just means a fixed team and fixed delivery date means when this team stops working).

It depends mostly on how much consensus you can get from stakeholders, product owner etc. Usually this boils down to making compromises on functionality (again thinking about how defined is the scope and how important are the stories you can't afford to deliver for any reason or maybe the justification for replacing these stories for different ones).

I would suggest paying more attention to your product backlog, and making the fixed scope part of the project a bit flexible in the sense that you want to leave out as much technical details as possible for interpretation and better implementation later.


There are multiple solutions possible depending on the type of uncertainty and the type of project. As always, there is no single correct solution. Look at the various options and see what fits into your context:

  1. In some projects, there is uncertainty, but it is well understood. For example, website design, has some back & forth before you finalise on the output, but this is well understood. Usually you know how much time will be spent in revisions and you can buffer that time & cost into the fixed price when you make a quote.
  2. In some projects, you dont understand where there will be uncertainty. In this scenario, you need to prioritise your work, delivering the higher value stories first. When you get feedback or changes for the higher value features, create new stories for those changes and remove an equal amount of lowest value stories from the bottom of the backlog. Basically, you are trading one story which is more valuable for another story which is less valuable
  3. In new innovation work, where there is going to be a lot of uncertainty, then negotiate for the time & material contract. It is in your own customers interest to do time & material as it is likely that a lot of changes will be required before you end up with the right software that your customer actually wants. If you do fixed price, the delivered software will mostly not meet customers needs.

The various contexts where these can be used:

  1. First is the fixed-price fixed-scope scenario. Choose this for commodity software which you have delivered many times before and you understand well. Not only about the product you are building, but also which are the likely areas of uncertainty and duration to resolve them.
  2. Second is the fixed-price variable-scope scenario. Choose this for reasonably well understood software where you understand the product you are building, but dont know the time it will take to resolve uncertainty.
  3. Third is the variable-price variable-scope scenario. Choose this when you are doing something new, and expect a lot of uncertainty in the product direction

I find that scrum is usually part of an agile approach and as pkoval implies, having a fixed date is not very scrum-like. I would start with bare-bones functionality that you can do in HALF the time. Deliver that and then start delivering features one-by-one.

I would work on additional education of senior management if necessary about all the pieces of scrum and agile.

Scrum and it's implications have to be well understood by all, not just 'applied' on top of an existing system to try and push 'faster' results.

  • 3
    Fixed date is fine, you just have to manage the other two points of the triangle, and since budget is fixed, all you can play with is scope. So you deliver the most important stories that provide the most business value to the customer.
    – CaffGeek
    Commented Nov 29, 2011 at 21:09

I believe DSDM Atern, which is another agile methodology, explicitly deals with fixed time and fixed budgets.

By prioritising the requirements using the MoSCoW method, it is understood that some things will not make it into the final release. It is up to the Business Visionary to identify which requirements are flexible in this manner. Although there is a ratio that is advised, else everything becomes a Must Have.


You should watch the video "Agile Fixed Price Projects" that discusses this exact topic

  • "Using Scrum in fixed price, fixed date situations presents an opportunity, but only if your audience knows how to listen and is willing to listen" - Agile Project Management with Scrum. Ken Schwaber. There is a piece where he details how to approach such a situation, concluding with the above statement.
    – Laura
    Commented Dec 5, 2011 at 17:08
  • The video is not available anymore. Commented Aug 23, 2014 at 4:47
  • No video available
    – Andy L
    Commented Aug 8, 2017 at 14:56

I'm a Scrum newbie and looking to implement Scrum in my company. Obtaining buy-in is not a problem, it is my company and the developers are more than happy to work like this.

The problem is that 75% of our revenue is derived from fixed length/fixed price projects.

Ken Schwaber in his book, Agile Project Management with Scrum, covers the topic of bidding on fixed length/fixed price projects in an appendix at the end of the book.And u explained beautifully.Hats off

Here is a Plug to my website http://www.scrumstudy.com

  • 2
    Could you summarize Mr. Schwaber's key points & value? And please clarify how your website answers the question?
    – MCW
    Commented Jan 27, 2014 at 11:06
  • Hi peeter, welcome to PM.SE! Is important to make sure your answer actually answers the original question, otherwise it only look like a proper promotion of your website (which is not advised unless really in scope for the original question). Not revising the answer will make it get eventually deleted.
    – Tiago Cardoso
    Commented Aug 19, 2015 at 21:43

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