How we come through estimation process in Freeze Pro. All about stages, benefits and common pitfalls


Technical Articles
Oleg Mykhaylovych
12 February 2016
1252

Software development effort estimation is inevitable and sensitive process, which is necessary to meet eventually for everyone. This issue is painful for managers, clients, and for all employees. So is it possible to make estimates development process easier? Which kind of problems may appear and at what project stages? How to face and prevent them? Today, our manager Yuri Savanecky tells about practicing all these issues in Freeze Pro Software. Estimates basis

The estimate is very important factor in planning and development. While many of us do not like to give them, it is simply a MUST HAVE. First, it is important for the client, so he/she can calculate a budget and confirm the readiness. Estimates are also needed for the executive company, to assess its own strength and to gather the appropriate team. Yuri also believes that estimates allow predicting some problem issues, which does make much sense.

“Our estimates often based on experience, expert opinion or previous projects. We are able to check the database, where similar projects can be found, and similiarly make an approximate schedule.

Also, depending on the project, we can give a parametric estimate. For example, we know that we have done some projects with breakdown structure. Now we face a similar challenge, but the volume is 3 times more. Then we can simply multiply the estimate by 3 and give the consistent result. “

Estimates stages

software development stages

The project manager must always retain control of the development process. Every time, he needs to count whether the team will get all the work done by the deadline. As soon as he notices that something is wrong, he immediately takes necessary actions.

Since the development process is multifaceted and has a number of stages, estimates have to be recalculated and composed during each of them. Yuri identifies 4 estimate stages: presale, zero sprint, iteration (breakdown on tasks) and daily.

Presale

presale software development

When your project goes through the stage of initialization and you discuss the possibility of collaboration with the client, you need to provide him/her with information about how much it will cost and how long it will take.

“At this stage estimate preparation is time-boxed and you have a minimum of information. None of the sides have confidence whether the dialogue will grow into the project. In most cases, you do not have an opportunity to specify the details. In short, this step is the most difficult because you experience a lack of resources and the evaluation should be given roughly accurate.

According to statistics, this estimate is very superficial; it takes a little time, nearly 1 to 5 hours. As a result, we should offer the requirement document for 1-2 pages. The level of accuracy may be about 50%. Thus, in the future, requirements may differ in two times”.

Yuri says that in the beginning the estimate is counted in the days, and later - converted to the currency and rates. Though manager is extremely time-boxed, he tries to make a starting breakdown structure in order to get the maximum of details.

“I divide it into 10 to 15 parts and give an estimate of 3 points: pessimistic, optimistic and most likely. Therefore, it becomes possible understand where uncertainties and problems may appear.

 It is very important to comment estimates because the requirements often can be misunderstood from the perspective of a business user. You must be sure that the client understood these comments correctly. Such approach brings clear understanding for both sides.”

Zero sprint

If everything went well and you have moved from the discussion phase to the phase of cooperation with the customer, you should start to plan project workflow. At this stage, the executor already has more requirements, you know which kind of team you need, and you start to work on prototypes and selected solutions. According to these issues, the estimate becomes more accurate and simple.

“At this point, we develop effort estimation plan for separate release, version or the whole project. It takes more time, but it will not differ more than 15-20%. Generally, there are 2 options for drawing up such estimate. The first one expects us to do time calculations and schedule the deadline. In the second case, a customer brings a specific date, and we define what can be done during this period.

It’s quite important not to forget to include all the possible activities in the calculation. For example, if your project demands trainings for end users, it ырщгдв be automatically mentioned in the estimate. The same with documentation and user guides development. However, these issues may need to be discussed and updated in future, what also takes time. Basically, these little things are often ignored, thus, it causes a lot of problems. “

Iteration

At this stage, we develop the working plan, which has to be performed during the iteration. Most often such estimate is calculated by the whole team. The project divides into tasks that are more detailed and employees give their forecasts for assignments.

“Sometimes we may have no testers at the planning stage. How to calculate an estimate without them? We should use an experience then. Depending on the project, a testing phase may take 30% to 50% time. Thus, we can measure it approximately and include in the overview.”

A current stage goal remains the same - the client understands when to expect to see a release, and the team receives a deadline.

Daily

Daily estimates are the most accurate. They make it possible to react quickly to any changes. They are defined and adjusted directly by each team member. The variation here is nearly 5%.

“It is important to keep track of the team. The manager shouldn’t ignore the psychological aspects. People may not have an ability to meet the deadline, and at the same time, they may be afraid to talk about it. Any task-tracking system helps to solve this issue as it allows you to clearly see how much time is spent and how much is left for certain tasks to be done.”

Common pitfalls

You cannot escape the problems, they happen to everyone. But often they can be considered as a useful aspect because they may appear as the original signal exactly where something goes wrong. While gaining an experience, you learn how to avoid and prevent various troubles.

Yuri highlights the biggest problem in the psychological aspect and the human response. He says that people are often afraid or do not want to provide the estimate. Why? They explain it with a lack of requirements.

“But this is not an indicator because by the end of the project requirements may still be unclear.”

In addition, Yuri mentioned managers as troublemakers. Often they begin inventing their own calculating rules, which is fundamentally wrong and leads to failure.

“I have noticed a specific con of many managers. If someone gives you the estimate, they multiply it into some kind of a coefficient. This is undeniably wrong. Finally, no one believes this information, neither a team nor a manager.”

Another pitfall comes with optimistic predictions, which are usually given by employees. Someone thinks that everything will be fine, thus, the estimate will be too short. Someone may try to catch a tiger by its tail, being afraid to ask for a larger estimate. Sometimes, you can meet pessimistic team members, who used to say that everything goes wrong and everything is done poorly and, consequently, would draw an unimaginable deadlines schedule.

“It is necessary to explain that there is nothing terrible, everyone can make mistakes. Later it becomes easier because you begin to discover your team and anticipate where they may miss something.

I am trying to find out the reasons why a person is not sure about something. In such cases you shouldn’t exclude your formula, you just have to find out why the estimate may increase. I understand that some new features to develop can easily be implemented, and some not. However, it is also essential to include these cases into estimate via describing the above-mentioned optimistic and pessimistic forecasts. We need to be aware of problems at different stages; we need to define them before they will grow into something critical. Risks can be both in a positive way and the estimate may be reduced. It's all about risk management, and that is another topic.”

However, the most critical aspect Yuri considers in the possibility to ground your estimates. You should maintain your prediction properly; provide real facts and arguments based on a plan.

“The client may say that your estimate is too big and he/she believes that it should take up to 3 times less. If you agree, it's the end. Trust instantly decreases, communication becomes poor and no one believes you anymore. It’s the worst nightmare. You need base your estimate on specific arguments and strong reasons. Yes, we may be wrong somewhere, some facts may not be taken into account. In such case, a client may know more and tell us why this should be done 3 times faster. Anyway, you should be always ready to fight for your decisions.”

Conclusions

  • Many people think that if you have a scrum, there’s no need for estimate development. This is a misconception. More experienced people know that it is extremely important and you can’t move anywhere without it.
  • However, there are many pitfalls, which may occur during the planning process. The main one - is the human perception. You shouldn’t think that estimates are created in order to get people the framing effect and keep them at the office after working hours.
  • Estimates are designed to careful planning and project understanding, for the workflow distribution, budget calculation and deadline definition.
  • In any case, eventually, planning becomes easier. After you had enough time to explore the employees, you may predict where a person may go wrong and where everyone goes wrong while starting something new.
Previous
Previous
9 Reasons to Use Xamarin
Next
Next
Project communication: everything you always wanted to know but were afraid to ask