In traditional approach estimates once done are not revised, but in Agile estimates and plans are revisited in every iteration, which brings it more close to reality.
In traditional approach, the project manager will create a project plan for tasks with all the dependencies mapped out and team members assigned; while in agile it’s a complete team effort, complete team in involved.
Estimating in traditional project management is usually task-based. The project manager, with the help of the team, develops a work breakdown structure (essentially a list of tasks) and then the subject matter experts take a stab at estimating the number of hours each task will take. Estimating in agile project management is typically feature-based, such as "find a flight by source and destination city," are estimated in their entirety.
Traditionally, task-based estimating attempts to forecast an absolute number of hours for a task (or, at best, a range of hours), feature-based estimating is more focused on relative size of features, a sort of "small, medium and large" scale that refrains from attaching an absolute time prediction to each task.
Estimate by Analogy:
Analogous estimating uses a similar past project to estimate the duration or cost of your current project, thus the root of the word: analogy is used when there is limited information regarding your current project, an analogous estimate is considered “top-down” and is generally not as accurate as other estimating techniques.
Considering our same example to paint house:
“How long would it take to paint my house?”
The sitting room seems reasonably simple so we’ll give that an estimate of 2 pts.
The kitchen is the same size but more complex due to the plumbing so we will estimate that at 8 pts.
The drawing room is large, but easy to paint hence will estimate to 5pts.
However, to use this technique, it is necessary for the organization to put in place certain pre-requisites, such as:
1. The organization ought to have executed a number of projects
2. The organization should be keeping meticulous records of past projects
3. The organization must be conducting project post-mortem for every project and causes for variances must be identified using meticulous methods and the actual values validated depending on the causes. Care must be taken to prevent erroneous data to influence future projects.
4. The organization should have a well-organized and maintained knowledge repository from which it is feasible to locate similar past projects and extract the validated project data.
Merits of Analogy based Estimation:
1. It is based on actual values achieved within the organization in an earlier project and hence are more reliable than other methods of estimation
2. Easy to learn and very quick to come out with a good estimate
3. This technique facilitates the use of organizational expertise and experience to be brought forth for the current project like no other technique of software estimation.
Wideband Delphi Estimation Method:
The Wideband Delphi estimation method can be summarized as:
Select a team of experts and provide each with a description of the problem to be estimated. Ask each expert to provide an estimate (often anonymously) of the effort, including a breakdown of the problem into a list of tasks and an effort estimate for each task. The experts then collaborate, revising their estimates iteratively, until a consensus has been reached. WD helps to build a complete task list or work breakdown structure for major tasks because each participant will think of tasks. The consensus approach helps eliminate bias in estimates produced by self-proclaimed experts, inexperienced estimators or influential individuals who have hidden agendas or divergent objectives.
When planning a Wideband Delphi session, the problem is defined and the participants selected. The kick-off meeting gets all estimators focused on the problem. Each participant then individually prepares initial task lists and estimates. During the estimation meeting, several cycles lead to a more comprehensive task list and a revised set of estimates. The information is then consolidated offline and the team reviews the estimation results. When the exit criteria are satisfied, the session is completed. One nice aspect of this method is that after an initial stage, the estimates can be refined at each phase (or even at each iteration).
The process can be faster if the same estimators are available, starting where they left at the previous estimation cycle. More information about the problem is available, some assumptions have been modified and an architecture is in place to help break down the effort.