Let’s start with following questions & try to estimate: -
1- Approximately, how much time will it take to go from Delhi to Chennai (Distance between the cities = ~ 2200 KMs.)?
2- Approximately, how much time will it take to go from Delhi to Noida (Distance between the cities = ~ 30 KMs.)?
And the condition is “Mode of travel” is same in both scenarios, say By Road.
INTRODUCTION
Estimation is the process of ‘evaluating something by keeping its constraints in the mind’. At each step in our life, we go through this process & make our decisions. From shopping to investment, from exam-preparation to games everywhere we do an estimate. It is not wrong to say that “In Life, if you have taken any decision, you’ve DONE the Estimation”.
Projects are not an exception. Software Development Life Cycle starts with Requirements & Analysis and runs until delivery. At each phase, estimation is done. Project Estimation is like “What & when can we deliver?”
AGILE Estimation techniques are the process of estimating the work in the project & try to find the answer “What & when can we deliver?”
In Agile, there are different ways & techniques of the estimation which cater different purpose. Mainly estimates are of 2 types:
HIGH & LOW-LEVEL ESTIMATES & ESTIMATION TECHNIQUES
In Agile, any project is delivered as multiple MVPs (Minimum Viable Product) in defined iterations (aka. Sprints). Before project start & during the development of a project, Product Owner takes input from Customers & stakeholders and manages the product backlog based on the requirements, suggestions & feedback received from them. Customers & Stakeholders provide their input based on the business value of the features of the project. Hence, the product backlog is something which shows the Vision of stakeholders & business value of the product. The items will be picked from this product backlog & put into the sprint backlog for the next sprint (iteration). BUT “Shall we pick items randomly from product backlog?” No, and now HIGH-LEVEL ESTIMATES comes into the picture. Let’s see what that is!
HIGH-LEVEL ESTIMATES
Consider an Iceberg as a project. See below picture: -
Suppose an ICEBERG is like a product which we must develop & deliver. The area which is under-water shows the Product Backlog/Wishlist & will be delivered in future releases. The items will be picked up from product backlog & will be moved to Sprint backlog & these items will be released as MVP at the end of the Sprint.
HIGH-Level Estimates help Product Owner(PO) & Stakeholders to prioritize the product backlog item, long-term planning of product deliveries & set long-term goals. But How High-level estimate helps?
T-Shirt Size Estimation – This is the technique to estimate the epics & features. The sizing is provided as S, M, L, XL, XXL. The team sits together with PO & gives a very high-level estimate based on this sizing. This is the way to estimate Epics & Feature.
SWAG (Scientific WILD-ASS Guess) - This is also the technique to estimate the epics & features. The sizing is provided very vaguely but in points. E.g., - 600 points etc. The team sits together with PO & gives a very high-level estimate.
Relation with Business-Value – When these high-level estimates are collected by PO, She/he discusses this with stakeholders. They brainstorm & compare the estimates against the business value of each Feature. Because of this brainstorming, PO gets the prioritized product backlog as per business value & size.
This is how High-Level estimates works in the Product journey & helps in product planning.
LOW-LEVEL ESTIMATES
Now the Product backlog is prioritized (using High-level estimates) & having the user stories for long-term planned Epics & Features and we are in Sprint planning ceremony. Each item/story from product backlog will be estimated individually & moved to Sprint Backlog. These estimate which is more specific, detailed, based on each & every detail of work required in the story, are called low-level estimates. There are 2 techniques of Low-level estimation:
Story Points – Generally Poker Card is used for these estimates. The team will go through the “Acceptance criteria” of the story & ‘Definition of Done’ & comes up with story point estimate. The sizing is any of 0, 0.5, 1, 2, 3, 5, 8, 13, 40, 100, ? and ![]()
(infinity). Finally, these are the estimates which are reflected in velocity because These estimates estimate the business value which will be delivered.
Clock Hours – This is the absolute technique of estimating the work. The team split User stories into task & give Hour-estimates. The sizing can be any positive number. These are the estimates which are reflected in burndown chart & shows the daily progress of the project. These estimates estimate the individual’s capability to complete a particular task and that is why the summed-up capability set the starting point marker in burndown chart.
Relation with business value – After each sprint MVP (which is a part of the feature) is delivered. These story point estimates set the velocity of the team. When stakeholders brainstorm the priority of new feature or epic based on business value & timeline, they consider:
1- The Business Value of the Feature
2- The total rough estimates (High-Level estimate) received for a Feature (Say it Distance or Volume)
3- The velocity of the team (Say Velocity)
When velocity & Distance/Volume is present, a stakeholder can easily estimate the TIME of getting this new feature delivered. They Compare it with its business value & prioritize into Product Backlog. And then, the same cycle goes on for this feature to be delivered as MVP in next Sprint.
Now, remember 2 questions from which we started. Just think of your answers: -
In our answers (or estimates) of these questions, we are clearer about time from Delhi to Noida journey rather than Delhi to Chennai. The reason is lesser volume (or say Distance), Lesser chances of blockers, lesser complexity & lesser uncertainty.
Therefore, we can consider: Delhi To Noida à Sprint Backlog Item (as User story)
Delhi To Chennai à Product Backlog Item (as Epic or Feature)
Now, as we have seen above, how we should estimate these: -
Delhi To Noida à Sprint Backlog Item (as User story: Estimated as low level – 3 Story point or 1 hour)
Delhi To Chennai à Product Backlog Item (as Epic or Feature: Estimated as high Level – 100 Points or XXL)
Conclusion
The Epics/Feature are bigger, more complex & more uncertain items & these are included in a high-level plan. It is difficult to estimate them & hence vague or high-level estimates are used for these. On the Other hand, User Stories are more clear, simple & smaller items & easier to estimate & hence low-level estimates are used. These user stories deliver the MVP & set the velocity which further is used by stakeholders to plan & prioritize the direction of a complete product as per Market/Business value.
