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.
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.
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.
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.
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:
Now let's take a look at 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.
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:
Relative estimates do not have units. They are just relative numbers. Whereas, in a Scrum, these numbers are called Scrum Story Points.
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
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”.
Now let’s discuss the steps of the game of planning poker used for relative estimation.
We will learn more about this activity in the next section more briefly.
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: