What is Agile Estimation

What is Agile Estimation?

6-7 minutes

Whether the team is developing a product or developing a project, we all need to answer “When will we be able to complete it?”, or to what extent we can do it at a certain point in time, so like the traditional development model, we need to estimate the amount of work before we start the project.

Agile estimation has the following three characteristics:

Team 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 use da collective estimation approach. Collective estimates typically use Planning poker as a tool, the team makes a collective estimation 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

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.
The product owner will either read describe a feature to the team.
The team members discuss the feature and, ask the product owner questions if needed.
When the members have finished their discussion, they each member select one poker card to represent the estimate. The cards are then revealed simultaneously.
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.
After the discussion, you can estimate another round, and the team needs to reach an agreement.
Go back to the second step and start estimating the next entry.

Estimate size, not estimate time period, use relative estimates instead of absolute estimates

An estimation 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.

Story Point Estimation

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 complete sin 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.