Expertise
Agile Estimation: Quantifiable and Realistic Estimates of Effort and Return
In complex projects with a high degree of uncertainty—such as in a software development project—agile approaches and methods help to minimize the risk of additional costs, delays and failure. Agile approach reduces the risk in projects according to the principle:
"Deliver value as early as possible".
In concrete terms, this means that all project participants should focus on the activities that provide maximum added value (return) with the least possible effort.
In order to focus on the right project activities, the effort and the expected return must be estimated in an agile project. Estimating the effort (but also the return) of a project or activity is a non-trivial task, even more so when an absolute estimate (e.g. in days/hours/costs) is required. This is illustrated by the fact that a large part of software development projects (60-80%) exceed the planned effort or deadlines [2].
With a quantifiable and realistic estimate for effort and return, it is possible to decide on which project activities to focus. Thus, the principle "deliver value as early as possible" can be followed. A return-to-effort ratio can be calculated from the two estimates. The project activities with the best return-to-effort ratio (bang for the buck) can thus be prioritized.
The concept of agile estimation
Agile Estimation is an approach to obtain quantifiable and realistic estimates for the effort and the return of project activities (e.g., developing individual product features of a software application). As human beings we are not very good at estimating things in absolute terms. This is true not only for time and money but also for things like weight or distance. What we are better at is comparing: Object A is heavier than object B. Activity X takes longer than activity Y.
Agile Estimation is based on the ability of humans to estimate things relatively - i.e. comparatively. Project activities are recorded in the form of user stories. User stories define requirements or project goals from the user's perspective. The user perspective helps to estimate the value of a user story for the addressee (e.g. a customer or software user). The effort and return of a user story is always estimated in comparison to other user stories.
To make quantifiable estimates out of this, estimation points are assigned to the ordered User Stories: Value Points for the value and Story Points for the effort. The possible points are numbers from the Fibonacci sequence (1,2,3,5,8,13,...). Using Fibonacci numbers has proven to be particularly useful for relative estimation of user stories. The next larger Fibonacci number is about 60% larger than the previous one.
The following video explains in detail how Agile Estimation works.
Agile Estimation in practice: Estimation Poker
To increase the reliability of the estimates in practice, the user stories are estimated in so-called refinement meetings. Each team member provides an independent estimate. If the estimates differ, they are discussed until the team agrees.
Business teams estimate the value (Value Points) while the implementation or development teams estimate the effort (Story Points). Together, the revenue-to-effort ratio is then calculated and prioritization is negotiated. Sometimes, constraints also determine the final prioritization. For a house, for example, the foundation must be built first before the masonry can be started.
To ensure independence of estimates, the project or development team plays Agile Estimation Poker. Estimation Poker is an agile technique, which is also known as "Planning Poker" or "Scrum Poker". Each team member is given a set of playing cards with Fibonacci numbers. On command, all team members simultaneously show the respective card with the estimated value. Thus, the estimates of the colleagues do not influence one’s opinion.
The Estimation Poker deck also has two special cards: Split and Unknown. The Split card signals that the estimator feels the user story is too big and recommends splitting it into two smaller user stories. The Unknown card signals that a team member is not in a position to provide a reliable estimate—e.g. because the user story is outside the area of competence.
Conclusion
Agile Estimation using Estimation Poker is a proven approach to obtain quantifiable and realistic estimates for effort and output of project activities in an Agile project. Only reliable estimates allow us to prioritize project activities in a way that the principle "deliver value as early as possible" can be followed consistently. This increases the chances of success and diminishes the project risk.