We are a bunch of freelancers working together making websites and apps and we starting using Scrum recently. We're enjoying Scrum and its transparency but we're encountering a problem with the budget side of the equation.

It feels like Scrum doesn't consider budgets, but we are too new to know for sure.

Is there a way to consider budgets and task cost in Scrum, or does it go against what Scrum is trying to achieve by using Story Points?

  • 2
    Cost evaluation is really hard in SCRUM environment, because SCRUM was designed to be too adaptive and able to change pretty much anytime during the development process, that's why it consists of sprints. You may evaluate the cost of each sprint and use that to some extent, however if you really want to know the price of a product beforehand, a traditional approach may be more feasible. Once you gain some experience and realize your SCRUM processes consist of similar parts, you can somehow expect what will be needed and evaluate the price from that, but you cannot be truly certain. – Andy Jun 19 '16 at 18:32
  • 1
    Maybe related: programmers.stackexchange.com/questions/311047/…. And don't believe that Scrum makes it harder to evaluate costs in Software development (of course, it also does not make it easier, because that is not the goal of the method). Cost estimation in software development is always hard, but this has absolutely nothing to do with Scrum. – Doc Brown Jun 19 '16 at 18:57
  • @DocBrown Not directly, obviously, but it is difficult to determine the total cost. More difficult than using a traditional approach. – Andy Jun 19 '16 at 19:17
  • @DavidPacker: whatever you call traditional approach might give you the wrong impression that cost estimation is easier, of course ;-) – Doc Brown Jun 19 '16 at 19:22
  • @DocBrown With scrum you cannot really define a price beforehand because you don't know how the plans will change throughout the process. That's one of the reasons why scrum driven development does not have an end date. With approach like waterfall from start to finish you can estimate how long each phase should take and therefore how much it should cost and you can give a price estimation. It's not easy either, but definitely easier than when using one of the agile models, be it scrum or Kanban, for example. – Andy Jun 19 '16 at 19:30

Scrum does not consider things like budgets or deadlines directly. Instead, it seems to provide the program management with the information they need to conscientiously manage budgets and deadlines. Story points are an excellent example. On their own, story points say nothing about how long a task will take. They talk about the complexity of the task. However, it is considered reasonable to look at a "velocity," which is the average number of points per week your team is doing and try to determine how long X story point should take. Velocity is a very popular and very powerful tool for budgeting in SCRUM.

My opinion on the theory behind this is that most systems which explicitly consider budgets or deadlines have a strong tendency of leading developers to give poor estimates in order to fit a budget. Often key information is squelched because it would show just how far off schedule the team is. I believe SCRUM's solution to this problem is to try to concentrate on making sure the information flows properly first, and only then consider deadlines.

SCRUM does encourage customization. You may be able to adjust its workflow to suit your particular company's needs.


Story points are typically a measure of implementation complexity. While there is a correlation between complexity and cost, in most scenarios cost will be affected by a number of other factors.

So, story points may give you a rough estimate of your implementation costs, but it will be so rough that you shouldn't really rely on it.


The primary point of SCRUM (and other iterative or agile approaches) is that it is not known what work and how much of it is required to "finish" the project. At any point during the project new tasks can be added, expanded or removed based on feedback from the customer. This is why SCRUM and other agile methodologies opt into making working software every iteration to give customer sense of progress instead of "traditional" we are x% done when x% of [budget is spent] / [planned time is spent] metrics.

This is problem for any form of predictive metrics, like estimated total cost or time needed, because you have no fleeting idea how much work actually needs to be done. There are ways to guess, but the more complex and big the project gets, the more uncertainty you get. And I don't know if your customer will be fine with estimation of 1year +- 9 months and with related total cost.

If you really need to estimate total cost and time spent, I would get rid of SCRUM and go for more traditional approach where you try to guesstimate all tasks needed to finish the project and how much work is required to finish them. You at least get some semblance of certainty that your guesstimations might be correct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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