2

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?

MetaFight
  • 11,549
  • 3
  • 44
  • 75
Hernan Carreras
  • 21
  • 1
  • 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: http://programmers.stackexchange.com/questions/311047/scrum-dealing-with-failed-sprints-and-deadlines. 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
  • Hey, thanks for the answers (and the editing in the post for a better english) Thanks for your answers. I see that our problem it's a common problem. In our team one of the members proposed to use the story points as a way to determinate the amount of money each task will cost. If we have a figurative budget of 100 and all the project take an estimate of 100 points to finish it... he said that each point shuld be equal to a percentile (in this example 1 point = 1%) And that way the payment will be fair for every task. I have several problems with this idea, but what do you think? – Hernan Carreras Jun 19 '16 at 19:41
  • Do you need to charge for features instead of a fixed cost per iteration? – Thomas Owens Jun 19 '16 at 22:34
  • It's depend on the costumer but usually, yes. – Hernan Carreras Jun 19 '16 at 22:41
  • Were you successful in providing estimates before you started using SCRUM? If so, why change? – JeffO Jun 20 '16 at 15:03

3 Answers3

5

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.

Cort Ammon
  • 10,840
  • 3
  • 23
  • 32
0

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.

MetaFight
  • 11,549
  • 3
  • 44
  • 75
0

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.

Euphoric
  • 36,735
  • 6
  • 78
  • 110