February 3, 2022
Many software founders or aspiring founders want a price quote for the development of a Minimum Viable Product (MVP). However, we need two things before we can properly estimate the time and effort required. We need to understand the problem domain, and we need to find out if users are actually interested in using the new product idea.
After those two early steps, estimating the software development effort is quite simple. It also becomes easy to determine what parts do not need to be developed yet, saving businesses from spending money on the wrong features.
For large products, software estimation is an intensive process to understand, and it takes time to estimate all the features. There are, however, some shortcuts you can take.
First, establish the development stack. Try to keep this similar for most projects that you do. Where possible, also try to maintain the same architecture and use the same patterns to solve comparable problems.
A familiar architecture and development stack, with familiar problems solved by familiar techniques, means the estimation process becomes a bit easier. You can use historic data or knowledge to come up with your own implementation details and tasks.
General infrastructure includes several things: setting up a project, knowing how to handle your exceptions, knowing where to log, and sending emails. Your framework probably takes care of all that.
Set up a source control repository, for which a gated check-in is recommended. You can always allot the same time for this. If your product is mobile-first or if you need internationalization features, make sure that these modules are set up and your team knows how to use them. If you need to send HTML emails, set up your templates, and test them across email clients right away. Make sure your dependency injection is ready to be used both client and server-side.
Suppose you were looking at a “Create Employee Page” feature. You will likely see input fields for the Name and Email Address, and a dropdown list for the State or Country. These are all tasks that should be on your list.
You will then need to set up the controller, service and the models separated between client-side and server-side deliverables. Familiarity with the framework helps here. If you work with Angular on the client-side, and ASP.NET (WebApi) on the server-side, you know your boilerplate tasks: set up a controller, hook up routing and injection, and so on.
Developing reliable software is all about predicting undesirable user and system behavior. Make sure your user gets guided through the process conveniently - even when things go wrong. Large amounts of development time should be spent on this, so schedule the required time in advance.
The fields discovered during our “UX backward” step will need to be validated, and user and system behavior will need to be tested. These tests must be done on both server-side and client-side.
Consider external things that might interrupt your user’s experience:
Few experiences are more frustrating than completing a form, getting an unhelpful error message, and discovering your data is gone.
Your user will not be interested in troubleshooting these problems himself. He only wants to know if his progress on the app is saved and if the issue will be resolved with as little inconvenience as possible.
Estimate all your tasks to last at least 1 hour minimum. Some practices recommend estimating in “story points,” which is based on task difficulty. Our team finds it more practical to schedule in hours, since an hour is a unit of time that anyone can understand.
Imagine you have three containers to put your tasks into: 1 hour, 2 hours or 4 hours. If you think a task will take half an hour, put it in the 1-hour container.
If the task will take 2 hours and 10 minutes, it is considered too big for the 2-hour container and must go into the next largest one: 4 hours. Anything that will take longer than 4 hours should be broken down into smaller tasks that will fit into your containers.
Still, there’s a possibility you have unknowns or tasks you’re not entirely familiar with. In this case, you may want to assign 8 or 16 hours to it to be safe. And if you’re unsure how to split them into smaller tasks, build a quick, rough prototype. This way you can get a slightly accurate plan for what you need to do, and you eliminate risks of being wrong.
Using the next highest container for estimates will also allow you some leeway. Nobody is effective 8 hours a day, and you will also spend some time on communication and troubleshooting.
If you’re worried about your time estimates being too long, you shouldn’t be. No boss or client will complain about you being done earlier than planned. Underpromise and overdeliver.
In most products, there are repeating tasks for various models. For example, you need to estimate a module in a system to Create, Read, Update and Delete (CRUD) an employee, a product, a customer, a supplier, and an order.
Compare the estimated number of hours allotted for the employee page task and the product page task. Chances are they’re very similar. Maybe the employee will take 36 hours and the product will take 40 hours. If you see this trend, you can use it to estimate similar tasks.
Similarly, if your system requires you to have some reports in it, you can estimate 3 similar reports, and use this as a baseline in the next item.
Using familiar patterns comes in handy during the estimation of software development tasks. Perhaps you can write a state pattern of a 4-state solution in 8 hours. Don’t forget to break it down to 2 hours per state.
Now that you have some useful data for estimating similar tasks, you can use the same container system for estimating similar features. In this case, you use a 2-day container, a 3-day container, and a 5-day container.
Some practices allow a 10-day container, but you run the risk of inaccurate estimates. Break these features down into smaller chunks, and avoid using the 10-day container where possible.
In our software development process, we make sure to check-in our source code and deploy it to a development server after a user story (or feature) is completed. The client gets to see the initial results and we build a faster feedback cycle.
Tasks like minification, bundling, and deploying can be automated. If your team is not ready for this, allot time to manually do these tasks before deployment and repeat after every user story or feature. You will also need a recurring schedule for integration testing, cross-browser testing, or testing on multiple phones and OS versions.
Spikes are tasks aimed at answering questions or gathering information, rather than directly creating the product.
Remember that you are not constantly in a sprint, and you will need to take breaks for data-gathering or simply for health. Work in short sprints and short spikes to avoid burnout and decision fatigue.
In case of longer development estimations, estimate your modules in 1, 2, 3, or 6 months. As with other container systems, try to break these down into the lowest possible container before you implement.
Determine an estimated completion time that can be adjusted as you progress. Expect requirements to change after the first version is delivered, or priorities to shift after the first critical bug or error is found.
No matter what, expect that your long-term development estimates will always be a rough idea.
Software development effort estimation can’t be properly done in a top-down approach. Despite the definition of “estimate,” your success depends on your estimate being close to actuality.
Communicate with your client clearly to manage their expectations, but work to deliver your estimate anyway. To do this, ensure that your software development estimations are informed by data, research, and experience.
We speak from experience, that’s why we’ve got your estimations and quotes handled. We provide our services at a fixed price and easy phased payments to help you manage your investment at each phase.
Note: This post was originally published by Alain F. at You_Source.
