What is Agile Estimation?

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 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

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.

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.

About Visual Paradigm

Visual Paradigm help organizations stay competitive and responsive to change faster and better in today’s fast changing environment. Our award-winning products are trusted by over 320,000 users in companies ranging from small business, consultants, to blue chip organizations, universities and government units across the globe. It enables organizations to improve business and IT agility and foster innovation through popular open standards and process frameworks.Visual Paradigm, a killer Agile feature in 2018, introduced Scrum Process Canvas for automating the way a Scrum team to create, manage and deploy software application that empowers the team to continuously improve their performance at unprecedented speed and scale. Manage the Entire Scrum Process in One Page Automate the Scrum Framework in a fun and enjoyable dashboard with eye-catching updated status. Manage Backlog, Multiple Sprints of different Scrum Roles with a single-page visually executable canvas Allow instantly access, review and generate scrum artifacts and related documents to be archived in the Shared Cabinet Automate the Scrum events and related activities with self-explanatory instructions, samples and required document templates.