Sometimes, that’s the first thing stakeholders want to know.
They ask it even before they have any idea of what the software product really is… or what it’s going to be.
And it’s an extremely important question. I get it.
But what, exactly, is “it”?
Are we talking a huge, packaged enterprise version of your software with all the bells and whistles?
Are we talking about version 1.0, which should be your minimum viable product (MVP)?
Are we talking about future upgrades, maintenance, and support?
Each of these different points in time will give you a different answer when you ask, “How much will it cost?” But whichever version you’re talking about, the accuracy of your costs will always boil down to one thing: planning.
Starting with the MVP
Why start planning with something as scaled down as a minimum viable product? Because that’s the one thing you can know up front. This is the one version that’s based on what you think your commercial software product should be – based on your research and input from potential customers, of course.
Your actual MVP is always much smaller than imagined at the outset, too. According to Eric Ries, who popularized the phrase “minimum viable product,” your MVP should be about 1/8th the size you expect it to be, on average.
This is your initial cost to market. It’s the investment you need to make in your commercial software development before expecting any kind of return. There’s no guarantee, of course, that proceeds from your MVP will fund the remainder of your project – or even come close to it – but it’s an excellent starting point when it comes to understanding your costs, as well as understanding what your customers actually want.
After the launch of your MVP, what’s next becomes much harder to predict. That’s because the features you’ll be packing into subsequent production sprints should be based on the actual feedback and needs of paying customers, not on what you assume those customers would want.
Accuracy is in the Estimate
There are two reasons most software cost estimates go astray.
First is that the work itself is not broken into small enough increments. A Scrum product backlog and the way it splits user stories can solve this.
Let’s say you need a very complex feature built into your commercial software. You know all the technologies involved and the basic programming needs to pull it off. But for all that, your estimate is little more than a guess. You haven’t drilled down into the smaller details where most of the complexity is buried.
Large stories like these are called epics. In our blog post Splitting Epics and User Stories, I explain how epics can be divided up into multiple, much smaller user stories. And then those stories are prioritized in the planning of your Scrum production sprints.
The advantage of this process in estimating is that it breaks software features down into pieces of actual work. Each of those pieces can be estimated with a much higher degree of accuracy. By adding up the pieces, you get a sense of how long producing that epic feature will really take, as opposed to the original method of guesswork.
The other reason why Scrum produces more accurate estimates has to do with who is preparing those estimates. In many software development organizations, timetables and workload estimates are “handed down” from management. But in Scrum, the estimates for user stories come from the actual team doing the work. They, of course, are in much better position to judge the size of each story.
How to Estimate Software Work
So how can you help your engineers produce such accurate estimates? Ascendle offers two free resources that show you exactly how:
- Our downloadable Software Development Estimate Template
- Our webinar on Agile Estimating and Planning with User Stories
These resources give you a detailed roadmap on how to estimate software work for any project. They also reveal how to assign story points to user stories, how to discover your software development team’s velocity, and how to use that velocity to determine the likely number of story points that will go into each sprint.
Using processes like these will give you more reliable time ranges, which you can then translate into costs, based on the weekly cost of your team. They even take into account the efficiency gains your team will naturally acquire with experience over the course of a project.
This all works when you know which features are being built into a product… like your MVP and subsequent releases, for example. But what about your “end vision”? How do you attach a figure to something as nebulous as that? And how do you build these long-term costs into an operating budget?
There are two ways you could estimate your long-term project costs. You could either take a project-based or a time-based approach.
Whole Project Estimating
Here you pick which stories you expect to be included in the “final” product and estimate those. This is similar to the way in which most software projects are estimated with high degrees of inaccuracy, of course. But you can get much closer to the mark by considering the stories to be included… and by letting your team make those estimates instead of your managers. At the end of the day, this gives you a “ballpark figure” that is at least more reliable than the typical “top-down” method of creating estimates.
If you have the time for your team to work on the project for four or more sprints, you’ll be able to get to a level of accuracy of about +/- 10%.
Time-based Project Estimating
A better way to approach the cost of software development is to determine the monthly cost of the resources in use.
You can estimate your MVP normally, but beyond that, define your costs as month-to-month. You already know the monthly cost of your core software development team, so you just need to add the cost of additional people and physical resources you anticipate using.
Build six months to a year of those costs into your budget, and simply let your software development team follow the priorities to build the best commercial software possible.
An Example: How Ascendle Estimates Software Project Costs
At Ascendle, we use a time-based approach to estimate software project costs, but we tighten our estimates with all of the tools described above. You could summarize our general process in three steps:
- Structure a balanced cross-functional team and estimate their cost per week
- Calculate time range estimates from user stories, story points, and development team velocity
- Multiply the time range by the weekly cost to get an over and under
But What Does a “Normal” Project Cost?
Let me just say this: there are no “normal” projects. Every project is unique – just like every software development team is unique.
But that doesn’t stop anyone from asking. And it certainly doesn’t stop companies from wanting to know.
In my experience, the first marketable version of a solid commercial app will cost somewhere between $300,000 and $750,000. Over its lifetime, depending on the level of support and feature upgrades, that same app will have a total cost of anywhere from $750,000 to $5 million or more.
I explain these costs and what goes into them in more detail here. Your own commercial software application could be smaller than these norms – or even more ambitious. Either way, accurately estimating your costs during planning is a key factor towards overall success.
And while all this may sound great, some of you reading this article may have no idea how to do this, or how to get started. That’s okay. That’s why we’re here — to help you conceive, design, build, and get your app to market. You can call us at 603-369-6325. Or, fill this out and an Ascendle software expert will get in touch shortly.
