Costing Agile projects: How to cost Agile projects

How to cost Agile projects is a question that comes up frequently, and a perfect question for a blog post. It’s actually very easy but before I get to the heart of the matter I’d like to spend a few paragraphs setting the context of the question.

Costing software projects

With many software project approaches it’s common to have people with different specializations involved on the project for only very limited times. For example, a Business Analysts would be fully committed at the start of the project but their involvement would gradually decrease until they were no longer involved. This is known as a Resource Allocation Model and best way to fully understand it is with a diagram (below).

Costing this type of project is significantly difficult. You first have to model each disciplines’ likely involvement (as a percentage), and multiply that by a daily rate. The daily rate profile will change from day-to-day. To calculate the total cost of the project we calculate the sum of all the daily rates for the duration of that project. There are, of course, multiple assumptions made along the way … What are individuals availability? How long should each specialization be involved for? And, what happens when things don’t go according to plan?

This type of project costing is often done with a complex spreadsheet with many variables.

Costing Agile projects

Costing Agile projects are trivial in comparison … so trivial it feels like cheating. There are two important facts about Agile projects that I need to make clear before I continue.

  1. Agile project teams are cross functional. What this means is that Agile teams are comprised of Analysts, Developers, Testers etc.
  2. Agile teams are dedicated for the duration of the project. At the risk of repeating myself, this means that everyone (Analysts, Developers, Testers etc) are 100% allocated to the project for the entire duration of the project.

Given these two ideas, it should now be obvious how to cost an Agile project. We have static team compositions and the team is dedicated 100% of the time, so there is a fixed cost for the team per day. Which means there is a fixed cost per Sprint. The cost of an Agile project is simple the fixed cost per sprint multiplied by the number of sprints we think the project will take … so easy it can be done on the back of an envelope!

Some interesting implications

There are a couple of interesting implications from this costing model which may not be immediately obvious. Firstly, because all team members are 100% dedicated, Agile software development is not necessarily cheaper although a good Product Owner will make sure that the team delivers business value sooner. Secondly, there’s a more complex question about how to estimate the complete cost of a project.

I don’t have space to explore these last points in any great deal but if you’re interested please leave a comment below and I’ll write a blog post in the near future.

, ,

11 Responses to Costing Agile projects: How to cost Agile projects

  1. Rina Beider December 29, 2011 at 7:37 am #

    Thabk you for your information. Could anybody suggest whether we need to include “Preliminary Cost and Benefit : info in the Agile project charter. What document this information should be included in? If Project Charter is the document that should be signed and approved by the senior management , how they can make a decision without Cost and benefit information?.

    • Kane December 29, 2011 at 4:52 pm #

      Scrum doesn’t talk about a “Project Charter”. So, from a Scrum point of view it doesn’t matter where you put the “Preliminary Cost and Benefit”. Rather than focus on where this information is kept, what is more important is that management have the information they need to make a decision. If they need this information earlier then give it to them earlier.

      All the best,

  2. Joshua Partogi August 13, 2011 at 6:58 pm #

    So basically we can take the planning approach from PMBOK if customer wants a fixed pricing. And we just divide the project span by sprint length then multiply it by the price for each sprint?

    • Kane September 9, 2011 at 3:15 pm #

      Hi Joshua,

      Yes, that’s certainly a viable approach … and it works well with Fixed-Price-Variable-Scope projects. Fixed-Price-Fixed-Scope projects are a lot more difficult (i.e. they have more risk) and I’d therefore caution against FPFS projects. I’ll discuss this topic in my next blog post.

  3. Kenny Grant August 11, 2011 at 3:15 am #

    Looks interesting, would be great to have a more detailed article. Cheers, Kenny

  4. Fabrice Aimetti August 10, 2011 at 3:09 pm #

    Hello Kane,

    I have translated your nice post into French :

    And yes, I would love to know more about the estimation of the complete cost of an Agile Project.


  5. Vin D'Amico August 4, 2011 at 6:06 am #

    Your points are valid. I’ve long advocated that the development team should stay together throughout the project, even in waterfall. The approach demands that everyone have multiple skill sets AND be willing to do whatever it takes to deliver the software.

    Your last point touches on the question of “how many sprints will be needed?”. If the “customer” is willing to let the scope of the project float, the number of sprints can be readily defined. If the customer demands that scope be rigidly controlled, estimates get much tougher. I’d love to read your thoughts on the subject.

  6. Kenneth van Rumste August 3, 2011 at 11:51 pm #


    First of all, thx for giving us good information each time.

    Perhaps, some small extra information on the diagram you used.
    That is a diagram from RUP (Rational Unified Process) and, although it might represent a good overview of some of the people active in a project, cannot be taken as a standard for all agile processes.

    Even for RUP it is only an ‘average’ calculation of involvment so this cannot be taken as a standard for all agile processes. Scrum, Kanban and others even don’t have the four phases (inception, elaboration, construction and transition) so take this into account if you’re going to choose or work in an other process.

    But it does indeed give a good indication of the work involved and time spend in diferent phases of a project.

    • Kane August 4, 2011 at 7:04 pm #

      Hi Kenneth,

      >That is a diagram from RUP (Rational Unified Process)

      Yes, you’re absolutely correct it’s from RUP. I have greatly simplified the whole discussion about staffing a RUP project because I only have limited space and because I didn’t feel that the detail was necessary to make my point. Thank you for point this out, and for your comment!


  1. An overview of Agile Contracts | Scrumology - June 7, 2012

    [...] Part 1 and Part 2. [...]

  2. links for 2011-08-04 | Michael Ong | On9 Systems - August 4, 2011

    [...] How to cost Agile projects — Scrumology Pty Ltd (tags: agile cost practices scrum projectmanagement) [...]

(c) Scrumology Pty Ltd.

%d bloggers like this:
Read previous post:
Algorithms on the hunt for profit

The image below shows an automated trading algorithm called Stop-loss terminator, trying to trip loss triggers and cause a surge...