Validating the estimation by a developer

What will you do when you are in a situation to validate the estimate given by someone else? Have you ever faced this? We have compiled few best practices for you which will help you to tackle this situation.

When estimation term comes three important aspects need to be considered:

SIZE – EFFORT – DURATION

To calculate the estimate, it’s always advisable to know all the above factors.

Let us see what are these.

Size

The traditional Functional point is very much in use to determine the size of the project. Or many projects prefer it to be in Small- Medium and large depending upon the complexity of the work. In agile methodology we measure the size of the task in Story Point. The captain of the ship or the manager needs to understand this and needs to be comfortable with the size of his project. The team members are directly connected with the size and complexity of the task.

Effort

In terms of how many resources are required, we calculate the effort. The managers are interested to estimate the work to be done in terms of man hours, man days or in months.

Duration

The stakeholders are interested in this figure. They want to know the deliverable date. This will help them to foresee and give the next set of assignment for the business.

But there are many instances where one of the factors are not very clear at starting of the work. Estimation becomes a need to monitor and manage the project. It helps in cost management.

When do you need to validate the estimation

Here is a typical situation in an IT project where as a manager or as a business Analyst or as a senior project member you would need to validate the effort estimate given by someone else. It could be you had some doubt in estimation and you took help from the tech lead or a developer. We cannot have some vague estimate just for namesake. That will only result into effort slippage and schedule slippage. This will definitely have worse impact on the business. And hence the validation of the estimate given by someone else is always required. And this exercise is worth the result.

Why would you need to get it validated? When you can do the estimate yourself. This will save the cost of validation? Isn’t it? To answer these questions There could be multiple factors to this few of them could be:

• You might have limited knowledge to the technical aspects of the requirement
• You might be involved in other works. And hence you cannot estimate yourself. Delegation of effort estimation is the only option left for you.
• You are a new member to the team, and don’t know much on the details and the complexity involved of the work items.

Now how would you go about it.

How do you validate the estimation

If you have past experience of similar kind of work, you can use it conveniently and compare with the estimate given by the team member. You can break down the work into atomic workable items. In this situation slight variation to the estimate will be there as no two situations are same. And there are many factors which create the situations unique. factors like environments, resources, both in terms of person or hardware-software and of course network. If the two efforts match easily then take the mean of the same and go ahead with that, say you give 30-person hours and the estimate given by the team member is 32-person hours. You can easily choose 31-person hours for that work item.

However, this is not the case always. For some reason if you don’t have your justifiable estimate handy or the two efforts are not aligned then you can go by ‘Wideband Delphi Technique’. This is a very reasonable approach and it is always recommended when it comes to rescue the manager.

In this method you can assign two or more different team members to come up with their individual effort estimate. Now if the estimates given by the team members are similar you can take the mean of the effort estimates. But let us say they have high variation of more than 10% in their estimates, then you can ask them to sit together and come up with an agreed estimation. When the people sit together and work out its likely that they’ll understand the other person’s point of view. It could have happened that few of the factors have been overlooked by one person or may be not so relevant issue for the work has been over considered. They might take few revisions for the estimate. This revision exercise helps to get a common estimate which is more likely to be correct.

Here comes another situation where the work to be done is absolutely new to the team in terms of concept, technology, performance and real time application. This also needs a few answers to its feasibility. Whether the software development for the requirement has potential to bring values in terms of money or may be future ideas. In this case you need to have something called POC (proof of concept). This requires a lot of research and review. Though this does not mean it will always result into a deliverable. You can create a small team for the PoC. The initial efforts of the team member who gave the estimate will be the baseline. The team needs extensive brainstorming and get a detailed sketch of WBS (Work Breakdown Structure). Which is nothing but the requirement or the work broken into elementary tasks.

To validate the estimate always keep a checklist handy. Even if you are not confident on the technology to be used, or not have relevant domain knowledge, you can ask few related questions to the team member.

1) Whether the requirement is clearly understood.

2) Walkthrough the WBS. Verify on the level of granularity of the work items.

3) Each tasks of the work should not be estimated more than 2 -3-person days. You can check with the programmer what items can be worked in parallel or in serial?

4) Verify if the limitations are also considered while estimating. Limitations of software/ hardware, network configurations, skill set and so on.

5) Whether the documentation has been a part of estimation. There is absolutely no project which works on zero documentation. Even in agile framework where only few documents need to be updated.

6) How much percentage of the effort is given for the testing. Ideally it should be 40% of the total effort. Although it depends on the complexity of the work.

7) There should always be a buffer time allocated after the base estimation has been arrived. May be 5-10% of the same. This is to accommodate the unforeseen issues which might come up during the project execution.

8) When giving the schedule estimate, always validate against your team members leave plans and holiday plans.

About Techcanvass

Techcanvass offers IT certification courses for professionals. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.
We have a Business analyst training course with domain training in-built into it. This training program offers you the opportunity to get certified with ECBA certification as well as have banking domain understanding.