Fixing Scope in Agile Projects

Rate this post

Many software development projects need to have costs, delivery dates and scope (delivered functionality) defined at the start of the project. Agile and Scrum take a different approach, by delivering working software in iterations, where costs, time and scope are “fixed” per iteration instead of the whole project. But what if you manage an Agile project, and your project sponsor still wants you to commit to a delivery date, budget, and a fixed scope?

At the start of a project, project managers wants to reach agreement with the sponsor about costs, time and scope, and commit to meet them. For years, many projects fail to meet these commitments. They don’t meet the delivery deadline, spend more money, or both. If they manage to stay within budget and meet the delivery date, then either they don’t deliver the full scope, or the quality of the product suffers. My opinion is that fixing costs, time and scope is simply not possible. If you manage a software development project, then pick 1 or 2. Either fix the time and/or costs and try to maximize the scope, or fix the scope and try to minimalize costs and time. Fixing everything is an illusion!

Solutions for “Fixed Scope” in Agile

But what if the project sponsor insists on a “fixed” contract? You can still use Agile techniques to determine the scope for a project. Possible solutions are:

  • Agree upon the high level requirements, make agreements with the sponsor about when and how to detail the requirements. Usually it is ok to postpone detailing requirements until needed for a next sprint. Given that the sponsor, customer(s) and the project team will have a better understanding of the requirements by that time, the quality of the requirements will also be better.
  • Use the Agile backlog to estimate what the scope most probably will be at the delivery date, and commit to deliver this functionality. Offer to the project sponsor to discuss and change the priorities when needed.
  • Agree upon the possibility to end the contract after each iteration, when there is enough scope available to deliver, or insufficient value expected to continue the project.
  • Agree that the project only commits time, costs and scope for each iteration, and make sure that the project meets this commitment. This is way to build up trust with your project sponsor.
  • Prioritize the project content, based upon customer value, and use a business case to decide which functionality should be included in the project. Commit to the project sponsor only for the scope that has a sufficient business case.
  • Use an alternative estimation method next to agile, like function points or Cocomo, to estimate how much scope will most likely fit into the agreed upon schedule and budget.
These are some solutions to deal with a project sponsor that wants to fix time, costs and scope. Do you recognize them, have you used them? Do you have other solutions to deal with this? I’m looking forward to discuss this with you, feel free to comment on this article!

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 3 Comments

  1. Matt Verhaegh

    Mooi overzichtelijk artikel!
    Thanks, Matt Verhaegh

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.