We are working for a customer where we are using Azure DevOps for planning and estimating work in Sprints. This is the usual way to plan the work among our developers, but our customer wants a better estimate of how much money will be spent the next month. This will be across teams and Sprint iterations. Some say it might be good to look at forecasting or delivery plans. Why might they be asking for more accuracy?

  • If you plan and estimate work in sprints you have a measure stick already. Do you use some sort of velocity in your sprint? If you already know what you will be working on, you can use past velocity to forecast future work. Long term planning in Agile often creates waste, but one month should be fine. Just account a buffer for the usual suspects (i.e. things unexpected that occurred in previous sprints, or known risks).
    – Bogdan
    Commented May 15 at 11:16
  • You may also want to consider using some form of agile release planning. This answer describes a typical agile approach for that in detail.
    – Todd A. Jacobs
    Commented May 16 at 7:04
  • 1
    Does the customer run out of work at some point? If you are working for them at full capacity, the cost should be trivial to measure, the big unknown is how much they will get for their money. Or do you have a fixed target and adding manpower until you reach it? Then it isn't Scrum or sprints at all.
    – nvoigt
    Commented May 16 at 9:11

2 Answers 2


You don't need to forecast anything about the work or delivery plans to determine the cost.

If you have stable teams and fixed-length iterations, you should be able to calculate the cost easily. You can multiply the cost of the team per hour, day, or week by the number of hours, days, or weeks in your Sprint to get the cost of the people.

Depending on your agreements, you may need to also factor in costs for tools and infrastructure. Also depending on the terms of the agreement, you may also need to factor in a profit margin on top of billing for costs.


[O]ur customer wants a better estimate of how much money will be spent the next month[.]

If you're doing iterative delivery using fixed-length Sprints or even the Kanban Method with stable cycle times, you generally have an average burn rate on labor. That rate shouldn't vary outside of an expected range during a truly agile project.

Your capital costs such as equipment purchases, elastic pricing on cloud services, and so forth might vary though. However, if you've already mapped out what features are planned then you should be able to forecast any capital costs associated with those plans.

If your labor costs aren't stable, or you're unable to forecast capital costs, then you probably have a different problem than the one you think you have. Most likely, you and the customer are failing to agree on:

  1. Scope, which is generally the flexible constraint in agile frameworks based on a fixed run-rate.
  2. Schedule, because they're expecting (or you're promising) more pr faster features than can be delivered in a fixed time box or at a fixed run-rate.
  3. You're not really billing per team per Sprint, but are doing time-and-materials so you can meet schedule or scope targets that are not being accurately estimated or that don't have a reasonable Definition of Done.

In addition, there may be communication problems between the team and the customer. Examples include:

  1. The team not be setting customer expectations appropriately, or leaving insufficient slack to absorb change requests or unplanned work.
  2. The customer may be inserting changes in the middle of an iteration without understanding the impacts on team capacity or the delivery cadence.

There are certainly other possible problems, but these are some of the most common ones. The bottom line is that unless you're estimating poorly or communicating ineffectively with the customer, this is most likely a problem with expectations rather than one of precision.

Agility is a tool for creating predictability, both for the team and for the customer. Make sure you're using your framework to do that!

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.