Understanding cost is critical in every major project. But what if you don't know the scope of all functions, as is often the case with an agile approach?
We recently discussed that one of the features of the Agile approach is precisely that new features can be added during the development process. Of course, this increases the labor time and, accordingly, the project budget.
We understand how important it is to control costs, so we shared examples of how you can plan cost in an Agile system.
List desires and prioritize
Ask the team to provide a list of all functions and projects that they would like to complete within a year or less. The document can be approached informally - it is not necessary to record the requirements here, but it is important to prioritize each task. Use Google docs, Jira, or another familiar scheduling tool for this worksheet.
Discuss each item
The resulting list is very similar to the RoadMap (a roadmap for Agile tasks), at a meeting with the team, we say all the points: each is given no more than 5 minutes for discussion (it is advisable to turn on a timer). During this time, the person who added the task (most often the customer) reveals the essence of the selected functionality. The team then has 10 minutes to ask questions. If there are many features, then the analysis of RoadMap is divided into several meetings with exact timing.
Set a cost range for each item
Over the next few days, high-level documentation is generated for each element on how it can be designed. It is important to consider any risks and assumptions here. For convenience, in the YuSMP Group, we conditionally allocate several ranges:
S: 0-80 hours;
M: 80-200 hours;
L: 200-600 hours;
XL: 600+ hours.
These "packages" of work hours can be anything, depending on the project and the team. The more complex and uncertain the product, the more time we put into work. When the hours are counted, we tell the customer the size of the package.
Estimate the total cost
After each element of the RoadMap has been worked out, the team meets again. We again go through all the points, discussing in detail how this or that task will be implemented. At the meeting, all participants work closely together to eliminate various kinds of misunderstandings and confusion.
After this discussion, owners or their proxies see the potential costs associated with each item. The visibility of the tool helps to adjust the priorities: often after the review, customers abandon some points in favor of more important features. If the functionality remains unclear and it takes more time to figure it out (for example, in a complex integration), we designate the range of hours for its implementation.
The key to success
A key ingredient in Agile budgeting is that all parties understand that these estimates are by no means binding and that costs will change when the project starts. But such an algorithm gives an objective idea of the cost of the product, which means that costs will be easier to control.