I previously wrote a post entitled Waterfall vs. Agile in which I posted two charts comparing the success rates of both methodologies.
A reader named Mark recently commented and asked a question concerning how to initially estimate the cost of an Agile project. Since it’s a great question, I thought I would share my response with everyone.
The question:
Hi Kimberley, interesting post, thanks. I was wondering, with the charts showing the relative success of Agile and Waterfall, one of the criteria is finishing on budget. What I haven’t been able to work out yet is how to estimate how much an Agile project will cost up front. This seems contrary to the way Agile works, yet if the costs cannot be determined up front, then is it really possible to know if the project was successful from a budgetary perspective?
Hi Mark,
Great question.
Before starting any project, project leaders usually have a budget range in mind. In many cases, a strict budget amount may be allocated to a certain project. One of the team’s goals is to complete the project within the budget constraints. To reach this goal, the team must estimate how much the project will end up costing. They must also stay on top of budget throughout the project to ensure that it never goes over-budget.
While it is never easy to predict project costs right at the beginning, no matter which methodology you use, working in an Agile environment allows teams to have an easier time estimating how long the project will take, especially if they use Scrum. Scrum is one of the most popular Agile methods, in which projects are divided up into Sprints. Scrum teams usually consist of a set amount of team members, and the number team members will most likely remain the same for each sprint.
Agile cost management is simply a direct expression of long your project will take. Therefore, the first thing you should do before estimating your budget is figure out how many Sprints your project will consist of. To do this, create a burndown chart and use the burndown rate to predict how many Sprints there will be and when the project will end.
A few strategies for estimating costs for Agile projects:
– Calculate the initial budget. Start off by calculating how much the team will cost, based on their fixed / hourly rates for one Sprint. Multiply each team member’s rate by their number of working hours per week, then multiply this amount by the number of weeks in a Sprint.
– Then, calculate any costs for additional cost resources such as technology, licenses, equipment, and travel. Usually, these costs are only one-time costs and won’t need to be calculated for each Sprint.
– Once all the stories have been laid out, break them down into tasks. You will have a rough idea of how many man-hours each task will consist of. This will help calculate an estimated project budget.
Estimates are never 100% accurate, so it helps if you consistently stay on top of your project’s budget. Many Agile software come with budget tracking features that allows you to immediately know if your project is about to go over budget, which gives you time to take action and rectify any problems before continuing with the project.
Hope this helps!
-Kimberley
Related blog posts:
Scrum Methodology vs. Agile Methodology
Scrum Development With OneDesk
Agile Adoption Statistics 2012
Hi Kimberley,
Thank you for writing not just a reply to my question but a whole blog post! That is much appreciated. The approach I have taken is very close to yours, so I feel I am on a good path, time will tell, and as it is a new development company providing services so the sprint velocity etc. are still to be ascertained.
Certainly I am a lot more confident about the project running to a better timeline using this approach. I have in the past used a type of hybrid approach with work defined in larger units than a sprint, more like about 1 month of work at a time, and the level of specification varied over the iterations as the developers and I gained a better understanding of what we felt needed to be scoped and what could be left as easy to infer. I look forward to the more rapid feedback cycle of breaking this into smaller chunks again.
Thanks again for replying to my question.
Hi Mark,
Good to hear you’re more confident with this approach – proves that you’re on the right track. Once the velocity is established, you’ll be able to move through project cycles faster and more smoothly. You may even want to work on increasing velocity after awhile as this can help make budgets less costly.
Best of luck, and feel free to reach out to us anytime
Hi Kim
Thanks for this. One question though, why should one still estimate the cost for the subtask when you have already calculated team members rate. I was thinking the team rate should already cover the cost for the subtask. Will appreciate a response.
Hi Kimberly
How does this approach differ from the waterfall model where your scope is defined, and estimate is based on that? A good estimate in waterfall would be breaking down the requirements into smaller pieces and putting the cost against each feature.
The only difference I see is iterative delivery and early feedback, but from cost estimation perspective this is the same for waterfall and agile, it just may be worded differently.