Guide to Software Project Estimation. Project Estimation Process
In my last article on time estimation, I’ve shown some of the main techniques, methods and tricks you can use during the development process to successfully plan your team’s work. I’ve outlined the main reasons for project estimation errors and stressed why software project estimation is one of the most important processes in project development. I’ve also promised you a follow-up on the topic, so here we go.
This time I will be focusing more on the actual process of software project estimation. I’ll give you a basic strategy that we at LOVATA follow while working on complex projects, and will describe our approach to project estimation. I will go over every stage of estimation from preparation to evaluating the end result, analyzing what you have achieved and whether your estimate of the project was accurate. This will give you a more thorough understanding of what actually goes into a typical project estimation process.
Software Project Estimation Process
The process of project estimation is not just another minor task you do only once during development and then forget about it. It is a whole process, with multiple stages that entail project production from start to finish in an Agile environment. Below are the main stages of project time estimation:
- Actual Estimation;
- Estimation During Development;
All of them are interconnected throughout production and drive development in the right direction. By making accurate estimations, whether it’s a preliminary stage of preparation or current estimations for specific tasks during the development process, you will be on the right track to delivering the end solution on time and within budget. Let’s take a look at these stages in more detail, so you can have a thorough understanding of what each of them encompasses.
Yes, you are not mistaken: you do have to actually prepare for project estimation. It might sound like a stereotype. However, if you think of it, many issues could be avoided if you carefully prepare yourself for the estimation process. This particularly applies to setting up deadlines, but could also affect other development processes.
Estimation is part of development and usually comes after a detailed research of the problem to be solved and a comprehensive business analysis. Then the project is documented in the Product Backlog through epics and user stories and passed on to project managers and developers. The Product Backlog consists of the actual functionalities that have to be implemented in the current iteration of the development process.
Part of preparing for project estimation is studying and analyzing the Product Backlog. This is vital for a lead developer to fully understand and have a birds-eye view of the whole solution. I personally recommend you to take this part of the estimation process very seriously. Having a detailed Product Backlog at hand is a great advantage because you have the full list of tasks, objectives and probable user’s interactions with the system. So you can actually go through these user stories and ask your business analyst questions, should they arise. A typical Product Backlog looks something like this:
Product Backlog Snippet
The stories could be split into sections like “design”, “front-end”, “back-end”, “QA”, etc., so the process of estimation could also be divided into segments. You can also decompose tasks by pages, layouts, system components or whatever it is you need an estimate for. Basically, you can decompose tasks however is convenient for you and your team.
If you don’t have the opportunity to provide the project with a detailed and comprehensive Product Backlog, then your best move here might be to define the tasks for the first stage of development that you will be working on: the first sprint. Create a detailed list of goals and objectives for the first stage and leave the rest of the project in high-level documentation. The later stages could be worked out in detail during future sprints.
2) Project Estimation
When you have an understanding of what the project is about and the functionality that has to be implemented, it is time to move on to the stage of estimation. This is where you give the actual numbers that represent man-hours that will be spent on developing each task. A couple of important things that I would like to point out here are the following:
- Investigate the problem. Try to eliminate all uncertainties and ask as many questions as you can think of in terms of implementation and the pitfalls your team might face. Additionally, dive into any documentation you need to go through regarding unfamiliar technologies, such as frameworks, libraries, database, cloud computing and other surrounding tech.
- Decompose tasks. Estimating complex tasks can prove to be quite complicated. As I have already mentioned in my previous article, it’s much easier to split tasks into smaller bits and make more accurate project estimations. Even while estimating implementation of a single component, it is much more prudent to split your objective into separate tasks as you might not have a good understanding of how to approach the implementation as a whole. Decomposing tasks can also be done by various parameters, including technologies.
- Include risks. Any type of development always entails some type of risk. It may be an unreliable client that you are working with, the technology you use, one of your team members may fall sick, etc. It is vital to always evaluate the types of risks that go into your particular development process and include them in your project estimation.
Project Estimation Flowchart
I have created my own diagram for project time estimation. It is a little oversimplified, but in most situations I follow it while providing estimates for our projects. Here’s what it looks like:
Project Estimation Flowchart
3) Estimation During Development
Logging Your Time
The most important process of estimating tasks during development is logging time. Without logging time you spent on a particular task, you can’t have an understanding of where you are at in your development process. In this case, performing an estimation is basically pointless as you are not tracking your time and just waiting for the deadline to come.
Another important thing is reevaluating tasks. As soon as you are being assigned a task, you should look at the estimate given for that particular task. Try to understand if the estimate is valid or has it, for instance, been made for your colleague. It may also be a preliminary estimate that was made at the initial stage of communication with the client and is no longer relevant. So be very careful before accepting estimated tasks. If you have found that the task requires to be reevaluated and provided with a fresh estimate, then you should address the matter to the project manager, team lead, or whoever else was responsible for estimating the task.
Analyzing the accuracy of your estimations is also an important part of being a developer or a team lead. You need to have at least some kind of understanding of how well you are doing at project estimation. If you still haven’t done so, ask your project manager or team lead to regularly provide you with feedback on the accuracy of your estimations, and always try to improve your results.
Project Time Estimation Formula
Use the formula I provided in my last article to calculate your overall statistics for project time estimation. If you don’t remember, here it is again:
Why Tasks Multiplied by Time is not Estimation
In most cases, tasks multiplied by time won’t give you an accurate estimate of the time you will require to deliver the solution. This is partly caused by many risks that have to be included in your estimation, and by the fact that project development encompasses much more than just implementing tasks and various components. As I have already stated in my last article, developers, apart from just writing code to implement project features, are also busy with the following:
- Deployment, git;
- Reading documentation;
- Unit testing;
- Coffee breaks, checking mail, socializing, procrastination, etc.
Experience Comes With Practice
The last thing I want to say is that if you are a beginner and only just starting to make software project estimations, when something goes wrong or your project manager is asking you how long will it take to make an estimate and you have no idea, don’t be discouraged. Like any other thing in life, it all comes with practice, and sooner or later, when you will be approaching a project, you will already have a preliminary estimate or an idea of how to decompose a task in the back of your mind. All you’ll have to do is follow the actual project estimation process and the steps I have outlined in this article.
Happy estimation! ;)
About the Author
Aleksandra Shinkevich is a Full Stack (MEAN) developer at LOVATA Software Development Company. As a Lead Developer, she’s involved in the process of estimation and project management. In her free time, she organizes regular local front-end meetups, such as MinskCSS and MinskJS. In September 2017 she was among the organizers of the country’s first English-only front-end conference, CSS-Minsk-JS.