Satyajit Gantayat
Satyajit has broad and deep experience in Agile coaching at the strategic senior executive level wh... Read more
Satyajit has broad and deep experience in Agile coaching at the strategic senior executive level wh... Read more
If our estimates are wrong most of the time, why should we even attempt estimating in the first place?
Since we are in a complex world and the requirements, customer demands, and technology change rapidly, we know little about what & how we are going to develop. We learn more through empiricism. If this is the case, why bother estimating at all?
Estimating can work but only if you understand why you are doing it. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, it is rarely an estimating problem, it is a shared understanding problem.
Let us understand why we estimate.
A team is a persistent group, which has the combination of skills required to build valuable increments, and which self-organizes to identify tasks, assign owners, and do the work as quickly as possible.
We need to understand how much work the team can do, need to understand the scope that can be delivered in a schedule, or estimate a schedule derived from the scope. Estimates should be provided by the people that will be doing the work.
In SAFe we need to perform the exercise of estimation at multiple levels.
Solution/Program Backlog: The Program Backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART).
It also contains the enabler features necessary to build the Architectural Runway. The Solution Backlog is the holding area for upcoming Capabilities and Enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.
It is crucial to estimate Solution Backlog and Program Backlog because it allows a team and its Product Management/Product Owners to make longer-term predictions about how much can be delivered by when.
It allows teams to answer questions like:
It also helps product management in making prioritization decisions. Priorities should be set based on the expected benefits and costs of the solution/program backlog items.
For prioritizing the work, we consider the cost of developing the backlog items and the cost of delay using a technique called Weighted Shorted Job First (WSJF)
But, to be able to use this technique we need to know the estimates at a high level of the duration to build the backlog items.
For both Capabilities and Features, we would typically have lesser-known details. They are of large size. In these cases, it makes sense to use the T-Shirt Sizing technique.
Team Backlog: The Team Backlog contains user and enabler Stories that originate from the Program Backlog, as well as stories that arise locally from the team’s local context.
It may include other work items as well, representing all the things a team needs to do to advance their portion of the system. Each Agile Team will have its Team Backlog as an output of the PI Planning, for the duration of Program Increment.
For the Team Backlog, there are two reasons to estimate the stories. The first is that it helps the team determine how much work to bring into the iteration. By splitting team backlog items into small, discrete tasks and then roughly estimating them during iteration planning, the team is better able to assess the workload.
This increases the likelihood of the team finishing all they say they will. Second, identifying tasks and estimating them during iteration planning helps team members better coordinate their work. For example, if team backlog items are not estimated, a team might not notice a critical path through the work or that the designer will be the busiest during the coming iteration.
Transform your career with our Agile Coach certifications. Start your journey towards mastering Agile practices and leading high-performing teams today!
Register TodayHumans are visualizing animals; they find it easier to compare Objects as our brain is used to relative sizes. Because of its relative units, one of the advantages of the Agile Estimation technique is that it is understandable from a Junior Developer to Manager or to a Director of a company.
Most Agile estimation techniques use relative units. This means that we don’t try to estimate dollars or days directly. Instead, we use “points” or even qualitative labels and simply compare the items we are estimating to each other.
This takes advantage of the human capacity to compare things to each other and avoids our difficulty in comparing something to an abstract concept (such as dollars or days).
Agile Estimation is done considering :
Because the estimates in SAFe are done at different levels, for different artifacts, serving different purposes, they should be made in different units.
T-shirt Sizing is an Agile Estimation method – it’s used to estimate larger requirements i.e. Capabilities and Features. Items are categorized into t-shirt sizes: XS, S, M, L, and XL.
The sizes can, if needed, be given numerical values after the estimation is done. This is a very informal technique and can be used quickly with a large number of items.
This theory could be utilized as Bucket System Estimation. These techniques are used to estimate Solution and Program Backlogs since we have lesser-known details and estimates are at a high level.
A common tactic used by scrum teams is to estimate using a unit of measurement referred to as the Story Point. But why use Story Points instead of hours or days or any other well-known unit of time?
“A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements“
Story Points are intended to make team estimating easier. Instead of looking at a team backlog item and estimating it in hours, teams consider only how much effort a team backlog item will require, relative to other team backlog items.
Planning poker is an agile estimation technique that makes use of story points to estimate the difficulty of the task at hand. Based on the Fibonacci sequence, the story point values that can be assigned are 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. Each of these represents a different level of complexity for the overall project.
Planning poker starts with the team members involved in the estimation process sitting together for the session. Each member holds cards with the story point values described above.
The next step is for either a leader figure or the customer to read out the ‘user story’ (which is essentially the project), and describe all the requirements and features.
The stakeholder reading out the story will engage in discussion with the team members who are estimating, who will, in turn, discuss with one another. In this phase, they can ask the customer or owner questions for clarification and express any reservations they have.
When the discussions are finished, all of the estimators will select a card with the story point they believe needs to be assigned to the project. If the story point estimations match up – then that will be the final estimate.
However, if they do not match up, then estimators who gave the lowest and highest points can voice their reasoning, and more discussion will ensue until there is a consensus. This technique is not good for large teams, or when there are many items that need estimating.
If you only have a selected number of items (between 2 and 10) and a small band of teammates, then this is a good technique to use. It’s also one of the most popular estimation techniques.
For hundreds of years, we’ve had standard units of time. Why can’t we use hours or days? Well, in a nutshell, because your hour is not the same as my hour.
If you ask two developers to estimate the same user story, you’ll get two different answers. While some of the differences might be explained by gaps in the specification or understanding, the fact is that developers have different knowledge and experiences so it will take more or less time to do the same work.
Ask those same two developers to rate the amount of effort required to complete one team backlog item relative to another team backlog item and you’re far more likely to end up with a consensus.
Story Points. Ok, they show the relative effort to complete work on different team backlog items but how does that help anything? Until we understand what the team’s velocity is, we still can’t predict when team backlog items are likely to be completed.
Worse, if the membership of the team changes, the velocity will change and we won’t know what that new velocity is until sometime down the road. But to try and match Story Points to hours is missing the point.
What’s important is how many Story Points a team can complete in a sprint, known as the velocity. When you know this, you can make some predictions and you know what, they’re likely to be good.
Since the Tasks are assigned to specific developers, they could be estimated in hours. There are a lot of other estimation techniques used by different teams.
This article suggests only some specific ones gather an understanding of estimates done at different levels of SAFe.
Estimates should be provided by the team members who will be doing the work, as they have the best understanding of the effort involved.
Avoid estimating when predicting results of complex work, as it can lead to inaccurate timelines and pressure on the team.
Estimation in SAFe helps coordinate dependencies, align priorities, and forecast delivery timelines, which are essential for effective planning and decision-making.
Satyajit has broad and deep experience in Agile coaching at the strategic senior executive level while also coaching and uplifting the capability of teams and individuals. An Agile Coach and SAFe® Practice Consultant with more than 24 years of experience.
WhatsApp UsAttended the PSM 1 training by Preeth Pandalay. It was an eye-opener in many ways than one. The belief systems we worked...
I just attended the PSM I training with Preeth Pandalay, and it was awesome! Even though I already have a CSM certifica...
I recently attended the PSM-I (Professional Scrum Master - Level 1) session conducted by Preeth Pandalay, and it was an ...
Got a wonderful PO training from trainer Sumeet Madan from Agilemania. it was so innovative, interactive, lively, jolly,...
Had a really insightful training with Preeth Pandalay. This session helped me a lot in cracking the exam. His real time ...
We will get back to you soon!
For a detailed enquiry, please write to us at connect@agilemania.com
We will get back to you soon!
For a detailed enquiry, please write to us at connect@agilemania.com