What is Agile Estimation?

Whether a team is developing a product or a project, we need to answer: “When can we complete it?” or “To what extent can we deliver it by a certain time?” Just like in traditional development models, we need to estimate the workload before starting a project.

Agile estimation has the following three characteristics:

Team Collaborative Estimation

In Scrum development, the team shares responsibility and collectively works toward each Sprint. Therefore, Agile teams use collaborative estimation techniques to estimate workload. Collaborative estimation typically uses Planning Poker as a tool, where the team plays an estimation game collectively. Planning Poker is considered one of the most effective and engaging techniques for estimating effort in Agile development. It consists of a set of Fibonacci-like numbers: 0, 0.5, 1, 2, 3, 5, 8, 20, 40, ?, ∞. Each deck includes four sets of these Fibonacci numbers, designed for use by up to four team members.

Accuracy of Group vs. Individual Estimation

A study on effort estimation accuracy between individuals and groups in a software project experiment revealed that 20 software professionals from the same company separately estimated the effort required to implement the same software project. Participants had different backgrounds and roles, and the software project had been implemented previously. Later, they were grouped into five teams. Each team discussed and combined their knowledge to agree on a single estimate.

Result: Estimates based on group discussion were more accurate than individual estimates.

Steps for Playing Planning Poker

1. Each team member receives a set of cards containing: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞ — a total of 12 cards.
2. The Product Owner reads the description of the user story or feature to the team.
3. Team members discuss the feature and ask the Product Owner questions if needed.
4. After discussion, each member selects a card representing their estimate and reveals it simultaneously.
5. If estimates differ significantly, the team discusses: Do we agree? What factors were overlooked? The person with the highest or lowest estimate should explain their reasoning before the next round of voting.
6. After discussion, the team may go through another round until consensus is reached.
7. Return to step 2 and begin estimating the next backlog item.

Estimating Size, Not Time — Using Relative Estimation Instead of Absolute Estimation

Estimation is simply an educated guess. We use all available knowledge and experience to estimate how long it will take. Rather than evaluating each new work item in isolation, why not compare it with previously completed items? Humans are better at relating to similar-sized objects than guessing absolute sizes.

For example: Is it close to this very small item? Or more like this medium-sized project? Or truly large, like the one we completed last month? Relative estimation not only reduces the time spent on estimation but also significantly improves accuracy.

Our brains are not good at absolute estimation — we always relate new things we need to estimate to what we already know.

Story Point Estimation

Estimating Velocity — Recording and Averaging Team Velocity per Sprint

The team’s velocity is the number of story points the Scrum team actually completes in a Sprint. Team velocity tells you how fast the team works. For a new project or team (with no prior velocity records), we can conduct 1–2 Sprints to measure and establish an initial velocity. During Sprint execution, we record the team’s velocity each Sprint for future planning.

Estimating User Story Velocity

We estimate the total number of story points in the Product Backlog. Knowing the average velocity per Sprint, we can calculate how many Sprints are needed to complete the project — thus estimating the project’s duration. As shown in the figure below.

Scrum Project Duration Estimation