What is Estimation & Why
Estimation is the process of finding an estimate, or approximation, which is a value that
is usable for some purpose even if input data may be incomplete, uncertain, or unstable.
The value is nonetheless usable because it is derived from the best information
In every or most aspect of our day to day life, we look for approximation or estimation
and it helps us to take decisions in various context i.e. if we need to fix a broken capability in Car… we want to know approximate cost & time involved to take decision to go ahead, if we need to paint our apartment… we want to know budget, time, manpower estimations to take the decision to go ahead.
Similarly at work key objective of organizations is to make profit and make customers, stakeholders and employees happy.
- Estimations at each level i.e. business, product management, engineering management, scrum team (including Product Owner & Scrum Master) enables the group to take certain decisions on scope, schedule, budget and potential commitments to do justice to agreed scope, schedule and budgets.
- Estimation is really a very healthy activity, so long as the whole team collaborates on it together. It helps foster a buy-in from the whole team and ensure that everyone gets a common understanding of the scope and value to be delivered.
Communication and collaboration is the key to maintain common understanding of scope,
value, deviation from plan, revised plan etc among the impacted stakeholders.
Agile Estimation Techniques
Agile teams too, use estimation to help them plan and commit their work. Over time, team
members gets to know new user stories and they develop an increasingly accurate sense of
how they’re going to approach stories and how much effort each user story will take to complete. Teams with their historical experiences (successes, failures and challenges) can compare their velocity against point estimates and apply their learning to predict size and complexity of upcoming stories.
In the beginning, the team-specific concept of points or size for stories/backlog items is difficult to grasp and appreciate. But with time as a team work together for a while, and attempt to size and estimates new stories collectively they start feeling comfortable with the estimation at work.
Here are a few estimation techniques for agile teams that can ease the transition through
T-shirt sizing is a way to practice relative sizing. I found this technique very useful to get a quick team sense about new stories. The technique is used for estimating high level stories where uncertainty can be higher. Team finds the technique comparatively easy and by comparing stories team can assign them into buckets of Extra-small, Small, Medium, Large, Extra-large and Extra Extra Large.
- Team can create certain sections/areas on a white board or paper and label them Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL), and Extra Extra Large (XXL)
- Team and Product Owner has the list of prioritised list of user stories / epics to
discuss and estimate.
- Product owner picks stories/epics one by one and explain the expectation/objective/scope of the story.
- The team then collaborate to organise the user stories/epics under the headings XS to XXL.
Some teams even adopt creative approaches such as using dog breeds to estimate stories
(Dachshund, Bulldog, German Sheppard, Saint Bernard, Great Dane) or different animals (Rat, Dog, Tiger, Elephant, Dinosaur) to compare stories.
While T-shirt sizes and can be very effective for teams just starting out with agile, eventually it’s a good idea to move the team toward a more rational numerical scale.
Poker Planning (Story Points):
This is a well established technique popularized by Mike Cohn. Planning poker is a game that team members can play during planning meetings to make sure that everybody participates and that every voice is heard.
To begin, each team member is given a set of cards with numbers on them. The numbers are usually ordered using the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55….). The set of cards used for poker planning has the following number for practical purposes:
0,1/4, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?,..
- For a team to start using story point estimation (poker planning) technique, the first step is to set a team bench mark for a small story and a big story.
- Team goes through a set of stories and agree as a group on a small story that they all benchmark/estimate to be a story point ‘2’ story. Also team sets a benchmark/estimation as story point ’13’ for a relatively much bigger story (that they all understand well)
- Once benchmark is set, team can play the game and come up with estimates/story points for other stories in the backlog.
- Product owner picks a story/epic and explain the expectation/objective/scope and acceptance criteria of the story.
- Each team member mentally estimates the size of it on the scale. They can ask the
Product Owner questions to clarify any points, but for the moment they will keep their estimate (card) to themselves (hidden).
- Scrum master or facilitator asks the members to open up their card and then everyone opens the card.
- In an ideal case all the cards will have similar value, suggesting that the team have a common understanding of the requirements.
- But more often, the card values from each member differ and has variations. The team members with the lowest and highest estimates explain why they chose their scores.
- Product owner can add/refine the understanding of the group. Experts with detailed knowledge may be able to tell the rest of the team why a certain story is actually much easier than they thought, or why it may be more difficult than it first appears because of unexpected requirements.
- Team then re-size the story. Usually two such iterations help the team to build common understanding about the story.
As an estimation method, Planning Poker is very popular because it is fairly democratic.
Every team member gets a set of cards and is allowed to play, and gets the opportunity to
explain their reasoning to the others.
‘T-shirt sizing’ and ‘Planning Poker’ techniques are used for high level sizing of stories where more focus is on relative sizing and complexity of stories.
As team reach the sprint planning stage, the focus becomes on the sprint commitment
against their available capacity. That is where teams use ‘Hourly estimate’ for the identified sub-tasks for converting the story into potential shippable workproduct.
- Team picks the top priority story from the backlog.
- Product owner explains the expectation from the story. Team member (who has knowhow or who has done pre-planning/analysis for the story) shares the broad ‘HOW’ element for the story to execute.
- Team breaks down the story into sub-tasks (i.e. dev, test plan, code review, test plan review, unit test, qa, build, test, documentation etc.) to create the shippable
- Team assigns number of hours to each sub-tasks. Usually the sub-tasks are broken to the size where the sub-tasks can be done in 1 hr, 3 hr or 5 hr. If the effort estimation is more than 5 hr for a sub-task then team try to explore the opportunity to break down the sub-task further.
Team looks to be comfortable with hourly effort estimation at this stage because they are
familiar with the story based on their backlog grooming, relative sizing, pre-planning
As team mature, they explore the practice to go away with ‘Hourly Estimate’ and just commit to sprint work after detailed sub-tasking.