With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc...
Agile Methodology is in trend everywhere regardless of the industry type. It has been quite popularized due to its unique take on product release and delivery over traditional estimation techniques.
Whenever a team is trying to finish a product, the most important question is when it will be the release, i.e., what's the deadline?
In Agile Estimation, the tasks are not planned with time duration in the same way as traditional estimation; the division of tasks is based on story points. Now, think of story points as an abstract unit of time-duration, which is purposely used to let our mind not be focused on time but rather the problem-solving. Story points can be of different duration for individuals or groups.
In traditional estimation, the estimates are made using a bottom-up approach; this means that the evaluation of every individual task is done, the estimation for the time required to complete the task is done, and then the information is used to create the product plan.
Meanwhile, in the Agile Estimation, the product is gauged using a top-down approach. This enables teams to make a broad estimate of the amount of time the product will take or the amount of work it will need. This is then dismantled and applied to other aspects of the product.
This estimation technique's success for gauging a product duration comes down to the reason that humans are indeed really poor when it comes to making total estimates.
Let us elaborate if we estimate that any given product will be finished within a certain time duration, be it X days or X weeks or X months; by the time we finish the product, we might find our estimation to be way off and that it took much longer to finish the product.
But we can tweak this to our advantage with Agile estimation. As humans, we are quite adept at relative estimation, which is gauging a product's completion relative to the time it took for us to complete a previous product with similar goals.
To make it simpler, think of how we had math problems where we had to calculate how masons (or builders) will build a two-storied house while the time it took for them to complete a one-storied house was given to us. We used relative estimation to get to the actual time-duration.
The size of an individual task for the product is a story point. Story Points are based on the complexity of the task and the work necessary for the story to be implemented and executed
The easier to implement or less complex will rank lower in the story point scale, and the complex story will be prioritized higher in the scale.
There are four important criteria to be considered during estimation:
Pre-Planning --> Planning --> Release Planning --> Iteration Planning
Now that we have the basic idea about how Agile estimation works let's see some Agile estimation techniques for implementing them.
When predicting a long-term timeline, a team's average velocity is used. The average velocity is computed by adding the velocity points from the team's previous three rounds of Sprints and dividing it by three.
So if the entire team achieves 10 points in the first run, 13 points in the second run, and 7 points in the third run. So, the team's average velocity will be 10 points per Sprint run (10+13+7 divided by 3).
It is possible to assess the most ambitious, negative, and probable completion dates if the team has a velocity data record. The more probable outcome is calculated using the team's average velocity figure, while the most negative forecast completion date is calculated using velocity numbers from the team's worst-performing runs.
Planning Poker is an estimation technique that relies on reaching a consensus between the team and the client using a game format, which is then used to estimate the work required to implement the product's goals and, thereby, ultimately decide the duration.
The Product Owner or the client starts by reading an Agile story or describing a feature to the team.
After listening to the story and asking for further information and requirements, the team estimates the story points using numbered cards. The numbered cards are then put onto the table face down and are revealed simultaneously by everyone. If everyone agrees on the same story-point estimation, then it's settled. Otherwise, the process is repeated till every team-member agrees on the same estimation.
The highest and lowest estimation member should most definitely partake in the discussion to reach a consensus.
Planning Poker uses the Fibonacci Sequence to add an estimated value or a point to any of the features or Agile user-stories.
Fibonacci Sequence is used as:
F(n+1) = 1.618 or 60% incremental, which is the most estimation accuracy we can get. F(n)
A group or team estimates the products Agile-user stories or features by putting them in "buckets" in the same order as Planning Poker based on the Fibonacci Sequence.
Like in the Planning Poker technique, the team estimates individual stories or features and puts those stories in buckets scaling along with the Fibonacci series.
A specific feature like UI designing as per the client's needs is the least complex to achieve. So, the team will vote 2 or 3 in the bucket system.
If the majority votes do not select any given number, then the team will discuss further to reach a consensus.
Dot voting is an easy and accurate method for calculating small numbers of objects. Each individual is given a limited number of "dots," which they use to vote on an item's size; more dots equals bigger. This is done to identify and assort the Agile stories according to their priorities based on the amount of work they require or the amount of time it would take to complete it.
This trickled down from the Bucket System and simplified three choices: i.e. High Priority, Low Priority, and Uncertainty.
The first step is to categorize the Agile stories into the extremes (Big and small), and the more complex choices can be put into the 'uncertain.' Upon further evaluation and discussion, you can also categorize the 'uncertain' pile of stories into high priority (big) or low priority (small).
One of the most well-known ranking methods in Agile planning is T-Shirt Sizing. It's used to provide a high-level estimation of a project's relative scale.
Teams give estimated figures based on a t-shirt sizing scale of XS, S, M, L, and XL, after listening to the Agile stories. The size of the stories is decided after an inclusive and collaborative decision.
This approach works by looking for correlations between the estimated objects. They are to be grouped by the team.
Silent Relative Sizing: A card with the word 'Smaller' written on it is placed on the extreme left of a wall or a board, while a card with the word 'Larger' is placed on the extreme right.
Teams are asked to prioritize the stories based on this after considering the effort required to execute them.
Selecting the best suitable method of Agile Estimation for a project specifically depends on the size and experience of the team, as well as the kind of backlogs that needs to be sorted.