We are often requested to quote for a Minimum Viable Product (MVP), however before we actually have an idea on how long it takes, we need to understand the problem domain. We also recommend to find out if your users are actually happy to use your new idea using the UX Sprint. Once you get this far, it becomes easier to estimate the effort it will take to actually implement your product. Also it helps you determine what parts you do not need to develop, and can save you money from developing the wrong features.

For large products software estimation is an intensive process to understand and estimate for all the features but there are some shortcuts you can take. Here’s how we do this:

Work with a proven & familiar architecture, development stack, techniques and patterns.
For the projects that we get we first establish the development stack, and for most projects that we do we try to keep this similar. Also, where possible we try to keep the architecture the same, and use the same patterns to solve comparable problems. A familiar architecture with a familiar development stack with familiar problems and familiar techniques, the estimation process becomes a bit easier. You can use historic data (or your knowledge) to come up with implementation details and tasks.

Setting up your source control, skeleton project and basic infrastructure.
Setting up a project, knowing how to handle your exceptions, where to log and sending emails is all general infrastructure. Your framework probably takes care of all that. Setting up a source control repository, and we would always recommend a gated check-in. You can always allot the same time for this. If your product is mobile first, or you need internationalization features, make sure that these modules are setup and you and your team know how to use them. If you need to send HTML emails, setup your templates and test them cross email client right away. Also make sure your dependency injection is ready to be used both client and server side.

Work from your UX backwards

We work from the UX design backwards. If you look at (an imaginary) create employee page, you will see the input fields for the Name and Email Address, and it is likely that you have a dropdown for the State. These are all tasks that should be on your list. Making up the page itself is obviously a task, however this is generally boilerplate code that is quick to implement. You do need to setup the controller, service and the models. Separate between client- and server side deliverables. Here the familiarity with the framework helps. If you work with Angular on the client side, and ASP.NET (WebApi) on the server side – You know your boilerplate tasks. Setup a controller, hook up routing and injection, etc.

Find things that can go wrong.
Developing reliable software is all about predicting undesirable user and system behavior, and making sure that your user gets guided through the process conveniently, even when things go wrong. This is where a large portion of development time is spent, so make sure to schedule for this.

Going back to the fields we discovered using our UX backward approach – all these fields need to be validated – and most likely both server side, and client side. All this behavior also needs to be tested. Both client side and server side. Then, even when all the fields are validated – it could be that the internet connection is not working at the time the user sends the data. How to deal with that? Or the connection between your server side application and the database does not work? Your user is not interested in that – he just wants to make sure his hard work is saved. Few experiences are more frustrating than completing a form, getting a cryptic error message and all your data is gone.

Estimate your tasks in 1, 2 or 4 hours.
Any task on your list will take at least 1 hour – you don’t estimate less than that. Some practices dictate to estimate in story points, but practically we have found out that scheduling in hours works best for us. An hour is a unit of time that everyone can relate to. You could in a later stage consider them story points if your estimates are off.

Imagine your estimates as a container system. If you think a task takes half an hour, you put it in the 1 hour container. If it takes 2 hours and 10 minutes, it goes to the next higher container: 4 hours. Anything larger than 4 hours needs to be broken down in smaller tasks.

If you have unknowns and want to assign 8 or 16 hours to it, do your research first – you probably can split these in to more manageable small tasks. If you are still not sure, build a quick & dirty prototype. This way you both get an accurate plan on what you need to do, and you eliminate risks of being wrong.
Using the next higher container your estimates cater for some leeway. Nobody is effective 8 hours a day, and you will probably also still have some communication overheads. You think your estimate will be too high because of this? Don’t worry, we have never had a complaint when we were done early., Impress your client or boss by over-delivering!

Look for comparable features.
In most products there is some form of repeating tasks for various models. For example if you need to estimate a module in a system to Create, Read, Update and Delete (CRUD) employee, CRUD product, CRUD customer, CRUD suppliers and CRUD orders. When you compare the number of hours on the detailed task list of the employee and product page, you will notice that the estimates will be very similar. Maybe the employee is 36 hours and product is 40 hours. Not very far apart. If you see this trend you can use it for estimating similar tasks. Similarly, if your system requires to have some reports in it, you can estimate 3 similar reports, and use this as a baseline in the next item.

Estimating development tasks is the part where using familiar patterns comes in handy – 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.

Estimate features in 2, 3 or 5 days.
Now that we have some data that we can use to estimate the product we will use the same container system for estimating similar features. Some practices dictate you should also have a 10 day container, however you may be too far off in my opinion. My advice would be to avoid using this container where possible, break them down in smaller chunks.

Don’t forget to add recurring tasks
In our software development process we make sure to check-in our source code, and deploy to a development server after a user story (or feature) is completed. This allows the client to see the initial results and it caters for a fast feedback cycle. We generally automate the tasks of minification, bundling, and deploying but if your team is not ready for this – it is work that should be done before deployment, and should be repeated after every user story or feature. Depending on your strategy – after the user story is integrated, don’t forget integration testing, cross browser testing, or testing the software on multiple phones and different OS versions – and the consequences of the defects you find.

Don’t forget to add your spikes!
Once you have your development effort sorted using this approach – don’t forget that you are not constantly in a sprint. Work in short sprints and short spikes to avoid burn-outs, decision fatigue and set a proper routine.

I need to estimate a product that will probably take months or years to develop?
To have an unrealistic planning on software completion you could estimate your modules in 1, 2, 3 or 6 months; however you should obviously break these down back to the lowest containers before you start implementing. It can be a helpful strategy to determine an estimated completion time – just make sure you adjust this as time progresses. I don’t believe in this as requirements change as soon as the first version is delivered, and priority shifts as soon as the first critical bug found. It could be helpful to have a very rough indication of the day the initial idea is completed.

Final thought
My take on software development effort estimation is that it can’t be properly estimated in a top down approach. Granted, it should be an estimate, but an estimate should be close. (Good) books that I actually learned a lot of other things from dictate you have to make sure that your client understand it is an estimate, not a commitment. Sure, but an indicative price can’t double. I have seen people estimate a feature as 3 weeks without having any data to back this up. I know I would not accept this if I would pay for an engineering job. How do you know it takes 3 weeks to do without having a good idea what you need to do for it? I am interested in finding out how you estimate software development effort.

‍

‍

‍