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.
- Coordinate dependencies: It can be extremely useful to know when the team can proceed to work on a new design if the key expert is temporarily out of the office.
- Align priorities: During the day we have a list of things to do. Often, we estimate the efforts to sort out our priorities.
- Choose the "best value" option: Estimates help us to decide when we choose between different options, for instance when I choose the best car for a budget.
- Forecast: A forecast is great to be better prepared for the future. Forecasts are often based on empirical evidence.
- Shared understanding: When a team agrees to build something complex together and take a lot of decisions during the process, probably they are better to sit down and validate some of the assumptions behind the agreement.
When not to estimate?
- Predicting results of the complex work. It will end up with a time-management mess
- Focusing on someone to work better. Humans are awful at demonstrating the best results under time pressure. This is the reason why professionals are striving to increase estimates to make life easier.
- Increase the effectiveness of time management. Estimates decrease effectiveness because of Parkinson's Law.
Who Provides Estimates?
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.
What to Estimate?
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:
- How much can you deliver in three months?
- When can a certain set of team backlog items be delivered?
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.
Techniques for Estimation
Humans 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 :
- The amount of work to do
- The complexity of the work
- Risk or uncertainty in doing the work
- Time / Duration
- Business Value
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 Estimation
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.
Story Points
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 Technique
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.
Why not estimate in hours?
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.
Why Story Points are better?
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.
