Providing an accurate answer to “How long?” and “How much?” is a fundamental component in organizational planning and alignment. The goal of estimation is to predict the effort required to complete a project or deliverable. Agile estimation at scale can be challenging due to the complexity of large teams and the uncertainty associated with developing complex software. Let’s explore 5 principles of Agile estimation from Scrum@Scale to guide your agile teams in their estimation efforts.

1. Sizing is always relative

As with any Agile estimation, teams should leverage relative estimation vs. absolute or time-based estimation. The amount of time required to complete a unit of work can be influenced by external factors and may not accurately reflect the actual effort required. Using tools such as Planning Poker or Affinity Sizing, teams can quickly arrive at a relative size in the form of story points which can be used to create time predictions.

2. Time predications are always based on empirical data

Time predictions in agile estimation are always based on empirical data. Agile teams use historical data on team velocity, cycle time, and other metrics to inform their estimation efforts. This data provides a baseline for estimating how long it may take to complete a given work item or project. However, it is important to note that time predictions are never exact and can be influenced by a range of external factors. Agile teams recognize that estimates are not set in stone, and they remain open to adjusting their plans based on new information or changing circumstances. By using empirical data to guide their estimation efforts, agile teams can make informed decisions and plan their work in a way that maximizes value for their customers.

3. Estimation is only done by the people doing the work

One key principle of agile estimation is that it is only done by the people doing the work. This means that only the folks responsible for delivering the work should be estimating the effort required.

The rationale behind this principle is that those who are closest to the work have the most accurate understanding of its complexity, dependencies, and potential risks. When team members are involved in the estimation process, they have a shared understanding of what is required to complete the work and are more likely to take ownership of the estimates. This can lead to a more accurate estimation process and a greater sense of buy-in from the entire team.

Additionally, involving the entire team in the estimation process can help to identify and address any potential roadblocks or issues early on, which can improve the overall success of the project.

4. Granularity is your friend

Granular estimation involves breaking down work items into smaller pieces, providing benefits such as improved progress tracking, collaboration and ownership, identification of risks and dependencies, and more accurate overall estimates. By estimating smaller, more manageable pieces, teams can identify and mitigate risks, accurately track progress, and increase ownership and collaboration among team members.

This does not remove the importance of progressive elaboration. Start with high level and refine to an appropriate level of detail and understand that your backlog will change over time. You can, and should estimate everything on your backlog, including large work such as epics or capabilities.

A good window of detail should resolve around your release windows. We know from patterns of high performing teams, that a team should have 2-3 sprints of backlog ready for work at any given time. Beyond that your backlog will contain larger items (big user stories, epics, etc.), but close in we should have a high level of detail.

For that reason, I like to work in releases that are around 3-4 sprints in length. This allows you to plan ahead and answer larger, budget-level decisions with release planning, but also favor the fact that smaller and shorter increases your accuracy.

5. Embrace uncertainty

Embracing uncertainty is an important principle of agile estimation, especially at scale. Agile teams understand that solution development involves inherent uncertainty, and estimates may change as new information emerges. Rather than striving for perfect estimates, teams should focus on creating estimates that are good enough to guide decision-making and planning. This involves being open to the fact that estimates may change as the team gains more information and experience. It also requires a willingness to adjust plans and priorities based on new information. By embracing uncertainty, teams can focus on delivering value to customers in an iterative and adaptive manner, rather than getting bogged down in attempting to create perfect estimates.

This principle must be reflected in how you display or talk about time expectations. Traditionally companies and teams have used tools like a Gantt chart to report progress. However, an unintended consequence of these type tools is that they report a level of confidence against a timeline that does not exist.

In the Agile world, tools such as a Burn-Down or Burn-Up chart better reflect the inherent uncertainty of work while also giving stakeholders the ability to quickly see and respond to changes in schedule and budget. Additionally, most backlog management tools can quickly generate these reports when generated against a DEEP, well-refined, backlog.