When shopping around for vendors for a software development project, clients that are not familiar with agile methodologies want a figure to assign to their budget or have a specific figure themselves that came from a previously defined budget. These numbers often come way before any detailed requirements have been documented and most certainly those requirements will change as the project moves along.
In the past, we have written about the benefits of the time and materials pricing model but I´d like to go a bit deeper into the topic of budgeting and estimation.
Without a pruned product backlog and a working team with a known sprint velocity, it is hard to give a realistic estimate of the project and therefore offer a base price to the client that assumes no changes will be made (which is unrealistic). However, a baseline is determined during Sprint Zero which helps us to have a rough understanding of the project´s needs regarding team size and duration.
Usually, there are several companies bidding for the given project that either chooses to ignore these issues or just don’t have the experience to know them so they offer a fixed bid. Clients tend to give great weight to the sticker price variable during the partner selection process. This path tends to be dangerous for the client as the total cost of ownership of a software project contains additional variables aside from price. Best case scenario, the clients will get what they asked for which might be very different than to get what they really needed.
It is understandable that the client´s stakeholders need some numbers to have an idea of the cost of their investment in order to know if it’s worth following or not.
Since a detailed estimation is not recommendable at this stage and, as mentioned previously it would not be realistic due to future changes in requirements, the best way to go is by starting a conversation with the vendor in order to define a core team that has the combined skills to get the project done. With the team size, roles and estimated monthly hours dedicated to the project for each team member set, it is possible to calculate a monthly burn rate budget.
For example. If during the conversation between the client and the vendor they agree that a suitable team size is a Scrum Master dedicated 50% of the time, a junior User experience designer working 30% of the time and a Lead Developer, a Senior Developer, an intermediate developer, an intermediate QA engineer all with 100% dedication then with an average of 165 hours per month and the vendor´s hourly rates we can calculate the monthly burn rate for the team. Let’s say for this example that the burn rate is $X.
Monthly Burn Rate = SUM [ Role n (Dedication percentage* hourly rate * 165) ]
The next step is prioritization. Feature prioritization is key in Agile in order to maximize stakeholder ROI. With a well-prioritized backlog, the stakeholders are able to stop anytime they believe the current software version satisfies their business need while adding enough value. The way we prioritize at Perficient Latin America is by evaluating the value and risk of features. High risk-High value features are done first, Low risk-High value are then done, Low risk-Low value are next and High risk-Low value are avoided altogether.
With this prioritization of features, the client will be able to weigh spending $X(assuming it is a four-week sprint) against the benefit of getting the next set of prioritized features the team estimates can develop during that sprint. If the value those features add to the software is more than $X then the sprint should go on. It the value is lower, then the client is able to make the strategic decision to terminate it at the time.
If the initial budget or timeframe the stakeholders had in their minds runs out but there are additional features that still add value to the software, then more budget or time can be allotted to the project. The stakeholders are then able to roughly predict how many sprints it would take to tackle on an additional set of features with the previous experience acquired during the project (i.e. the team velocity) and with the backlog items’ high-level estimation, thus they would be able to multiply $X per that number to get to an approximate new budget.
One of the most important aspects of building long term relationships with our customers is open and transparent communication. These practices help to increase communication and improve understanding between the team internally as well as with the client not only on a technical scale but from a financial perspective as well.
Want to know more about how to budget for your software development project? Contact us!
—-
About Perficient Latin America: Perficient Latin America specializes in outsourcing and nearshoring Agile software development, software maintenance, quality assurance, and staff augmentation. With offices in Colombia, Mexico, and the US, Perficient Latin America has customers all over Latin and North America, ranging from tech startups to Fortune 500 companies.
