Estimating the cost before the project even starts can always be challenging, regardless of which project methodology you use. However, in an Agile project, you can tie the amount of time the project will take with its total cost.
First, create a burndown chart and use the burndown rate to estimate how many sprints will be in your project and when the project will end. Then, calculate how much the team will cost based on their hourly rates. Multiply each person’s rate by the number of working hours per week, then multiply that by the number of weeks in a sprint. Once you estimate the initial budget for your team, you can add any other costs, like technology, travel, or equipment.
You could also break down each user story into tasks. Once you have an idea of how many hours it will take to complete each task, you can estimate the project budget.
And lastly, you could use planning poker to estimate the effort required for development goals. Planning poker is a consensus-based, gamified technique for estimating the effort of development goals. Each team member makes estimates by playing numbered cards face-down on the table, instead of saying it out loud. The cards are then revealed and the estimates discussed with the whole team.Traditional cost estimations can take a lot of time, and they distract from the development team. There are various approaches that you can take in completing your cost estimations.
Burn Rate Cost Approach
The first approach is to work with your sprint session burn rate and period. Considering the sprint session has a fixed number of time resource units, it can be simple to work out the true cost if the cost of each resource is obtained. Depending on what costs are available to you, the approach can either be:
Average cost per person per hour. This is the simplest approach as you multiply the hours of each resource utilized during the sprint by the average cost you have been supplied. As an example, if you have one part-time resource and one full-time resource at $100 an hour (assuming 8 hours a day), a two week sprint would be (40 hours x $100) + (80 hours x $100) giving you a $12 000 per 2-week sprint cost.
Specific cost per person. This approach would require some additional calculations, where you will need to derive an hourly cost per person based on their annual salary cost. Once you’re down to an hourly rate, the calculation is the same as average cost per hour.
While this budgeting is a straightforward approach, its major challenge or downfall, is that it is heavily dependent on calculating the correct burn-down rate or scoring each agile task accurately. It also requires the tasks to have been estimated before you can turn the sprint cost into a project or solution cost. This only solves one part of the problem.
Another issue is that it doesn’t solve for the additional costs outside of the sprint planning. You will need to extend your costing model to provide for testing hours, administration hours, meeting hours and design hours.
Precision-alignment approach
Another approach is more budget orientated and less estimation orientated, and requires a set of business outcomes that are prioritized.
This practical example is based on an article by Debbie Madden writing for Harvard Business Review. Let’s assume you’re building an online retail shop for clothes. This business requirement can be broken down into a handful of areas that translate to major solution tasks, such as:
A landing page for marketing
A search function
A checkout function
Product pages
A customer knowledgebase
Order management system for customer agents
The next task is to then estimate, based on previous experience or some guidance from developers, what each task would take:
Task Time Budget
Store landing page 2 - 4 weeks $20k - $40k
A search function 4 - 6 weeks $40k - $60k
A checkout function 6 – 8 weeks $60k - $80k
Product pages 3 – 6 weeks $30k - $60k
A customer
knowledgebase 2 – 4 weeks $20k - $40k
Order management
system 4 – 8 weeks $40k - $80k
This gives a first-sweep budget range of $210 000 - $360 000. Despite this wide range, the business can already make a decision if the minimum budget exceeds the resources available for this project, or is way under resources available. If the range is too broad for the business, you continue with the next step.Take all the tasks, and assign a priority to each one, which allows a distinction between ‘must haves’ and ‘optional maybes’:
Task Time Budget Priority
Store landing page 2 - 4 weeks $20k - $40k 5
A search function 4 - 6 weeks $40k - $60k 3
A checkout function 6 – 8 weeks $60k - $80k 2
Product pages 3 – 6 weeks $30k - $60k 1
A customer 2 – 4 weeks $20k - $40k 6
Knowledgebase
Order management 4 – 8 weeks $40k - $80k 4
system
Blend to your environment
Both approaches take different directions but provide useful budgeting information for your agile project. You can combine elements of both approaches depending on how you have implemented agile principles in your organization. For example, if your agile environment is mature and you need to provide mid project sprint costs, the first approach is ideally suited. If your environment is less mature and the project is at an early stage, the second approach might be more suited as it quickly delivers cost approximations at the right stage of the process.
After the budget, comes discipline.
Two things will happen once you enter your project: you will either use fewer resources (time, money, etc.) or you will use more. Either way, daily management of the project and timely updating of your stakeholders is critical.
The situation that needs the most discipline and feedback is when you have detected that the project budget was under provisioned. Many times this is not a simple case of making mistakes during the budgeting process, but rather unexpected obstacles occurring during the project execution such as:
Delays caused by 3rd parties beyond your control
Rework that was unexpected
Resource unavailability, such as illness
External cost shocks, such as currency fluctuations
No comments:
Post a Comment