Estimating the cost and effort needed to build your software depends directly on the quality of information that you can provide. Before you request an estimate, you should think about how the software should work, how it should interact with users, how it should generate value for you and your customers, and some specific things about the interface.
If you need to see what can influence the cost of software development, read the following article: Price estimate for web and mobile applications
In this article, I want to show you how to prepare yourself for software estimation: what information you should collect before you request a quotation), what documents you should prepare, and how to do it. Here it is:
Preparing for software estimation, step by step
1. Make your provider understand the business you’re trying to build with the software
In order to do that, you need to understand the customer perspective and the user perspective. The customer perspective is about:
- What does the software really do for the customer’s business?
- How does it create value?
- How does it alleviate pain?
One way to build this understanding is by creating a customer persona and defining the value proposition. A customer persona is a fictional character that represents the key traits of a segment of the company’s audience. It’s based on the data that the company’s gathered from user research and web analytics. Value proposition is a statement that summarizes why a customer should use the company’s product. It shows the pains, the gains, and the tasks or jobs that the customer needs to fulfill, and, at the same time, points out how the product relieves their pain, provides gains, and what kind of job it supports, performs, or automates.
At the same time, you need to keep in mind that your users and your customers don’t always have the same goals. For instance: the goal for your company may be to increase sales. But the goal for the agent at your call center is to make the biggest bonus. It’s important to understand the difference because it will affect the whole customer experience – from the moment the users get to know your product to the moment they pay for it, and when they recognize the value it created.
The first things you need to deliver are the customer persona, value proposition, and then user persona. You need to know what each user has to do with the problem, what their pains, gains, and jobs are. And, finally, your response to that in the matter of relieving pains, providing gains, delivering value, and the jobs that you support or do for the users.
2. Understand how your product solves the problem
The question is about the kind of specific user stories that are provided by your software – and what the flow between them is.
User stories are short, simple descriptions of a feature told from the perspective of a person who requests the new capability, usually a user or customer of the system. The more detailed they are, the more accurate the estimate will be. They typically follow a simple template:
As a < type of user >, I want < some goal or objective > so that < some reason, benefit, value >.
User stories are extremely helpful for user story mapping when you plan the whole roadmap for your product development.
A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that deliver value to users and business with each release (from Jeff Patton’s The New User Story Backlog Is a Map).
Remember to include the success-failure criteria! It will help you measure the progress and evaluate the work of the service provider.
3. Prepare the wireframes
A software development provider should know the key components of user interface of your product. To make sure it’s clear, you need to prepare wireframes.
Wireframes are simplified outlines of your websites, applications, and other software products. They are used early in the development process to establish the basic structure of a product – way before visual design and content is added. This initial representation of what your app will look like helps you visualize your idea and work on it before committing anything to code. It’s much easier to change the outline that the entire app.
Here are some tools that you can use when preparing your wireframes:
4. Give specific requirements on what your product should really do
When you say “we need a chart showing the number of registered users ”, the estimates of your request are an open question. It’s something that can take as little as 10 hours, but it’s also something that can end up being 200 hours. Building a chart is completely different if you need to update it in real time, if you need to zoom in and zoom out into the chart, if you need to show comparisons of the different timelines, if you need to change the granular data so you collect something every hour, if you want to see the results daily or weekly. These are the aspects that are really important when it comes to charge because they influence the workload.
It is basically the same for most of the components, so make sure that you point out as many details on what your product should actually do as possible.
5. Give information about your competitors
A very good thing to do is to provide information about your competitors.
- Direct competitors – solutions that deliver similar approach to solving the problem (like an application that does pretty much the same but in a different way – with different UI, slightly different functionalities, different UX).
- Indirect competitors – solutions that show a different approach to the same problem.
Point out the alternatives considered by your prospective customers. Remember, though, that your biggest threat is that your customers will keep doing things the way they do. And that they won’t be willing to change that at all. Neither for your product, nor for your competitor’s.
And that’s pretty much it. The most important things to prepare when you want to get a reliable software estimate are:
- customer persona and value proposition for the customer
- customer persona and value proposition for the end user
- user story mapping with user stories
- any specific information on how it should be done.