18

I'm really confused on how agile projects are budgeted for cost and effort before the project starts. Cause the user stories are never completely discussed and estimated as a practice in agile. So if we do a guess and arrive at a number of story points (by may by the product manager during the inception) which by definition will be far from accurate, how cine the budget is finalized based on that wild guess.

Any insights would help...

Improve this question
1
  • Joel is correct. You budget the agile team and they will deliver the high priority scope. Agile will not go over or under budget in this case.
    – Firooz
    Oct 19, 2017 at 5:35

4 Answers 4

Reset to default
18

Well the easy and probably not completely helpful answer is, agile requires a change in how the business plans. You fund teams, not projects.

That's not entirely helpful so let me try and bridge the gap.

The success of an agile project boils down to having a good backlog and dedicated teams.

  • If you don't spend time planning a backlog, then you'll never get an accurate estimate, and as a result you won't get a good budget. That is not to say you need to decompose the entire backlog down to its component tasks. You need to decompose enough to get the answer you need. The critical key is the acceptance criteria. You could have a massive epic of "Provide spa services in the hotel" and if you have acceptance criteria for it "Massages, Facials, Mud Baths, Zen Waiting Room" then you can estimate and hence budget.

  • A well formed and functioning team will be able to take a high level backlog and generate a reasonable estimate of the time to deliver. More importantly, a well formed team working with a good product owner (or product owner) team can prioritize the user stories. Why is this important?

  • When using Scrum the date is fixed. This allows you to budget for the effort. What then becomes fluid is the scope. Because you prioritized the backlog correctly, if something doesn't get built, it will be one of the least important items (and may well fall into the 60% of features that never get used or used only rarely).

Is this perfect? No. Then again, a Harvard Business Review study showed that one in six IT projects have a cost overrun of 200% or more. You won't be going over budget with an agile project. You may just not ship everything you planned to and when you dig in, may find that's entirely okay.

There is a good HBR article on budgeting in agile here: https://hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate

Improve this answer
3
  • 1
    So if I understand correctly, in Scrum, with a fixed deadline, an high-level estimate should be done to calculate the cost and retrofit the scope based on the fixed deadline.
    – user3189851
    Jun 24, 2015 at 1:52
  • 1
    Yes, though generally the schedule is going to come first. Just the way of things in most high-tech companies.
    – Joel Bancroft-Connors
    Jun 24, 2015 at 14:51
  • @user3189851 Scrum essentially turns the classic "This is what we want. When will you have it and how much is it going to cost?" -> into -> "These are our ideas. Build the best subset you can with X time and money"
    – Kempeth
    Oct 19, 2017 at 10:13
6

One way to think about it is using the classic "accuracy vs. effort" curve. Sure, you can spend significant time planning up front, but you quickly hit diminishing returns on accuracy and will most definitely waste time planning things that won't make it into the final product (placing yourself far along the curve).

Or you can take an agile mindset and plan just enough to get started, even if that means a budget range or flexible scope as Joel mentioned (being lower on the curve but accepting that it might go up or down by some %).

Improve this answer
2

In my practice, agile projects are set up and budgeted the same way as the regular ones. We have business case / high-level scope, based on this we make a preliminary estimation for cost and schedule, check it against our past experiences (or past project metrics), and document it in the project charter.

Most agile methods do not cover the entire project lifecycle, so from high level (say, from top management level) projects that are agile are just the same as projects that are executed in a more traditional way. Of course, for expectation management reasons it is good to communicate the methodology (so they will understand and even anticipate scope changes).

There may be one significant difference when estimating agile projects: it is usually a very bad setup if you only have time / budget for mandatory requirements, so either include some optional ones in the initial scope, or have a big (30-40% or even more) reserve for extra features that may come later. This way your team (product owner, etc) will be able to handle scope changes in a flexible way.

Improve this answer
0

You have to have the Fiduciary guidance while allocating a budget for a Value stream, once you get at value stream level, you can estimate the stories and size the Features and Capabilities

Improve this answer

Your Answer

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

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