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.

Agile project teams are cross functional. What this means is that Agile teams are comprised of Analysts, Developers, Testers etc.

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

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?.

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.

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.

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.

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.

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!