Estimation

Overview: –

Taking a leaf out from the previous chapter of Product Backlog Grooming where we studied how a Product Manager should help team members understand every product backlog item in detail, now it is time for the team to give an estimate to build the product as whole.

So, in this chapter, we will study and understand what is estimation and how is a product backlog estimated.

What is Estimation?

Any textbook definition would sum up estimation as a way to quantify efforts needed for completing a task.

In software development, where today most companies have adopted to Agile Development Method, a task is correlated to a user story who’s efforts are quantified by scoring them based on unit called story point. (We’ll see the details ahead)

But fundamentally, why do we need estimates? Can’t engineers work on tasks assigned to them by the given deadline or based on the organization’s need?

Let’s understand this before we study techniques.

Why do we need Estimates?

Let’s take an example. Say you’re building a house for yourself. You approach a builder/contractor, he asks your budget, creates a plan, you finalize design & the plan for the house. But the contractor doesn’t give you an estimate about how long will it take to build the place. Will you consider going ahead? Wouldn’t you think, will the contractor take forever to build the house? Has he created the plan based on my budget leading me to pay more than needed? You would right?

Likewise, for businesses to sponsor a project or a product in order to align it with their needs, having estimates help run the organization better and thereby the project as well.

Let’s have a look at commonly used techniques in estimating a projects.

Planning Poker : –

Planning Poker is a technique wherein the team anonymously votes or scores Product Backlog Items (PBIs) using a scale such as Fibonacci Series or T-shirt Sizes to indicate their estimate for each.

Voting can be done using cards with either of the scales or digital tools to keep anonymity. If there are large differences identified, the team is expected to discuss about the particular user story/feature or any PBI and then come to a consensus.

The Fibonacci Series is the most commonly and widely used scale to point or score PBIs. It is a sequence of numbers formed by the sum of previous two numbers. The series goes as , 0,1,2,3,5,8,13,21…

A commonly observed and a convenient practice is that when a PBI is pointed 13 or more, it should be broken down into smaller task or be considered as Epic wherein you can add a list of tasks to complete it.

Three Point Estimate: –

Estimation is challenging and more often than not, you’d find that the estimates are wrong. And it’s natural because atleast today, there are humans engineering a piece of software and it’s difficult to predict how long will it take to complete a task or a project as a whole. So, a better approach a PM can take is to be Pessimistic.

The Three Point Estimate is not specifically an estimation technique but a value derived from the mean of estimates gathered after a true estimation has been conducted in order to be used to present a near – realistic number.

It is a technique which helps a PM or a scrum master (if the responsibility is bestowed) who have a pessimistic outlook towards the estimates, the team & their nature of work. It further helps navigate but not fully solve the conundrum,

“No matter, even if the same team happens to work on the same type of product for a project, the estimates can turn unrealistic when you (the product manager) falls in the trap of thinking that because the team has done better previously, they’d do it again”

Method: –

1. Gather estimates by adding and removing a safe buffer value to obtain 3 values of estimates. Namely: –
   • Most Likely
   • Optimistic
   • Pessimistic
2. Then get a mean of the three values to obtain the near – realistic estimate for the project

Lets, see with an example. Say you’ve conducted an estimation of the project and by the first round without having any buffer added or removed, come up with Most Likely (M) estimate of 75 story points. You then discuss with the team to be aggressive and cut it to around 50 story points. This becomes your Optimistic Estimate (O). Lastly, you add variables such a festive leaves, the team’s leave plan and other factors that could affect the completion of the project and get the Pessimistic Estimate (P) as 100 story points.

Three Point Estimate = (M+O+P)/3

= (50 + 75 + 100)/3

= 75

So by factoring an aggressive approach and a pessimistic one, the project can be completed or the product will be delivered by burning 75 story points.

T-Shirt Size: –

Similar to Fibonacci Series, the T-Shirt Size is a scale rather than a technique used to estimate PBIs. While Fibonacci Series is helpful in ensuring every granular story or PBI is pointed with detail, T-shirt sizes are assigned when you’re expected to provide a high level of estimate that need not be accurate.

The scale can go as XS, S, M, L, XL, XXL…

These are three widely used methods for estimation. Although a tiring and exhausting task engineers need to perform, it is important for the organization is what they must understand.

Let’s look at considerations and Mistakes to avoid while estimating.

Considerations and Mistakes to Avoid : –

Definition of Done: –

Definition of Done is a formal description of the state of the increment when it meets the quality measures required for the product

The Scrum Org

It is a quality checklist that all PBIs should pass before they can be declared as DONE.

The Definition of Done is exclusive to every product and every team. Ideally, no two teams should have same DoD.

The Definition of Done is not an acceptance criteria because the acceptance criteria is specific to a particular task or user story while DoD is more of a standard to declare done.

But why should we consider Definition of Done while estimating?

It is to give a sense and an idea about how and when a story is deemed done which helps better estimate.

The mistakes to avoid are,

1. Never convert story points to hours. This leads to over commitment and under achievement.
2. Averaging Estimates –
   • If during planning poker, a few engineers point a user story an 8 while a others point it as a 5, then averaging is not the solution. Here, it is important to have a discussion and narrow down to come up to a consensus.
3. Never adjust story points based on who will be working on a user story.

Takeaways : –

We learnt what is estimation and why is it important in any discipline of engineering. We further looked at what are the techniques and scales used to estimate user stories and lastly had a look at the considerations that need to be taken while mistakes to avoid during estimation.

In the following chapters we’ll look at everything around planning before we begin work.