When you’ve got a mix of experience levels on an Agile team, it’s easy to assume that the senior folks should take the lead on estimations. After all, if someone’s been around the block a few more times, it seems logical they’d have a sharper sense of how long things will take. But here’s the thing: the beauty of Agile lies in its collaborative approach, and shutting out junior voices during estimation not only undermines that collaboration but can lead to some blind spots in understanding the scope of work.

Let’s say you’re in a typical backlog refinement or planning session and a story comes up. The more seasoned team members throw out a two-point estimate without much thought, but a junior dev hesitates and suggests it might be a five-pointer. That hesitation is often gold. It’s a sign that something—maybe a potential complexity or an unconsidered requirement—has been missed. If the senior folks brush off that input because they’re confident in their quick assessment, the team misses a chance to dig deeper, ask questions, and reassess. What looked simple on the surface could have snags only certain perspectives can spot.

You see, people with less experience often lack the same assumptions or shortcuts as their senior counterparts. They’ll ask questions that might seem basic, but those questions can expose gaps in understanding or overlooked details. Sometimes, those fresh eyes catch things that a more experienced team member might gloss over because they’ve built up a mental backlog of “that’s how we always do it.” By fostering open dialogue where everyone’s estimates are respected and explored, teams create opportunities for deeper discussion and, ultimately, better solutions.

This is where Agile’s emphasis on collaboration and self-organization really shines. Estimation should never be about “who’s right,” but about what’s going to help the team collectively understand the work better. Even if the junior dev’s five-point estimate seems exaggerated, asking them to walk through their reasoning could reveal tasks or risks that weren’t immediately apparent to the rest of the group. And this doesn’t just benefit the juniors—it improves everyone’s understanding of the task at hand.

Estimation isn’t just about numbers, you know? It’s not about guessing right every time, but about uncovering knowledge gaps. Even experienced developers can fall into the trap of making assumptions based on past scenarios that don’t always line up with the current task. The conversation that stems from differing estimates—whether it’s the senior person dialing down expectations or the junior member voicing concerns—opens up a chance to share knowledge across the team. This kind of back-and-forth highlights areas where the team may need to do more research or spend extra time fleshing out unknowns.

One of the great things about having a mix of experience levels is that it promotes healthier checks and balances. A junior dev might think something will take longer because they’re unfamiliar with certain tools, but that’s precisely when a senior dev can chime in and offer mentorship, showing them a quicker path forward. On the flip side, seniors can also get bogged down in their routines, and someone newer might propose a completely different approach—one that’s more efficient, modern, or attuned to newer technology the more experienced devs haven’t yet adopted themselves.

This dynamic exists across all teams, by the way. Think of teams with diverse expertise, not just within “levels” like senior or junior, but even across technology stacks. Frontend engineers may have totally different considerations than backend engineers when looking at a story. That mixture of experience and perspective often brings out innovative ways of attacking a problem.

The key here is respect. Everyone’s input matters, not in a “let’s be nice to juniors” way, but in a practical, “every angle helps us see clearly” way.
Here’s where things get tricky: instinctively, we want estimates to come from those who “know best.” If someone’s been coding for ten years, it’s natural to trust their judgment more than a junior dev who might only have a year of experience under their belt. But Agile estimation isn’t about who’s been doing it the longest; it’s about asking how we can get the best outcomes as a team.

One thing I’ve noticed time and time again is that the act of estimating is a fantastic way to uncover hidden knowledge gaps—regardless of experience level. It’s not just about putting story points to a task but about understanding what that task really entails. For example, during estimations, even the most seasoned developer might overlook small but crucial details that someone newer to the project, with fresh eyes, could catch. The questions that arise from these discussions can lead to clarifying points that radically change the estimate and, more importantly, prevent unpleasant surprises later on.

This collective “realization” that estimations often bring to the surface is what makes having a broad range of experiences within a team so valuable. Juniors will think of things seniors don’t, simply because they haven’t pre-packed their brains with all the defaults that come from years in that role. And seniors can point out shortcuts or risks that might sail right by a junior. All of this together leads to better decision-making. The key, though, is maintaining an environment where everyone feels like their voice counts—because it really does.

Take a real-world situation: a team is estimating a task that involves building some complex logic for data validation. The senior backend dev quickly suggests it’s a 2-point story—they’ve dealt with this kind of thing before. But the newer team member, maybe unfamiliar with the existing codebase, hesitates. They’ve recently had a tough experience debugging a similar feature and voice concerns about how edge cases might be handled. Suddenly, the scope of the story expands, as the team realizes they hadn’t considered enough of the potential “what-ifs.” The final estimate jumps to 5 points, reflecting a more thorough understanding of the challenge. Without that junior team member speaking up, the team might’ve underestimated, leading to scope creep or technical debt later.

This scenario plays out all the time on good Agile teams. When differences in estimates come up, they aren’t obstacles—they’re sparks for conversation. And it’s those conversations that lead to catching problems early. In fact, as teams become more practiced at joint estimation, it stops being about the actual number assigned and more about ensuring that the team fully grasps what’s needed.

There’s also something to be said about the confidence it builds. When junior members participate in these discussions and are taken seriously, their confidence grows. Estimation isn’t just about refining your task list; it’s about refining your team’s collaborative muscle. That newer team member who was once hesitant to share their thoughts will become more comfortable speaking up—not just in estimation sessions, but in reviews, retrospectives, and even during sprints. Over time, this shift improves the entire culture of the team. People are more likely to push boundaries, experiment, and innovate when they feel heard.

And let’s be real: experienced developers are humans, too. They can get it wrong just as easily—if not more so—because they’re sometimes operating on autopilot. Relying on past experience sometimes means falling into assumptions rather than truly thinking through the intricacies of a particular task. Encouraging group discussions grounded in differing points of view keeps even the old-timers sharp. It forces everyone to keep learning, to rethink their approach, and to stay open to the idea that they might be missing something.

So if you’re in a position where the most experienced person’s estimate always wins out, it’s worth reassessing how your team is handling discussions. Are you inviting the quieter voices to share? Are you digging into differences in estimates rather than brushing them off? Because at the end of the day, estimation is a collaborative process. The best results come from pooling all those varied experiences together, not from deferring to the loudest or most experienced voice in the room.

At the heart of Agile is the idea that people, not processes, build great products. And that includes how we estimate. Embrace the differences in experience on your team—they aren’t a challenge to get around. They’re the driving force behind better collaboration, better problem-solving, and ultimately, better delivery.