How to estimate product backlog items more effectively?

Estimation in Agile Software Development is one of the most discussed and debated topics, but still, it confuses many people. We always wanted to know more and more about estimation and planning. A group of people was asking the below question during my recent talk then someone requested an answer on Quora as well. So I thought, why not write a detailed explanation here?

5 most frequently asked questions related to estimation.

1. Why estimation needed for software development
2. Which technique to use for estimating product backlog
3. What are relative estimation techniques in agile
4. How to estimate product backlog using story point
5. When to estimate story and product backlog

Why Estimation Needed for Software Development

We wanted to know how much time would take to get the required software and how much money someone has to pay for it. So is there a way to answer this question while practicing Scrum? Because Scrum is for developing complex software.

Why is software development complex? Because the requirement is either not consistent, technologies keep changing, or both. If something is complex, then estimating duration and cost will not be easy, but our sponsor wants an estimate.

Estimate means approximation, so there can’t be an accurate estimate because the accurate estimate is an oxymoron either estimate or accurate. Estimates help in planning releases, funding development efforts, and mitigating risks.

Which Technique to Use for Estimating Product Backlog

Any method is acceptable as long as everyone understands that this is just an estimate and not a contract. You may use a user story point, functional point, use case point, complexity point, number of days or hours, etc. But we are talking about complex software given by a team, not by an individual, so better to use acceptable techniques for everyone.

At the early stage of my software engineering career, my manager introduced complexity-based estimation, and it was useful. We were using five scales — very low, low, medium, high, and very high.

Very low means approx one day, low means 1–3 days, medium means 3–5 days, high means 4–8 days, and very high means 7–12 days. Later we changed it to a T-shirt size, but it was similar. When we used story points, it became confusing because points were also numbered. Many tried to convert points directly to days rather than using it as a scale. Although story points are more popular nowadays and you can try the same be careful.

What Are Relative Estimation Techniques in Agile

If we know how much time it will take to solve the problem, then no harm in estimating in days or hours. But we are talking about the complex domain and team to estimate, so it will be difficult to estimate in days and hours.

Difficult but possible if everyone understands the purpose of the estimate. If the objective is to forecast releases, have some initial budget allocation, and track progress toward releases, then no harm in estimating ideal days.

If the aim is to hold an individual, team, or organization accountable for the same, it defeats the estimate’s purpose, and then it turns out to be a contract game. In such cases, people use psychology rather than mathematics to see what number will win the contract. Story points or any relative estimate help in avoiding the contract game.

Relative estimates are about sizing problems based on some factors like the bigness of the problem, requirement clarity technology complexity, etc. Since the team prefers writing PBI (Product Backlog Item) in the User Story, so story point becomes the perfect choice. You can even think about the complexity point or use case point if you are using another format for writing PBIs.

How to estimate product backlog using story point

If there is already an estimated PBI, we estimate the rest compared to that, but what if we don’t have any existing estimated PBI? We have to pick one PBI with moderate complexity (for example — everyone agreed that a PBI is an intermediate complex because there are 3–4 validations and 2–3 workflows, the requirement is well understood, and the technology is not new).

Since we have one now, 2nd PBI can be estimated compared with 1st PBI. Similarly, 3rd PBIs can be estimated compared with 1st and 2nd PBIs. We can use the Fibonacci series to estimate and define scale: -

1 — Very Small, 2 — Small, 3 — Medium, 5 — Large, 8 — Very Large, 13 — Very Very Large

The team can use planning games to estimate. Planning Poker and Estimation Walls are popular techniques among agile teams. I will write about both in my next blog. Estimates given in points do not answer our initial questions. How soon the product be completed, and how much will it cost?

Our sponsor/customer/business wanted to know when they will get the full product even before the team starts working on 1st PBI, so what to do?

Try to understand the purpose of the same before providing any number. Usually, it is for awarding a contract to the vendor or securing the initial budget.

Awarding a contract based on only a financial quote is not advisable, and many companies don’t follow it anymore. However, financial quotes are still needed to formulate an initial contract.

Some companies follow analogous estimates, few follow PERT estimation, and many follow capacity-based estimations.

Analogous estimation: It is based on historical data. We look at the total points that the team has identified compare them with past projects and quote some numbers. It also depends on who owns the risks due to requirement changes.

PERT estimation: It is also known as the 3-point estimation technique. Here are detailed steps for the same.

• 1The team must estimate all PBI using the relative estimate.
• 2Let the team decide how much work the team can commit for an iteration and choose three numbers. The highest number, is called Pessimistic, the lowest is Optimistic, and the common one is called Most Likely.
• 3Every team member has to give an estimate. Assume team members have decided on 20, 35, 30, 25, 30, 30, 20, and 25 points for 1st sprint. Then Pessimistic Number (35), Optimistic Number (20), and Most Likely (30). Now use the formula Pessimistic+Optimistic+4(Most likely)/6 = 29.16 so 29 points. It is the estimated velocity.
• 4Since we know the estimated team velocity and already have an estimated product backlog, we can divide the total story point by velocity to get the number of iterations required to complete all PBIs.
• 5Since the Iteration duration is fixed, multiplying the duration with estimated iterations will give the expected duration of development.
• 6Team size remains the same, so we know the estimated cost of one iteration to multiply the cost by the number of expected iterations to know the expected cost of development.

When to Estimate Story and Product Backlog

The Scrum team can estimate either during product backlog refinement or during sprint planning events. I personally prefer estimating during product backlog refinement. Some companies also follow the release planning technique, but technically it is a product backlog retirement that happens before the first sprint.

Where to learn all these?

I teach in my Professional Scrum Master and Professional Scrum Product Owner classes. You can join our upcoming mentoring sessions too. I would suggest exploring the Agilemania website.