top
upGrad KnowledgeHut SkillFest Sale!

Search

Scrum Tutorial

Today “Agile” is an enthusiastic topic in many software development discussions. There are a lot of questions surrounding Agile, everyone is asking for it, and everyone is trying to be Agile. But at the same time, there lies a lot of misunderstanding and confusion regarding its practice, especially when it comes to Estimation.Why is Agile Estimation required?Agile Estimation plays a pivotal role in planning and managing the development of a product, and in the same way, when it answers the questions such as “How many features will be completed?”, “when it will be done?” and“ How much will this cost?”. In order to answer these questions using scrum, we need to estimate the size of what we are building and measure the velocity rate at which we can get the work done. Having this information, we can derive the likely product development duration and the correspondence cost by dividing the estimated size of a set of features by the team’s velocity.Let us see the Agile Estimation techniques in detail.So,  what is Estimation?In software development, an “estimate” consists of a quantified evaluation of the effort necessary to carry out a given development task.Who all should be attending the Agile estimation?It’s important to have the right people while estimating product backlog with planning poker. Let's take a look at the members who are needed in the team and the roles they carry out during the agile estimation meeting.First, of course, we should have a team. All the team members should be present when playing planning poker. And the rest of the members are as follows.Scrum team membersProgrammersTestersProduct owner (only if invited by the team)Scrum MasterAgile estimation gamesThe Agile estimation game is one of the best techniques as it improves the performance of a Scrum team. It’s like a game which also performs valuable work. Using this technique, the team is able to estimate 20 to 60 stories in an hour.The objective of agile estimation game is to balance the time spent on estimation with the value it delivers.Agile Estimation techniquesBasically, methods used for estimation on Agile software development project varies widely. Teams adopt their own approach and adapt it based on what works for them. Here are two widely known techniques:Relative EstimationPlanning PokerNow let's take a look at Relative Estimation.    1. Relative EstimationIn traditional software development method, estimation was done in the form of a number like hours or days. But here, work breakdown structure can be applied so that the project is divided into smaller tasks and each is estimated in hours. These estimations depend on the skills of the resources.Estimation of technical tasks is not easy and hence, cannot be denoted absolute in number. Sometimes for a technical task, it is possible for a team to solve problems which might take 6 hours, but the actual code fix will be done within 10 minutes.Relative estimation is useful in estimating complicated tasks. It’s good to understand better with an example of  Steel container, as seen in the below diagram.Let’s understand it better,Suppose when you asked how big the first container is and how big the second one is, you might find it difficult to answer this correctly. But when you are asked how much bigger the second one is compared to the first one (relative estimation), then you will feel like ‘whah!’ Yes, it’s easier to answer the second one rather than the first one. So, it’s better to go with a relative estimation technique for estimating complex tasks for better results.Following are a few more agile estimation examples which will make you understand in a better manner:Australia is about double the size of India.Canada is three times the size of India.Canada and USA are of the same size.Relative estimates do not have units. They are just relative numbers. Whereas, in a Scrum, these numbers are called Scrum Story Points.Benefits of Relative EstimationLess time, and easy to refineCan be explained easily and expectations can be justifiedPeople are better at relative estimation than absolute estimationIts geared to be more team-centric than time-centric like absolute.Common Mistakes Made While Using Relative EstimationRelative estimation is harder when you try and translate it into your work (user stories), as it involves the common mistake of estimating in time and complexity.The example goes like this:“ that last user story took 3  hours and this seems it will take 3 hours” and you don’t know at this point who will take up the work, time varies and is not a good measure for estimation (in a team setting)“ that last story worked had some complications to it and the current will also look very complicated” these things can seem more complex to different people, this is why complexity is not a good measure for estimation    2. Planning PokerPlanning poker is a very popular technique in agile estimating as it is based on the estimation technique known as Wideband Delphi, which was created by the RAND Corporation either in 1940 or 1968. It became more popular when got added to Mike Cohn’s book “Agile Estimating and Planning”.Planning Poker Game in ScrumNow let’s discuss the steps of the game of planning poker used for relative estimation.Steps for the planning poker gameThe first step deals with selecting a reference story from the product Backlog and start estimating in terms of story points.Now, select another user story from the product backlog for estimation.Understand the story from the product owner.Each person will start estimating the size of a user story relative to the reference story using poker cards.Everyone displays their cards at the same time.If estimates vary significantly, high and low estimators explain briefly.The process is repeated three times or until the team agrees to the estimates.Choose a number that everyone agrees to.Repeat this process for all the user stories from the product backlog.We will learn more about this activity in the next section more briefly.What is the outcome of an Agile estimation?An estimate is the best guess for us to know what can be achieved and by when. Here are some of the best advantages by the agile estimation:It helps to identify when a team can release better resultsEstimate helps us to choose the best option.
logo

Scrum Tutorial

Agile Estimation

Agile Estimation


Today “Agile” is an enthusiastic topic in many software development discussions. There are a lot of questions surrounding Agile, everyone is asking for it, and everyone is trying to be Agile. But at the same time, there lies a lot of misunderstanding and confusion regarding its practice, especially when it comes to Estimation.

Why is Agile Estimation required?

Agile Estimation plays a pivotal role in planning and managing the development of a product, and in the same way, when it answers the questions such as “How many features will be completed?”, “when it will be done?” and“ How much will this cost?”. In order to answer these questions using scrum, we need to estimate the size of what we are building and measure the velocity rate at which we can get the work done. Having this information, we can derive the likely product development duration and the correspondence cost by dividing the estimated size of a set of features by the team’s velocity.

Let us see the Agile Estimation techniques in detail.

So,  what is Estimation?

In software development, an “estimate” consists of a quantified evaluation of the effort necessary to carry out a given development task.

Who all should be attending the Agile estimation?

It’s important to have the right people while estimating product backlog with planning poker. Let's take a look at the members who are needed in the team and the roles they carry out during the agile estimation meeting.

First, of course, we should have a team. All the team members should be present when playing planning poker. And the rest of the members are as follows.

  • Scrum team members
  • Programmers
  • Testers
  • Product owner (only if invited by the team)
  • Scrum Master

Agile estimation games

The Agile estimation game is one of the best techniques as it improves the performance of a Scrum team. It’s like a game which also performs valuable work. Using this technique, the team is able to estimate 20 to 60 stories in an hour.

The objective of agile estimation game is to balance the time spent on estimation with the value it delivers.

Agile Estimation techniques

Basically, methods used for estimation on Agile software development project varies widely. Teams adopt their own approach and adapt it based on what works for them. Here are two widely known techniques:

  • Relative Estimation
  • Planning Poker

Now let's take a look at Relative Estimation.

    1. Relative Estimation

In traditional software development method, estimation was done in the form of a number like hours or days. But here, work breakdown structure can be applied so that the project is divided into smaller tasks and each is estimated in hours. These estimations depend on the skills of the resources.

Estimation of technical tasks is not easy and hence, cannot be denoted absolute in number. Sometimes for a technical task, it is possible for a team to solve problems which might take 6 hours, but the actual code fix will be done within 10 minutes.

Relative estimation is useful in estimating complicated tasks. It’s good to understand better with an example of  Steel container, as seen in the below diagram.

Relative Estimation

Let’s understand it better,

Suppose when you asked how big the first container is and how big the second one is, you might find it difficult to answer this correctly. But when you are asked how much bigger the second one is compared to the first one (relative estimation), then you will feel like ‘whah!’ Yes, it’s easier to answer the second one rather than the first one. So, it’s better to go with a relative estimation technique for estimating complex tasks for better results.

Following are a few more agile estimation examples which will make you understand in a better manner:

  • Australia is about double the size of India.
  • Canada is three times the size of India.
  • Canada and USA are of the same size.

Relative estimates do not have units. They are just relative numbers. Whereas, in a Scrum, these numbers are called Scrum Story Points.

Benefits of Relative Estimation

  • Less time, and easy to refine
  • Can be explained easily and expectations can be justified
  • People are better at relative estimation than absolute estimation
  • Its geared to be more team-centric than time-centric like absolute.

Common Mistakes Made While Using Relative Estimation

Relative estimation is harder when you try and translate it into your work (user stories), as it involves the common mistake of estimating in time and complexity.

The example goes like this:

“ that last user story took 3  hours and this seems it will take 3 hours” and you don’t know at this point who will take up the work, time varies and is not a good measure for estimation (in a team setting)

“ that last story worked had some complications to it and the current will also look very complicated” these things can seem more complex to different people, this is why complexity is not a good measure for estimation

    2. Planning Poker

Planning poker is a very popular technique in agile estimating as it is based on the estimation technique known as Wideband Delphi, which was created by the RAND Corporation either in 1940 or 1968. It became more popular when got added to Mike Cohn’s book “Agile Estimating and Planning”.

Planning Poker Game in Scrum

Now let’s discuss the steps of the game of planning poker used for relative estimation.

Planing Poker Game in Scrum


Steps for the planning poker game

  • The first step deals with selecting a reference story from the product Backlog and start estimating in terms of story points.
  • Now, select another user story from the product backlog for estimation.
  • Understand the story from the product owner.
  • Each person will start estimating the size of a user story relative to the reference story using poker cards.
  • Everyone displays their cards at the same time.
  • If estimates vary significantly, high and low estimators explain briefly.
  • The process is repeated three times or until the team agrees to the estimates.
  • Choose a number that everyone agrees to.
  • Repeat this process for all the user stories from the product backlog.

We will learn more about this activity in the next section more briefly.

What is the outcome of an Agile estimation?

An estimate is the best guess for us to know what can be achieved and by when. Here are some of the best advantages by the agile estimation:

  • It helps to identify when a team can release better results
  • Estimate helps us to choose the best option.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments

Julz

Thank you for sharing such Sprint ideas, it's too good!

Da-Trok

Thanks for sharing this content. I have serious interest in learning and finding a job as a Scrum Master. The information share here has given me an eye opener and boosted my desire to learn Scrum.

Biswajit Datta

Your blog post was a valuable resource for anyone seeking practical advice on the topic. I appreciated the clarity of your explanations and the actionable recommendations you shared.

OpenGrowth Hub

Thank you for sharing such amazing information. Looking forward to reading more stuff like this. Great share, Amazing write-up.

Suman

Truly its a outstanding post. So precise to look into Scrum.

Suggested Tutorials

Scrum Tutorial [Video]

Scrum Tutorial [Video]

Agile Tutorial [Video]

Agile Tutorial [Video]

USEFUL LINKS