Effort estimation is an essential part of software development. It is important to the developers themselves, but mostly to the project owners who establish and maintain the project schedules in order to ensure cost efficiency. To tackle this challenge, several techniques have been established to arrive at the most accurate estimates for achieving specific tasks within a sprint.
To fully understand these methods, first consider the following points:
- Solid effort estimation entails fully understanding the task on hand - otherwise you won’t be able to come up with an accurate estimate.
- Once everything is clear, it is crucial to split the task into smaller pieces and create a model (i.e. a mental model or mock model). The size and scope of the project will usually determine how much you will go into detail with this model.
At the end of this process, the larger task should have been divided into smaller tasks, each of which describes a certain piece of work that has to be done (such as setting up the DAO layer, creating the REST API, writing unit tests and many more). Arriving at smaller components of the task makes it much easier to estimate individual components rather than estimating the full project which is probably too large for a valid estimation. However, it might still be difficult to come up with good estimates, which is why there are three major approaches  used for advanced effort estimation:
- Expert estimation - some experts have to estimate the tasks
- Formal estimation model - a proper model with useful data must be provided to do the estimations
- Combination-based estimation - this is a mixture of the first two approaches
In this article, we are going to describe some of the expert estimation and formal estimation models.
This is a three-point expert estimation technique and it is commonly used with CPM. You should represent your project as a graphical illustration which consists of nodes. Each node represents an event or milestone in a project. So each of the nodes needs to be estimated and if this is done for all of them you will get the overall time estimation for the project. As you can see in the diagram, some nodes depend on their predecessors. In the following example, node (1) needs to be done at the beginning, after which you can either continue with (2) or (4), but you have to finish either path before you can start with node (5) and only at the end you arrive at the final node (6).
But how are you going to do an estimation of each node? To be able to do so, PERT introduced a mathematical equation which is going to help you.
The variables that are necessary to calculate it are the optimistic time, the most likely time and the pessimistic time. The formula is
The variance formula is
We have to do the calculation for each node of the graph. The overall estimation time is the sum of all the calculated expected values. To get the standard deviation for the whole project, you have to calculate the variance for each node and then take the square root of it.
- PERT + CPM is great to visualize dependencies of the elements on a graph. It gives you a clearer image of the whole.
- Dependencies are better understood and decisions can be made more easily.
- If there are a lot of elements in the graph, this may lead to confusion.
- It's not easily scalable for smaller projects
Planning Poker 
Another common technique is the Planning Poker which is also an expert estimation model. When you talk about a task in the group it is possible that you influence other team members by your estimation if you say it out loud. Therefore, you can choose to use a standard deck of French playing cards to play the Planning Poker game. For example, you can use the cards 1, 5, 10 and King. Each of the cards represents an estimation of how long the task would take. For example, a "1" means that it could take 1 hour, so it is a really short task. A “5” could mean 1 day, and a “10” could mean a few days. The King is a special card and it means that the project is too large and should be split up into smaller pieces for an accurate estimation. However, the actual value of each card may depend on your needs and projects, so it is up to you and your team to determine suitable values for each card.
- At the sprint planning, you should discuss the tasks in the group to resolve all open questions.
- After that, everyone puts his/her card, with his/her guess how long the task would take, on the table and the most common value or an average of all the cards on the table will be used.
- If opinions differ too much, further discussion may be necessary until consensus is accomplished.
- Finding a consensus on a topic will give you an accurate estimation. It's really straightforward and gives project managers and developers a good understanding of the project.
- Despite being based on an expert estimation, the accuracy really depends on how experienced the team is.
- Each task will be owned by just one developer, so the development also depends on his/her personal experience.
Analogy / Comparison 
This is a formal estimation method. As the name already suggests, it draws on projects that already exist to estimate the effort of a future project. The projects need to be comparable in certain aspects, otherwise it does not not really make sense to use similar estimation values. For this approach, you have to consider which attributes and modules a certain project has before you can compare it to another one. But you can only use this approach if the developer has a certain level of experience.
- It's difficult to create accurate estimations when you are not really experienced and may not have done the previous project yourself. And often it isn't that easy to compare two projects because they might differ greatly in some respect.
Wideband Delphi Process 
The Wideband Delphi process is an expert estimation technique and it derives from the Delphi method. It originates from the book "Software Engineering Economics".
- A given project is presented to the software developers through a specification
- After reading the specification, a discussion should be started as to how each developer estimates individual parts of this specification, and how the specification can be splitted up into smaller parts.
- A survey is done where each developer can report their estimates anonymously
- If the estimations vary too much, the developers should discuss the topic in more detail. This process has to continue until a consensus is reached
- It's similar to the Planning Poker but without using playing cards
- It might be difficult to arrive at the same result if you do it with a different group of developers.
- It is also possible that the consensus is inaccurate.
At willhaben.at, estimating efforts of a huge project is achieved as group during the sprint planning - we discuss what the project is all about and how we can divide it into smaller, individual tasks. Hence it is easier to split the tasks within the team. For smaller tasks, each developer does the estimation by him- or herself. It is also up to them which technique they are using, so the developer could either create a small prototype to achieve a good estimate or they could also go with the PERT strategy. If the developer is sufficiently experienced, they can also come up with an effort estimation by just comparing this task to a previously tackled task. Ultimately, however, everything depends on your team size and on how experienced the team members are.
: Effort Estimation for Software Development, http://open-works.org/blogs/effort-estimation-software-development
: PERT Estimation Technique, http://www.tutorialspoint.com/management_concepts/pert_estimation_technique.htm
: Planning Poker, http://www.scrum-institute.org/Effort_Estimations_Planning_Poker.php
: Analogy Cost Estimating, http://acqnotes.com/acqnote/tasks/analogy-cost-estimating
: STOP PROMISING MIRACLES: WIDEBAND DELPHI TEAM ESTIMATION, http://www.projecttimes.com/articles/stop-promising-miracles-wideband-delphi-team-estimation-part-1.html
: Critical Path Method, http://pmstudycircle.com/2014/01/critical-path-method-cpm-in-project-management/