Estimating Fast with Multiple Teams Involved

[#1]

Let’s admit it: we are not very good at estimating.

We routinely overestimate and underestimate work, influenced by individual perspectives, experience, and incomplete information. The challenge becomes even more pronounced when estimates turn into commitments—especially when timelines are shared with stakeholders and delivery expectations are set.

While experience helps us improve over time, estimation rarely happens in isolation. In modern organizations, it usually happens across teams—or even teams of teams. This is where alignment on scope and complexity often becomes harder than producing the estimates themselves.

In this article, we propose a practical approach and toolset to estimate faster, with less friction, and with multiple teams involved.

Estimation as a Process

You have probably heard the saying: “Plans are nothing; planning is everything.”

The same applies to estimation.

The real value of estimation lies in the process itself. It helps teams:

• Walk through requirements in detail
• Build a shared understanding of the problem
• Identify upstream and downstream dependencies and associated risks
• Explore alternative solutions
• Discuss trade-offs between cost, complexity, and time

These conversations are critical for making informed decisions and aligning teams around a common approach.

But We Still Need Numbers

Ask any project or delivery manager, and you will hear the same response:
“This is all valuable—but we still need numbers.”

And they are right.

Estimates are not about precision. They are about expectation management—both internally and externally. Teams need a foundation for meaningful discussions about timelines, capacity, and trade-offs. Stakeholders need a way to reason about delivery without false certainty.

Good estimates enable better conversations. Bad estimates create false confidence.

Apples to Apples: Why Comparison Works

This is not a new problem. Over time, people have discovered something important:

We are much better at comparing than estimating in absolute values (e.g. hours).

Teams align faster when they compare new work to previously completed, well-understood items. Agreement on relative size and complexity comes more naturally than debating absolute numbers.

This leads to the idea of estimation by clustering:

Compare new work items against a set of known reference items with established estimates.

As the saying goes, “The best weather forecast is for yesterday.” They also say “The estimate is significantly more accurate when done collaboratively.”

Making It Work at Scale

Now let’s apply this idea at scale—across multiple software and business teams—using Atlassian Jira.

Step 1: Tag Reference Work Items

Start by selecting a set of completed work items with:

• Known size and complexity
• Broad familiarity across teams
• Representative scope

If you don’t have any completed work yet and everything is new, consider adding a couple of well-estimated items.

Aim for 2–3 reference items per estimation grade. Tag (e.g. use label Jira field) clearly so they can be queried using JQL and added to your main JQL you will use to pull the backlog of work items for the estimation exercise. Over time, you can replace or refine these reference items as better examples emerge.

Step 2: Build a Reference Estimation Board

Create a board where:

• Columns represent estimated sizes, from smallest to largest (with the last column or column group - aggregating a couple of the largest scales - typically called “Too Big – Needs Splitting”)
  
  
• Swimlanes organize work, for example:
  • One swimlane per team
  • Or by releases, increments, epics, or initiatives
  • Or JQL if you need ultimate flexibility

Reference work items could naturally sit within swimlanes defined. Or in case you are using a JQL-based swimlane you might consider to put collect them into separate (top) swimlane

Standard Jira Agile boards limit columns to statuses. To overcome this limitation, consider:

• Jira Product Discovery, which allows custom fields as columns
• Or Atlassian Marketplace Apps that provide flexible Kanban and Agile boards

For example, Advanced Kanban & Agile Boards allows any standard or custom field to be used for columns and swimlanes, and even includes a ready-made estimation-by-clustering template.

Step 3: Use Common Estimate Fields

To keep things consistent:

• Use a single, shared estimate field across all Jira Projects (Spaces)
• Story Points often work well as a common denominator. This ensures compatibility with Jira’s built-in features and most Marketplace Apps for reporting and analytics

If you are using different project types and therefore different Story Points standard fields you might consider a different custom field to align or a custom field for t-shirt size estimation technique that could be later converted into numbers by simple mapping.

Step 4: Consider estimation drift over time

Estimation drift—where story point estimates increase over time for tasks of similar complexity—is a common challenge.

This drift is typically driven by a few key factors:

• External and internal pressure: Management expectations combined with a natural tendency for teams to show increasing velocity from sprint to sprint, even without meaningful improvements in process, tooling, or domain knowledge.
• Insufficient detail: Higher estimates are sometimes used as a safety margin when task scope is unclear or initial investigation is limited.
• Infrequent recalibration: Without regularly revisiting reference stories, teams lose a consistent baseline for comparing new work to past items.

These issues can be mitigated—and estimation consistency improved over time—by using an estimation reference board and applying estimation by clustering, as described in the sections of this article.

Small Things That Make a Big Difference

Several usability details significantly speed up estimation:

• Ordering items within columns and swimlanes: Relative order often matters more than the exact value.

• Rich but focused cards: Show only information relevant to estimation directly on the card.

• Visible context without clicks: Tooltips for dependencies, comments, or estimation hints reduce the need to open items.

• Drag-and-drop simplicity: The smoother the interaction, the faster teams converge.
• “Play with swimlanes”: The ability to collapse, expand, and reorder swimlanes helps maintain focus and flexibility during estimation sessions. Plus ability to save such view configurations and revert to it just speeds things up.

With good preparation, estimation becomes a seamless exercise of comparing new items against reference work and placing them accordingly.

Beyond Estimation

An added benefit of this approach is flexibility.

If your board allows moving items between swimlanes, estimation sessions can also surface:

• Team ownership changes
• Rebalancing across sprints or releases
• Early dependency discussions

When standard Jira fields are updated automatically, all related boards, reports, and Marketplace apps reflect the results immediately.

Takeaway

People—and especially groups—are far better at comparison than at absolute estimation.

By creating reference estimation boards with:

• Estimates as columns
• Flexible swimlanes for grouping work items (e.g teams or increments)
• Visualize only necessary information on the cards and add detail on hand
• Estimate by simple drag & drop

…organizations can dramatically reduce estimation friction while improving alignment and expectation management. Overtime it can also help fight estimation drift problem.

With the right preparation and a few thoughtful usability choices, estimation at scale becomes faster, clearer, and far less painful.