Let's say we want to get a contract. A customer describes what he wants and asks us for when we provide them a completed product.

We are going to use Scrum. How do we calculate the amount of time we need to complete the work?

5 Answers 5


Scrum isn't used to tell you when something will be delivered. That's not its purpose.

Scrum is used as a framework to develop software transparently that will provide immediate value to its users and customers. It mandates a self-organized, cross-functional team that decides what it works on and when.

This is at cross-purposes with your requirement to deliver pre-specified software by a specific date.

It does not sound like scrum will be the best process to use for your contract; as it is not meant develop software to deliver a complete system by a specific date.

I would recommend a waterfall-esque approach, as it is well suited when the date is the highest priority over all else. You probably still won't deliver everything the client wants; but if the date is the most important thing, you will at least be able to pre-plan towards that.

  • 2
    Upvoted this answer as I think it hits the major points effectively. I feel like it could be interpreted incorrectly though. The advent of frameworks like Scrum was largely due to the failure of waterfall approaches to deliver projects on time. I could see this answer being interpreted as saying that a waterfall approach guarantees that.
    – Daniel
    Commented Jan 27, 2020 at 20:25
  • 1
    @Daniel Not on time, but rather not what the customer wanted. That's why Scrum pays particular attention to a short time period for development and feedback; to ensure the feedback loop is as short as possible from the time a customer asks for a feature to the time it's developed, delivered, and used by the customer. The overall time it takes for a project to be 'done' is a non-issue from a scrum perspective. Commented Jan 27, 2020 at 20:38
  • 2
    I find that Scrum is a great help to estimate effort, manage risk and deliver on time. Why do you doubt it? Without knowing what you really mean by "waterfall-esque" in this context it's difficult to see why that might be better.
    – nvogel
    Commented Jan 27, 2020 at 21:06
  • 1
    Where "Success" comes in is when a customer and team are able to negotiate scope or time based on learning; in a 'contract' situtation where that is decided up front you'd have to explicitly put that into the contract and make sure all parties understand that we're working towards an outcome, not towards a date and scope. Commented Jan 28, 2020 at 13:17
  • 1
    For sure no method of any kind can "guarantee" delivery. The point is whether Scrum gives you a good chance of meeting what you estimated. If I had a lot staked on an estimate then I might well want to use Scrum as a reliable way of achieving it. Also estimation over many iterations is at least a little easier than estimating without any iteration because you only need to be accurate to the nearest sprint.
    – nvogel
    Commented Jan 28, 2020 at 13:57

There are two parts to this answer. The first is how you estimate and the second is if the premise of your question is inherently problematic.


First, the estimation. Generally speaking, there are two broad types of estimation: relative and absolute. Absolute is what we think of in traditional project management. You take a list of tasks and guess at how long they will take based on past experience. Of course, the problem with this is that most knowledge work is very different from task to task making absolute estimation an educated guess at best and a shot in the dark at worst. The fact that you say there are a lot of research tasks means it's probably closer to the shot in the dark.

The second is relative estimation. This is no more accurate than absolute. It is basically using statistical distribution to get "close enough". The potential benefit of relative estimation is that it makes the fuzziness of the estimate obvious and clear.

This desire for a clear answer in estimates matched with the near-impossibility of providing it has gone on as long as there is knowledge work, it's why most people pad their estimates, and it's why projects almost never finish on time. Pragmatically, I can only say that if the only way to win the contract is to give them a date, then give them a date. It'll be wrong, just like every other project. Ideally though, you have a customer who values transparency and prefers to talk in rough forecasts, not absolutes.

Why Use Scrum?

So, the second half of this is basically, why would you use Scrum for a fixed date, fixed scope project? The entire point of Scrum is that you learn what you need as you go. Each sprint has the potential to be a small pivot or a complete re-imagining. Scrum, as a framework, was designed for those types of projects. You will pay a lot of overhead for no value if you plan to create a plan and then simply follow it to completion.

Now, that said, if I were running a software company, I'd use Scrum, but I'd probably only take on contracts where I was able to get the customer into an effective conversation about why they want a Scrum company. That's a choice for your company though.

  • why would you use Scrum for a fixed date, fixed scope project? because after all the content can't really be fixed in every detail and because a prioritised, iterative approach is what gives the best chance (if anything can) of meeting the expected date.
    – nvogel
    Commented Jan 26, 2020 at 23:33
  • I would argue that if things can change, it isn't really fixed scope. I agree with your statement that it is the best way to approach most knowledge work projects. It just seems odd that you can, on one hand, assume the project scope is fixed and therefor accurately estimable and on the other hand use a framework that is designed to tackle complex adaptive problems which, by their definition, can't be predicted.
    – Daniel
    Commented Jan 27, 2020 at 2:02
  • 2
    Contractually "fixed scope" does not mean that the scope of a project can't or won't change. It means that different terms apply to anything that does change or fall outside the scope (i.e. usually it costs extra). In the end, fixed scope usually comes down to negotiation about what is to be included or excluded and that discussion may go on throughout the project.
    – nvogel
    Commented Jan 27, 2020 at 3:42
  • That is a fair point
    – Daniel
    Commented Jan 27, 2020 at 4:35

To use Scrum to good effect you would want the customer to understand that the product is a collaboration to which they will contribute through continuous delivery, review and feedback and product ownership. That being so, a given target date perhaps becomes less important than achieving a sustainable pace and ongoing customer satisfaction.

Once you have an estimated backlog the team can extrapolate a completion date based on expected velocity. Since the date of delivery is always the end of a sprint, the estimates just need to be accurate enough to understand how many sprints are required.

  • We can't estimate the whole backlog because it contains a lot of research also. Should just reject a customer if they require a completion date? Commented Jan 26, 2020 at 18:19
  • That depends on the significance of the completion date. If you don't have enough information to give an estimate then you can only tell them the parts you know about. That's where iterative delivery is useful. If you are delivering the product regularly enough then maybe it's not so important to know the completion date.
    – nvogel
    Commented Jan 26, 2020 at 19:00

I would like to share a few comments to add to the discussion.

First, a fixed contract means that the client is buying a defined set of working hours for a set price. You will typically present a work plan to the client which will include work packages. The Work Package 1 (WP1) will start on a "Start date of WP1" and will end on WP1 + y w (where y is the number of work weeks that it will take for WP1 to complete). Your time plan will include real dates but these will be indicative, as the people are people, things are not written in stone, and dates and plans and scopes change. I like how nvogel previously explained the meaning of "fixed scope".

Secondly, on Agile cost estimation, what is important is the past experience and how this is documented to aid with the estimation of future projects. An estimation model is no more a necessary component of the process, than is an Expert on the team to help when Expert judgment is needed.

During the requirements analysis stage, you will need to turn the project's requirements into user stories, the stories into tasks and, based on analogy, to estimate them.

We estimate features by analogy given our experience gained from similar projects.

Expert judgment is valuable, when there is no previous experience on a task. Therefore, you need to count on the expertise of an Expert to estimate new features.

Estimating by analogy and Expert judgment will lower your risk.

Some last things I would like to mention:

  • It is important that you have a good understanding of what the Scope means and document it.
  • It is important to identify and document the project's Risks.
  • Keep in mind that a well-defined scope will not prevent changes in your work plan. Changes happen, you just have to anticipate them.

Firstly it is worth noting that the Scrum framework is designed to use iterative development and feedback to build a better product. You are unlikely to get all of the benefits of Scrum when using it on a fixed-price, fixed-scope project.

As for estimating, there is nothing to stop you using the same method you would use on a traditional project. For example, you could break the work down and then prepare a time-based estimate on it. If you do this before work starts then your estimate will come with all the risks usually associated with long-range estimating.

If you have an established Scrum team you could try and use their velocity to estimate the project delivery. This will at least be using empirical data to produce the estimate, but is it still unlikely to be accurate due to discovery, technical uncertainty, requirements creep, etc.

At this point you may ask the question: is it worth using Scrum?

I think you can still get some benefits from Scrum even on a fixed-price, fixed-scope project. These include:

  • Reduced technical risk due to an iterative delivery approach
  • By monitoring the team's velocity you can see if they are on track with the plan, so you should get early warning of missing a deadline or running over-budget
  • The benefits of regular retrospectives

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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