Relative Estimation

Relative Estimation

In a traditional software development method, estimations are done in absolute numbers like hours or days. In this approach, by applying the Work Breakdown Structure, a big project is divided into small tasks and each task is estimated in hours. These estimates depend on the skills of the resources.

Estimation of technical tasks in absolute number is not always easy. Sometimes for a technical task, debugging will take 6 hours but the actual code fix will be done only in 10 minutes.

Relative Estimation could be useful in estimating complex tasks. To understand more on relative estimation, let’s take an example of buckets mentioned in the picture below.

                                       

If we ask how big is the first bucket and how big is the second bucket (absolute estimate)? We may not answer this question in absolute numbers. But if we ask the question, “How much bigger the second bucket is as compared to the first one (relative estimate)?” Usually, we will be able to answer the second question more quickly and in a better way. It is better to use the relative estimation technique for estimating complex tasks.

Here are a few more examples of relative estimates.

• The bus is about the double the size of the car.
• Car is three times the size of motorcycle
• Motorbike and Motorcycle are of the same size.

You should consider following factors while estimating user stories,

• Complexity: Consider the complexity of the story.
• Risk: Consider the team’s inexperience with developing this story.
• Implementation: Consider the implementation factors.
• Deployment: Consider the deployment requirements.
• Interdependencies: Consider other outside issues.

Steps for the planning poker game

1. Select a reference story from the Product Backlog and estimate it in terms of Story Point.
2. Select another User Story from the Product Backlog for estimation
3. Understand the story from the Product Owner
4. Each person estimates the size of this User Story relative to the Reference Story using poker cards
5. Everyone shows their cards at the same time.
6. If estimates vary significantly, high and low estimators explain briefly.
7. Repeat up to three times or until team agrees to  the estimates
8. Pick a number that everyone agrees upon
9. Repeat this process for all the User Stories from the Product Backlog.

Why Planning Poker Works?

• Those who do the work, do the estimation
• Team member has to give the reason for his estimation
• As a team of resources does the estimates, it leads to more precise estimates.
• Each team member will be heard

Steps to estimate stories successfully

For each story to be sized, do the following as a team (Product Owner, Scrum team including developers, testers, and scrum master).

Identify base stories.

It is very important to identify one or multiple base or reference story against which you would do relative sizing of the backlog. This story is picked from current product backlog or a different story which we have done earlier. But what is important is the understanding of this story is same among everyone on the team. The team should be confident of this base story.

Talk through the requirements of the story.

Product Owner or Product Architecture will answer questions and provide an explanation about what exactly this story details.     

Discuss and note down things while discussed and important when implementing this story.

These can be bullet points on the story card or text in the “notes” section of a tool. This is best done by Scrum Master who can add these details as and when discussions are on.

Team should clarify the question before giving final story size

• Design: What will we have to learn before we can start work on this story?
• Coding: How much code will need to be written for this story? Have we written similar code before?
• Unit Testing: Will any special setup (e.g., mock objects) be required to unit test this story?
• Acceptance: Testing How much work is involved in helping the customer to automate the acceptance tests for this story?
• Integration Points: Does this story have external dependencies?
• Expertise: Does anyone of us has done a similar story before?

Find some point of relative comparison.

If this story is about the same amount of work as the one you have already sized, give it the same number of points. If it is more difficult, give it a proportionally higher value. If this story is similar to another but less work in some way, give it a lower value.