How to calculate the price of a feature

Backlogs, return on investment and old-school work-breakdown-structures

Software developers tend to forget just how expensive they are. To them, spending two weeks to work on a problem sounds like a reasonable amount of time. Just a quick feature.

But their managers have an ROI in mind. The time spent building a feature needs to be justified financially. The team can spend more on a fancy dashboard that brings in Enterprise-class customers than on nice-to-have functionality. With limited resources, each feature has a financial and an opportunity cost. It costs resources to build the thing, and what gets spent on developing feature A can't be spent on feature B.

In project-driven software development, calculating that ROI is trivial. The scope is structured in a Work-Breakdown-Structure – a hierarchical overview of all the features and their tasks.

Since each of these tasks is estimated in days, the feature costs as much to develop as all of its tasks combined. The price of a day is often a blended rate – an average of the developers' day rates.

While this isn't an exact science – the feature would be cheaper if built by the team's junior dev – it is accurate enough to calculate that ROI and opportunity cost. This is often the ground for discussing Change Requests. We need to sacrifice another similarly priced feature to add a new one mid-project without blowing up the budget.

When the industry switched from Work-Breakdown-Structures to backlogs, calculating the cost of a feature became harder. In theory, we could say that the price of an epic is the sum of its user stories multiplied by the blended rate. But in practice, this is not true. Agile software development invites change. We expect the epics and user stories to change over time. In fact, it's rare if they don't.

With the backlog's priorities changing constantly, we can approximate when a team will start working on an epic but not when they will finish it. For managers, it's impossible to say up front whether the feature will be worth building. They just feel like it all should go faster and cheaper. Just like a team without a schedule feels they are behind schedule all the time, a manager without a budget feels like they're running over budget all the time.

In projects, the cost of a WBS is the total of its tasks. That requires some stability to be manageable. In agile software development, we don't think in cost of scope, but in a team's bandwidth– its steady cost per week.

With Iterative Buffer Planning, there's a nice way of calculating the cost and opportunity cost of a feature.

Since the team has a steady cost per week and Focus Blocks are always in the order of weeks, we can do a similar calculation.

The price of a feature is the number of weeks spent on the focus block plus the following recovery block multiplied by the team's blended rate.

Let's say we have a team of 3 developers that cost us €300K per year. Divided by 52 weeks, each week on the roadmap costs us €5770. If we decide to spend 2 weeks on a feature, followed by a week of recovery, the feature will cost us €17310. Since we decide upfront how much effort we want to spend on a solution, we can decide upfront if the ROI is worth it. Focus blocks allow the team to work on a single problem at a time, so we avoid priority shuffling. We know when they will start and when they will deliver. If two weeks is too expensive, we can build a cheaper solution in a one-week focus block for €11540 or drop the feature altogether.

What often happens is that the stakeholders decide to revisit a focus block. After spending three weeks to build a feature, they decide to improve it by dedicating another two weeks later down the line. This feels similar to adding user stories to an epic, but there’s a crucial difference: it’s an informed choice. Only when stakeholders feel the improvement is worth another €17K will they dedicate more time.

Calculating the cost of roadmap items is a crucial way of building trust with your stakeholders. It gives them a way to understand how their limited resources are allocated.

Without it, software development feels like carte blanche.