How is budget decided?

If the team is in a position to deliver value incrementally, then why not fund the development effort incrementally, sprint by sprint?

Ian pretty much answers your question but...

1) How do i know my budget without having to analyse all my features?
If the customer has budget £25K a SCRUM team of 5x Developers at £350 per day can deliver 3 sprints. Is that what you are looking for? What can those 5 developers produce? Only they can tell you that. The budget is constraining the timebox you have available and thus you'd only be able to deliver 3 increments of working software. The customer should see the value you've produced and may choose to continue funding it.

2) [Imagine] we have a big project where all features were analysed and estimated. A client suddenly decides to stop because of budget reasons. <snip>
Whilst the customer is funding the project, SCRUM ON, you'll be adding value. They stop providing funding, SCRUM OFF, you stop providing value. Simples.

2) <snip> How does a company deal with the lost time?
As Ian has suggested above, only commit to a sprint when there is budget available. Should the customer find extra budget at a later date, cool, SCRUM ON!

Hi Andy,

I hear your problem. It can be confusing to contrast the development estimation benefits of Scrum against the external issues of budgeting for a project that hasn't been estimated completely.

Have you thought about the difference between the responsibilities for budgeting and estimating, as it relates to your team? When I'm working with a Scrum team, the budget usually comes from someone outside the team, who interacts with the developers through a product owner. The team's incremental estimates of what can be done in a given sprint have to be balanced against budgetary constraints that exist outside the team's scope.

One nice thing about Scrum as it relates to budget constraints is that a complete slice of functionality is supposed to be delivered at the end of each sprint, so the product owners can take a look at where they are, and go back to the people with the budget to decide whether it makes sense to move forward in the same direction.

To address your second question, it's always possible that the product owners will decide that development costs so far have been enough to prove that there isn't a valuable product opportunity, and cut their losses. (Better they should decide that now, instead of waiting until the entire product has been developed, right?) All that means as far as Scrum is concerned is that the team's backlog will need to be shifted to features for a product that is worth developing.

Let me know if that helps, or if it just raises other questions. It's an interesting issue.

Hi,

Your answer is a very modern way of thinking and from a SCRUM based perspective.
But ..in every company you have an IT manager Bob who wants to innovate and has his own budget for 1 year.

This IT manager Bob wants to find his solution, so he writes multiple software companies companies.. I want "X" and what is will it cost us.

The last thing that IT manager Bob wants to hear is. "Well.. how much can you give us.. and perhaps with your budget we can finish it. We will give you value for your money but I can not garantee it will be finished."

IT manager Bob wants to compare , stay within his yearly budget and have a finished product.

> But ..in every company you have an IT
> manager Bob who wants to innovate and has
> his own budget for 1 year

That's right. Bob wants innovation but doesn't want the shift to incremental funding. Agility sounds good to him, but he doesn't want it to challenge his idea of value or upset his patch.

There are lots of Bobs who want change, but who don't want *to* change. How do you intend to deal with yours?

Well Ian, I wouldn't ask if I knew the answer ;)

I could try to convince him that the SCRUM allows him to have his core software faster, only pays until he is satisfied with the result therefor potentially paying less than expected? (rings and bells are not needed).


But I will give you the answer of Bob:

-I'm 50 years and i have 25 years expierence in my job. You're 33 with 11 years expierence.
-My company has been happy with my track, so why would i suddenly risk it all by changing my way of working.
-I can't compare with other software companies.


I should add that Bob is IT manager of a company between 20-50 people. They don't have the budget for several sprints with a scrum team(s) of 5+.

It sounds as though this particular Bob is very comfortable and secure in his work, and does not face significant threats in terms of competition or disruption, nor a need to budget accordingly. If that is indeed the case, then I'd congratulate the lucky fellow and move on to another prospect.

There are others operating in far greater conditions of uncertainty, and they are the ones agile practices are designed to serve.

Hello, Could someone explain me the following:

A new (small) project starts , a product manager starts by making a list of features / scope.
The develoment team decides that the feature list is too big to fit in 1 sprint of 1 month.
Only the first sprint is analysed and estimated.

Hi Andy, Practical question. Here goes my $0.2 on the subject.

*NOTE* It is more from a business perspective and not from Agile perspective but everyone knows that processes and frameworks are created to serve the businesses and not otherwise :)

1) How do i know my budget without having to analyse all my features?

a) Analyze all your features

b) Estimate the project as you'd normally do (using any conventional, non-agile methods that you're comfortable with)

c) Calculate one-month timeboxed cost of iteration. Refer to this article by Jesse Fewell on the subject: http://www.leadingagile.com/2012/11/calculate-budgets-agile-team/

d) Now you have calculated your budget using two different methods. Use a variable factor to deal with uncertainty, that will come up.

e) This way you'd know how much margin you're going to keep - now, you can make an offer that makes the business sense

*NOW, MY NOTE ON SCRUM:* When we execute a project using Scrum, the opportunity is to retrospect at the end of each sprint and ask ourselves - are we going in the right direction? Did whatever we do in the past sprint is of any value from the business perspective? And take corrective actions.

In theory, taking corrective actions means that you can stop developing further or pivot if the business value is not found in the delivered increment. Practically, many people (and companies) fear that practice. Which is normal because in business we need predictability although we know that life itself is not predictable - but agile!

So, business-people want predictability and budget is one such practical problem so rather than dealing with that problem using agile techniques, we can choose to deal with it using any other conventional technique that works.
Sure, since we're considering agile, then we'd get the cost of iteration and add some variable factor to make some changes but it is, at its best, a kind of guesstimation.

This is not a perfect way. This is not where you will get optimum value from Scrum. Scrum framework is effective when the focus is on delivering value, not on finishing something by the budget.

If you can, avoid Scrum - or other agile practices - for these kinds of projects. If not, then you can tweak but in that case you're not using Scrum - or agile.

For the IT Manager Bob, predictability matters so he would not care which development framework the service provider uses. To win that project, make an offer that Bob cannot refuse.

Is this Scrum? No.
Is this Agile? No.
Is this business? You know it better :)

In my opinion, when not to use Scrum is a distinction that every practitioner must have because then Scrum remains a tool, not a magic wand.

The war has to be won; does it matter if you win it using Swords or Guns?

2) Imagen we have a big project where all features were analysed and estimated. A client suddenly decides to stop because of budget reasons. How does a company deal with the lost time?

Well, this is also a business problem not a framework or a methodology problem. You have a big project. You know your customer. You know what matters to him and what does not.

If the client is not wiling to deal with an uncertain next, then Scrum is not right framework for projects where he is involved as @Ian Mitchell rightly pointed out. The reason being, the customer is a key stakeholder and if the key stakeholder does not believe in the practices being performed at a service team level, it is very difficult for the team to make the project successful.

Now considering the budget question, if I were to deal with such a customer, here's what I'd do:

a) Based on expert judgement, I'd provide a higher level budget / estimation
b) Based on actual practices, at every small interval, e.g. 1-2 weeks, I keep an eye on the budget / estimation and communicate the same to the customer and take his buy-in on every possible encounter
c) In a nutshell, I keep Bob posted with what is happening, show him demos and provide him a sense of predictability in the practices that I'm following to execute the project.

It is important for Bob to be in good books of his bosses so I'd do everything possible to make Bob win.

If I get a chance to talk to Bob's bosses then I'll make sure that Bob gets all the credit for the work my agency is doing on the project.

This way, I'll establish a relationship based on personal rapport and trust with Bob and then eventually in next projects I'll have better listening.

I know that my answers might not "qualify" for correct agile way of doing it but I have seen the scenarios you are seeing in practice and the practices (or its variants) have helped me deal with such issues so thought to share my experience.

I can only say : waaw thanks.

This is of interest to me also, having been a PM on some large fixed deadline projects in the past (before Scrum).

It seems that Scrum "doesn't care" about things like budgets or end dates, for example how does one establish confidence that some critical end date will be met unless one factors in the cost/time for all of the subtasks (up to some level of granularity)?

Scrum - from what I'm gathering (which may be wrong) seems to say "Lets see what we can deliver in three sprints and and the extrapolate that to estimate get some rough end date, in which case its hardly suitable for critical projects with immovable deadlines.

Is this true? is Scrum ill suited to some kinds of projects and only suitable where cost/delivery is not that important to the organization?

Korporal.

Scrum is best suited for developing complex software products in conditions of high uncertainty. Confidence is assured through incremental release and the empirical assessment of progress.

Stage-gated or waterfall processes may be appropriate in simpler and more certain conditions, or certain non-software ones, where confidence might be assured by projections and promissary notes such as gantt charts and process documentation. In these conditions having empirical evidence of value delivery may be unnecessary.

Posted By Ian Mitchell on 04 Jun 2015 01:41 AM
Scrum is best suited for developing complex software products in conditions of high uncertainty. Confidence is assured through incremental release and the empirical assessment of progress.

Stage-gated or waterfall processes may be appropriate in simpler and more certain conditions, or certain non-software ones, where confidence might be assured by projections and promissary notes such as gantt charts and process documentation. In these conditions having empirical evidence of value delivery may be unnecessary.

This is helpful, you explicitly point out that its suitable when there's high uncertainty, whereas a PM based approach will (usually) strive to continually reduce uncertainty and ever more closely approach a well defined goal.

I think its important too to stress that a PM based approach to delivering some "thing" is not inherently a waterfall model - it can be but often isn't (and shouldn't). The infamous waterfall method was in the past the established way to deliver software systems, that's its origin, there's nothing waterfall though about project management in and of itself.

In a well designed project multiple parallel activities are often underway whose output is the input to another set of activities, opportunities for parallelism are and should be pursued as the plan is gradually formed.

I can foresee with scrum situations where team members would be saying "Oh man, if only we'd known this two months ago, we wouldn't have written X..." this amounts to wasted time in my view and a PM based approach is always striving to reduce the risk of wasting time, it can and will happen but the process itself (and the PM primarily) is always seeking to uncover uncertainties on a daily basis and taking remedial action promptly.

> ...a PM based approach will (usually) strive to
> continually reduce uncertainty and ever more
> closely approach a well defined goal.

In Scrum, uncertainty is reduced by empirical means. The only evidence of progress that is considered to be acceptable is the actual delivery of working product. The conditions of high uncertainty in which Scrum has most to offer are stabilised by this means of incremental delivery.

> I can foresee with scrum situations where
> team members would be saying "Oh man, if
> only we'd known this two months ago, we
> wouldn't have written X..." this amounts to
> wasted time in my view

Scrum allows team members to make these discoveries with each incremental release, and to inspect and adapt product and processes accordingly. An efficient implementation of the framework will reduce the incurral and discovery of such waste to no longer than one calendar month. Less agile approaches would extend this period over which empirical evidence can be gathered. Waste would increase until such time as a release is made and empirical evidence about a product's value can be obtained.

There is also different side of coin - Being Bob - how to trust someone who is e.q. young and willing but lacking of same experience level. All comes with trust. You can get it and you can earn it. What helps is moving closer piece by piece - and this is the toughest one in change I think - sustain with will and apply different ways how to move closer you want.

I believe people are smart ones, Bob is also smart, and in his gut feel he wants same things as you. The method is something which is hard to believe, because you need to let go of control and still be accountable for results.

It's quite old thread but I add 2 cents as this is quite important topic

Looking on the Ian comments and general scrum approach, it sounds like "it will be done when we finish, it will cost depending on how long we will work". It might work fine if you develop own Product or you have very reach customer which does not care if he will spend 100k USD or 1M USD.

I would like to put here simple example, you want to build house. Would not you like to know how much money it will cost so you can prepare budget for it? Would you just hire construcion company and let's see what we can get? I do not think so, you want to know how much money it will cost you before starting the work.

Currently where I work we do two types of projects:

* own Product continues development - it means all the time we add new funcionality and improvements to our own software, we have own developers - SCRUM is excellent approach for it

* software development for customers - in 100% of the projects which we do, customers ask for fixed price, they won't accept any other approach because they need to do Buisness value evaluation. How much money I can get from this project and how much it will cost me. They need also to reserve fundings for the project otherwise it can't be executed. It this case as others already mentioned, we can still make full project evaluation, time, resources and cost estmation taking in account that we will use scrum. In this case you have the estimation with all requirements. You can use scrum for development and you can get feedback from customer after each Sprint Review. Do not be surprised if customer do not show up or try the solution 6months later. Customer can ofcourse ask for changes as he finds out that maybe he needs something different. No problem, but then he has to add more money to budget if new changes require more development effort or drop something else so in same budget we can do same job. 

@Wojciech Monka

 in 100% of the projects which we do, customers ask for fixed price

Have 100% of the projects you do finished within budget, within scope, and within time? If not, how valuable has a fixed price been to the customer?

They need also to reserve fundings for the project otherwise it can't be executed. 

Can the customer not set aside a budget for the project up front, based on past experiences and an understanding of the return they expect, also keeping in mind that they may see value in providing more funding at a later date?

they won't accept any other approach

If a customer simply won't accept an Agile approach, then they won't accept it.  They also won't realise benefits of an Agile approach. 

you want to build house. Would not you like to know how much money it will cost so you can prepare budget for it?

The house example is difficult, because adding incremental value is more difficult in the construction industry, as opposed to software.  But let's look at it from a basic, livable house (which can be built in a four-week sprint), adding extensions (extra functionality) to the house as necessary.  

Knowing that you'll probably want a house with two extensions (broad road map), you set aside a budget of about 10 weeks of the construction companies hiring costs.  

After the first Sprint you see the basic, livable house, provide some feedback, and adjust the road map as required.  Meanwhile, you're able to live in the house, already gaining a return on investment. You are now at 6 weeks of budget left.

The second Sprint begins and by the end you have one extension.  You are now at 2 weeks of budget left. In the Review of the second Sprint, you realise to get the second extension you either need to provide another 2 weeks of funding to your budget or stop the second extension, and finish the project there.

Either way, you have a working increment which is seeing return on its investment.  It is now up to you to determine whether you think its worth continuing the funding for the second extension.

Great thread. I am completely new to the budgeting topic and have limited PO knowledge outside guide, so I am happy read different views. 

While I see agile benefits for development, I don't see how agile approach goes with money also. I understand original question and I am not sure I am satisfied with answers in sense I can make some conclusion and learn the answer. I do understand that its fine for for example :

1. internal projects funded by company with incremental budget
2. or project where maximising outcome within limited budget is welcomed 

but I see big problem in apparently simple question posed by @Ian 'why don't fund incrementally'. 

@Alex's approach to house is nice - but how it goes with mortgage ? What if you don't have cash? How many times do you want 'incrementally' convince bank to get money ?

The same holds for startup, what if it doesn't have enough cash ? It needs apply for investment, or it has board hesitating for putting money? 

Well, let me add my 2 cents. From my reading and understanding of Agile and Scrum, the management and budgeting is more geared from a developers point of view. ( Ian ) You are assuming that all the developers are talented, and only they decide if it can be done and when it will be done. That information is given to the Product Owner who will make the call whether to proceed or not. In other words, the IT team decides whether your software application/project will be delivered that is practical and usable within a certain time. The developers and the Scrum Master are not really bothered about the cost because they are focused on technical stuff and real development work. For them, it is like this. You want this application with these features using this architecture and methodology, this is how long it will take. They would not know the salary of every employee on the team because Scrum assumes for technical reasons that all are developers.

What people fail to realize is that Corporate Management have their own CAPEX (Capital expenditure) for various projects and products that they plan to produce and dole out. And that depends on the type of company and industry. So, they plan at a very high level and it involves the executive branch CFO, COO, CTO etc and VP's of Finance, Marketing, Sales, Manufacturing, Operations, Support etc. Once the projects are approved at the higher level with their milestone, it then shifts to which projects have what priority for that fiscal year assuming that all projects differ in type, size, scope and costs.

The responsibility of whether a project then gets approved is with the PMO (Project Management Office) where they do their own feasability studies and comparison with prior projects and costs. Estimation, Costing, Budgeting and profitability analysis and so forth are carried out here. Should we purchase of the shelf package or should we produce in-house?. If we buy off the shelf, who are the reputed vendors, RFPs, what are the terms, conditions and guarantees, after sales support, training, h/w requirements etc.... If we develop in-house, do we have the required architecture, IT Staff, technical know-how, experienced personnel and so on.  It is only after that decision is made that an approval is given. And by that time, the company already has a ballpark figure as to how much has been allocated for the project.

Obviously the Product owner who is sitting with Management and the PMO will know what is the allocated budget for that project for that fiscal year. What the Product Owner may not know is what each one employee earns, and will have to make an estimated guess of what it would cost the company per developer x 8hrs. at 40 hrs per week for each Sprint. So an experienced Product Owner is the key player who is responsible for the budget. The PO will need to relay that information to the IT manager and the Project Manager in order to keep track of expenses and time management.

So in short, it is not as though one can just throw out some philosophical statements from some scrum guide and expect all companies to just agree to everything in it. That is just a framework which guides the IT team who work on the s/w project. At the end of the day, what is value to an IT team need not necessarily be value to a Management team. A project may be successful in that it was produced on time, and within a reasonable budget. But then the application produced did not or may not have got off the ground for numerous reasons. The users did not find it user friendly, or they were slow to change, or the training was insufficient. It could also be that the company merged, and so the new application was not a priority, and shifted to integration of systems as the parent company felt that their systems were more advanced - Think Oracle / SAP ERP.

At the end of the day, all avenues have to be looked at before one can just talk about producing a functional product in increments. After all, Scrum is just a framework within which process and methodology are used to create a quality product. It was never written with the business view in mind. And if a business is not successful, what good is it to concentrate on just executing Scrum?.  It has to be balanced with the PMO.

This is a great thread that I've come across while researching the challenges companies face nowadays with developing in Agile, but having an overarching budget and deadlines for the complex project or program, that are set at a senior level. I couldn't agree with you more Cecil D'Souza!  For project delivery to be successful in a business, where the budget and deadlines are set for the year and allocated per project, you cannot rely solely on scrum for delivery.  Whenever people start talking about Agile methodology and the benefits of scrum, it's always from the Developer's perspective.  But when you're in senior management and have to align the spend back to a overall budget that has been set by the C-level executives, you simply can't get this perspective from an Agile methodolgy.  (Or at least in my experience; I'm happy to be corrected on that).  

 For project delivery to be successful in a business, where the budget and deadlines are set for the year and allocated per project, you cannot rely solely on scrum for delivery.

Yes, but why should the budget and deadlines be set for the year and allocated per project? Can we be more agile when making the budget? Can annual budgeting work in an uncertain and competitive environment?

Hi Andy, 

Hi to all,maybe, after of your "Discovery Works" phase, you can start inmedially the "Releae Statement" phase getting the "Product Roadmap" as result, then start with the sprit cycles, adaptantiing the roadmap acordelly. 

is very useflul for us, an early and shared vision of the roadmap of our product!!! 

I hope can its help to you and get the answers that you are looking for. after learned a lot from the community. thanks to all guys,  

Gabriel  

A well-planned budget is a result you should expect from a discovery phase step. It creates a much wider context both for the development team and the client and helps to come up with non-standard and sophisticated solutions.

Hi you all, this is a very old thread with very interesting questions sort of blankly pending within the Scrum framework.

It is mentioned that the PO should manage the budget, however this is not clearly stated on the Scrum Guide... of course it makes sense because (s)he is accountable for effective Product Backlog management. However, is it possible that an eventual lack of budget is to be considered as an impediment to the Scrum Team's progress, therefore being this an activation of the servant role of support from the Scrum Master to the Product Owner, facilitation stakeholder collaboration as requested or needed?

In the same way, an eventual lack of budget for the development of refined PBis could be a reason for a PBi to get a lower position on the Product Backlog? Hence being this an impediment to be considered at least on the next immediate Sprints?

Thanks!

An eventual lack of budget could also mean that stakeholders no longer want to finance the product, in which case there is no impediment to resolve. We can't force stakeholders into financing a product they no longer want or need. Scrum Master could certainly facilitate discussions with stakeholders if that was needed but it is worth noting that while Scrum Masters may serve, that doesn't mean they are servants or in a servant role.

PBI order changing doesn't seem like an impediment. Just because a PBI has been refined doesn't mean it will be developed. The market or needs for the product could change at any time. If there is a lack of budget the PO and/or the Scrum Team may have to make some tough decisions about what is most valuable to work on with remaining budget. This could be PBIs that are not yet refined, or those that have been. It really depends on the situation.

In practise the budget is different from organization to organization and depends on many factors, often beyond the control of the Scrum team. 

In general the Evidence based management guide released here at scrum.org at 2020 provides some interesting insight on budgeting