什么是敏捷估计？

无论团队是在开发产品还是在开发项目，我们都需要回答“我们什么时候能够完成？”，或者说在某个时间点我们能做到什么程度，就像传统的开发模式一样，我们需要在开始项目之前估计工作量。

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 used a 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.

Best Scrum Software Every Project Needs

A powerful scrum software that supports scrum project management. It features scrum tools like user story map, product backlog management, sprint backlog management, task management, daily scrum meeting, sprint planning tool, sprint review tool, sprint retrospective tool, burndown, impediment, stakeholder and team management.

Learn More

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.

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.