Agile Estimation: Relative estimates vs Absolute estimates

Accuracy of Group vs. Individual Estimation

Whether the team is working on a product or a project, we need to answer the question “When will we be done?” Or how far we can go at a certain point in time. Just like traditional development, we need to estimate the effort before we start the project.

What is Project Estimation?

An estimate is a rough calculation of something. For example, project cost estimation is a general concept of project price model. It helps you provide a hopefully more realistic figure when your customers or other project stakeholders ask you to evaluate the cost and time of the project.

Agile vs Traditional Estimation

Traditionally, we allocate time to estimate software projects, while in agile methods, they prefer to provide a story point for a backlog item as a measure of relative work. This allows the team to consider other work they have done in the past and compare it with the product backlog they will estimate. Story points are not measured by giving an absolute time, but by estimating the workload required to solve similar tasks based on past experience.

Agile estimation has the following three characteristics:

1. Team Collective Estimation
2. Relative Effort vs Absolute Time Estimation
3. Estimate Team Velocity

1. Collective estimation

During the development of Scrum, the team shared responsibility and collectively committed to the work of each Sprint, so the estimated workload for the agile team used a collective estimation approach. Collective estimates typically use Planning poker as a tool, the team makes a collective estimate by playing an estimation game. Planning poker is considered to be the most effective and very interesting technique to do workload estimation in Agile. It consists of a set of numbers similar to Fibonacci numbers, including: 0, 0.5, 1, 2, 3, 5, 8, 20, 40, ?, ∞, each deck of poker card has 4 group of such Fibonacci numbers for serving for 4 people use.

The Accuracy of Group vs. Individual Estimation

According to some study on the accuracy of estimation of effort between individual and group in an experiment for a software project. 20 software professionals from the same company individually estimated the work effort required to implement the same software development project. The participants had different background and roles and the software project had previously been implemented. After that, they formed five groups. Each group agreed on one estimation by discussing and combining of the knowledge among them.

Result — The estimates based on group discussions were more accurate than the individual estimates.

Steps for Conducting Planning Poker

1. Each team member gets a set of cards, including 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞, a total of 12 cards.
2. The product owner will either read describe a feature to the team.
3. The team members discuss the feature and, ask the product owner questions if needed.
4. When the members have finished their discussion, they each member select one poker card to represent the estimate. The cards are then revealed simultaneously.
5. If the team evaluates different estimates. Do we agree? Do we have differences? Is there anything I have not considered? Those who chose the highest or lowest value should share their reasoning with the group before each member selects another poker card.
6. After the discussion, you can estimate another round, and the team needs to reach an agreement.
7. Go back to the second step and start estimating the next entry.

2. Relative Effort vs Absolute Time Estimation

An estimate is nothing more than a well educated guess. We use all the knowledge and experience at hand to make a guess about the amount of time it is going to take. So instead of looking at every new work item separately, why not compare it to previously finished work items? It’s easier for humans to relate to similar items than to guess the actual size of things anyway.

For example, is it closer to this really small thing? Or is it more like this normal sized item? Or is it really huge like that one piece of work we finished last month? Doing relative estimates will not only reduce the amount of time spent on estimating work, it will also heavily increase the accuracy of the estimates.

Our brain is not capable of doing absolute estimates; we always put that new thing that we need to estimate in relationship to things we already know.

3. Estimate Velocity — Record and Average the team speed of each Sprint

The team velocity is the number of story points that the Scrum team actually completes in a Sprint. The team velocity tells you how fast the team is doing. A newly estimated project or team (without referencing velocity records in the past), we can do1–2 Sprint to measure a speed as the initial speed. In the Sprint implementation process, we need to record the speed of each Sprint, for future plans.

We estimate the total number of story points for the product Backlog, and then we know the average velocity of each Sprints, then we can figure out how many Sprints we need to finish, and thus the Sprint is expected to be required for the project as shown in the Figure below.