Estimate Your Software Development Effort

Introduction

10 years back a friend of mine described about DRIVING, “it is all about Assumptions and Estimations, nothing else”. First glance we could NOT agree on that.

But few minutes later we were (somewhat) agree on that.Is it normal in our life too (assumptions and estimations)? let us assume about our education, investments and even selection of our spouses 😊

If that is valid for our lives, how can we omit assumptions and estimations when building a software project? In most of the cases we start the analysis of the project with many assumptions, then we raise questions (and clarifications), later we are having discussions and finally reaching to a value as our estimation. Can we have ZERO assumptions during our effort calculation? In Real world we might have few assumptions OR may have many depending on the Requirement Clarity Index (RCI) of business functionalities. 

How / Who / When should we do the estimation

Currently we follow various ways and techniques to define a precise estimation. With that can we derive a perfect report throughout our project?

On the other hand, who has the responsibility to define an estimation? Since, we are all victims 😊 at the end, can we delegate this task to Business Analyst? or Project Manager? or Dev-LEAD? or Dev Team?

Another important question is, when should we finish our estimations in a software project? Is it rolls until GO-LIVE stage in real world ? Let’s go through the article and try to come to a conclusion !

Estimation Approaches

Although there are various techniques to accomplish our target, we could consider the below approaches,

1)     Plain Approach

Through this approach, TWO developers can work together for the estimation. If we can have ONE member outside from the planed development team, it will cover different viewpoints and will lead to a have non-biased estimation. Where we can have 2 estimations, BEST case, and Worst-case values. Then we can come to a middle way with their assumptions and clarifications. It is always better to write-down all the assumptions in a separate section while doing an estimation, where we might forget some while moving on.

2)     Poker Approach

We can have fun and play a game while following this tedious estimation process. First, define main features / user stories (by product owner) and then reserve a time slot for the full team. In the session,

• Pick a single user story, discuss all the questions and analyze
• Select the estimation (value) privately by each stakeholder
• Adjust deviations and agree to a common value

Through this, all members participating in the estimation while improving the understanding of the project. Meanwhile, the responsibility also distributes among the team from the beginning of the project. Experience, skills, and previous exposure of such system blends in this approach. We must also clear assumptions raised by each member and try to keep it minimum.

First Step - Simple approach

Firstly, analyze the project as a business owner, the usage, necessity of it , the basis of the project and critical functionalities of the application. Then divide business functionalities into pieces and integration processes. We should raise our questions upfront and expose our assumptions with the team members, to fine-tune those while alluring their inputs.

Now we can start the estimation.

Simple Calculation

Since we identified business functionalities in the first step, now we can go through each in a detailed manner while considering them as separate business components. This is essentially done by thinking about them independently, coming up with assumptions and then doing the estimation for these components. Rule of thumb, we must have smaller chunks which can be estimated for maximum of 30 hours. (references 1 **)

Is it correct? How can we fine tune

• Go through each business functionality again
• Discuss with team members
• Get viewpoints from outsiders
• Refer previous examples
• Review with senior people
• Break into further smaller chunks
• Discuss with the product owner about assumptions and get the feedback

Table of Estimation

Now we have gone through the business functionality at least twice. With that we have good understanding about the business requirement. (at least we must think so) Then we can add our technical expertise into project estimation.

Please refer below estimation extracted from an actual software project estimation, 

Main features (APP and Portal)

As discussed in Simple calculation we can go through main business functionalities. Then analyze each component thoroughly and define tasks and sub-tasks. Put all technical jargon with clear assumptions. Finally do the estimation and justify it.

Backend

Most of our projects consume data, so we should analyze our end points and define those. Which can be a windows service to a micro service. It should be consumable and should embrace all non-functional requirements when doing the design. The assumptions should be clarified, and estimation should do carefully.

Repository

We should think about data persistence as well as tracking and logging, where we have many ways and technologies for this piece. We should analyze, decide, communicate and get the feedback from stakeholders while doing our estimations.

Integration

Generally, A software project has many integrations with other systems. So, it is necessary to have all endpoints covered during the estimation process. We should carefully go through all aspects of modules and have a clear understanding with project owner. We must judge the accessibility, compatibility and permission while doing the estimation.

Project Delivery

Each project has its own velocity. We always have meetings, clarification calls and discussions on each functionality. Shouldn’t we calculate and add into our estimation?

Another critical piece of a software project is the infrastructure. When doing the estimations, we should evaluate and count that in development space as well as Deployment space.

Unit test is also an important functionality when project is evolving. It will make modules testable and accurate. It is worth to invest and include them into the estimate.

Another important thing is the code quality. Most of the time we follow a dev process and it has particles to fulfill. Code review, peer review and static analysis related changes consume time and we should incorporate those through our estimations.

Non-functional aspects (highly critical)

In modern days, (even though it is called as) non- functional aspects has a huge impact on any project or module. We must analyze and break those into micro pieces before starting estimations. Significant amount of time will be wasted if we neglect this portion in the earlier stages of a project.

Let us segregate the above sections mathematically in a practical example, 

We can see that the MAIN feature development consumes only 55% from the total effort. The REST (Back-end, Repository, Integration, Delivery and Quality) consumes a considerable amount of effort which was NOT highlighted in the first sight.

When we estimate efforts frequently, we can define value percentages for REST section and fine tune the numbers. This is NOT a generic rule, but most of the time it follows a common path. If we can minimize our assumptions while improving our understanding on the scope, we can define a precise value for the proposition. 

Is it accurate now?

We have analysed our business requirement and added technical substance into it. As the first step we make the Business Analyst, Project Manager and Product owner happy with a realistic estimation. Latter we make our Dev team happy with a practical estimation. If both parties are happy, what should we do? Share it with all stakeholders (while mentioning their valuable effort) 😊

Benefits

We have tried to come up with an accurate estimation while minimizing assumptions. Which will,

• Define adequate timelines
• Prioritize deliverables
• Assign and boarding resources on time
• Budget to approve

Summary

While going through about 1200 words in this article, I have tried to discuss,

• Estimation approaches of a software project
• Key sections of an estimation
• Fine tuning our effort with practical example
• Time factor of supporting features VS main features

References

1.     https://stormotion.io/blog/how-to-estimate-software-development-time-accurately/ (*)

2.     https://www.ascendle.com/insight/blog/a-step-by-step-guide-to-software-estimating-free-software-development-estimate-template/

3.     https://www.scnsoft.com/blog/software-development-time

4.     https://dev.to/artemkobilinskiy/how-to-estimate-software-development-project-330b

5.     https://www.binaryfolks.com/blog/how-to-estimate-software-development-time

6.     https://hackernoon.com/barriers-to-effective-software-effort-estimation-and-how-to-avoid-them-4abd39f09f26

7.     https://www.hexacta.com/10-useful-tips-for-software-project-estimation/

Images

1.     https://www.rmagroup.net/blog/think-you-can-text-or-talk-while-driving-your-brain-probably-disagrees/ (**)