This article is part of my online newsletter called the Scrum Addendum. If you enjoyed this article you should signup for the complete series.
How to cost Agile projects is a question that comes up frequently, and a perfect question for an email course. 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.
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.