Self-Funding Projects – A Benefit of Agile Software Development
One of the many benefits of developing software in an iterative way is that you can start realising the benefit of your work before the project is officially ‘finished’.
The objective is to front-load the project with the most profitable or highest value deliverables and release them as soon as possible so that they can start making money for you. If you’re using a Lean approach, you’ll release them as soon as they’re finished, if you’re using a Scrum approach, you’ll cluster a few into one (or more) releases at the end of each iteration.
It’s worth noting that not all projects or deliverables offer a financial return, however one assumes they still offer value of some sort e.g. Strategic, Compliance, Risk Management, Cost Avoidance, Technical Debt etc. These types of projects/deliverables may never become self-funding.
Those projects that do offer a financial return and particularly those that have been pitched for off the back of an impressive Return on Investment model should become self-funding at some point during the project lifecycle.
Self-funding projects are great for the following reasons:
- Less investment required up front
- Less debt being carried through the project
- Reduced risk
I will share a scenario in hopes to illustrate this concept more effectively.
For more details on the scenario itself and what to do when assessing your own project, download the Excel Template at the bottom of the page.

Self-Funding Projects - A Benefit of Agile Development
This scenario describes a project with 25 User Stories of varying size and value.
The team has a velocity of 21 points and for the sake of simplicity, a cost per sprint of £21 i.e. £1 Cost Per Point (“CPP”).
I have included a financial cost (CPP x Story Points) and an ROI for each User Story.
In reality, it is unlikely that you would/should take the time out to calculate the ROI for each story, however it helps to illustrate this point.
With that said, you may choose to produce an ROI at an Epic or Theme level, then prioritise the comprising stories using Value Points vs. Story Points.
As a starting point, calculate the earning potential of each story i.e.
Revenue – Cost = Priority
For non-financial scenarios, you could calculate Priority using the following equation:
Value Points - Story Points = Priority
After determining the priority of each story, you can produce a release plan. Take care to squeeze as much value into each sprint as possible – this may mean you need to de-prioritise certain high effort / high return stories in favour of a low(er) effort task so as to stay within the Velocity.
Some factors to consider when prioritising delivery include:
- Story Point (Effort)
- Value Points
- Velocity – You may need to prioritise low effort/low(er) return stories over higher effort/return due to capacity
- Risk
- Other: e.g. dependencies, constraints, holidays, skills e.g. Do you have the skills required to deliver the story?
As you would expect, the percentage return for my fixed £21 per sprint effort is much higher towards the beginning of the project.
For example:
Sprint 1: Cost = £21, ROI = £165, 686% return
Sprint 2: Cost = £21, ROI = £89, 324% return
… Sprint 5+: The ROI doesn’t justify the Investment. These stories should be dropped unless they deliver a high value, non-financial return.
The total cost of the above project is £122 with an ROI of £383, however from the end of Sprint 1, we are £144 in profit with only £101 of outstanding cost. It is at this point that the project becomes self-funding i.e. the generated profits can sustain the rest of the development.
In theory, we *should* be able to deliver this £122 project with an investment of only £21 up front, a rather attractive prospect to any investor.
In a traditional waterfall projects, we’d require the full £122 initial investment and would realise no return until after the project was finished. This leads to :
- Higher cost
- Higher risk
- Higher levels of uncertainty
There you go – the rationale behind self-funding projects in a (highly simplified) nutshell.
Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!
Case Study: Self-funding Projects - A Benefit of Agile Software Development
Related Articles:
[...] PDRTJS_settings_81187_post_441 = { "id" : "81187", "unique_id" : "wp-post-441", "title" : "Interesting+blog+posts+%28July+30%2F2009%29", "item_id" : "_post_441", "permalink" : "http%3A%2F%2Fanalytical-mind.com%2F2009%2F07%2F30%2Finteresting-blog-posts-july-302009%2F" } Along the same line as an earlier post I wrote, Tara Lee Whitaker demonstrates that using an Agile approach (Lean or Scrum) allows you to start realising the benefit of your work before the project is officially ‘finished’. [...]
[...] https://agile101.net/2009/07/22/self-funding-projects-a-benefit-of-agile-software-development/ [...]
Thanks for this cool post. I definitely agree with this. Anyway i found your blog on google and find it very useful. I’ll be sure to come back again for more!
financial is very important if you want to succed in business.*;”
[...] You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development) [...]
Glad to see the recognition that not all projects yield direct, positive financial returns, and that these would not fit the model.
It’s also a relatively large assumption that Agile (let’s assume Scrum, but we could use Lean as well) would work more effectively than an Iterative Waterfall approach. So much depends upon the effectiveness of the teams, the quality of the respective planning and associated risk tolerance.
Regarding priorities, if risk exposure to lack of PCI compliance or bolstered security needs are acute, these could easily take precedence over other requirements showing considerable ROI on £’s, using a financial model exclusively. This would be the case even though regulatory compliance or security issues could, at best, be framed as ‘soft’ financial savings (no hard ROI compared to incremental top line sales growth for example).