How Much Is This Project Going to Cost?

Unlike Waterfall where the total effort is estimated up front, Scrum projects run in short sprint cycles, making time and cost estimation challenging at the onset.

But the management understandably wants to know how much the project is going to cost. How exactly do you tackle this question when working in a Scrum environment?

Here’s a methodical way to approach this:

First, ask the management to fund a small trial (lasting say two to five two-week sprints) to build a few basic product features. The goal, in this limited time, is to measure the team’s velocity (the work speed, measured in story points).

At the end of this trial, we know the average velocity of the team. Let’s say it turns out to be 30 story points per sprint.

Next comes the most crucial part: working with the stakeholders to identify what will be the defining features of the product. The ones that absolutely can’t be left off. Be very selective in this process. Remember that a very small number of features usually dictate the success of any application. For example, in Microsoft Word, the ability to apply basic formatting to text is way more important than writing or executing macro scripts.

Once the core feature set is identified and added to the product log, it is time to break them into user stories and assess the effort in the form of story points. Let’s say the total story points from all user stories sum up to 602. We now have a baseline estimate of 20 sprints (total story points­, 602, divided by the average velocity, 30), or 10 months to build the product.

Now, turning 20 sprints into the dollar figure is simple arithmetic. For example, if the team’s combined salary for a two-week sprint is $67,000, our estimated total budget for the entire project would be $67,000 x 20 sprints = $1,340,000 plus capital expenses such as hardware, software, and services. The calculation in this example is done for a single development team, but the same approach applies for multiple teams in a scaled Scrum environment.

So, how accurate is this estimate? It is good enough for the management to take the call, with the understanding that the estimate will continue to get refined as the development progresses and more velocity data are accumulated.

Nonetheless, having an estimated total budget at the initial stage of the project serves a valuable purpose for the management and stakeholders. If the estimate is under budget, they know there’s room to add more features. However, if the estimate exceeds the budget, they may decide to increase the budget, reduce the number of features, or cancel the initiative. The decision is theirs and we, as Scrum practitioners, owe to our stakeholders and to each other complete transparency in how we estimate and execute work.