“How can we get good estimates on a feature if we don’t know who is going to work on it? Obviously, the senior developer will do it more quickly!”
I’ve seen this objection raised more than once, both at conferences and online. I very much disagree with this sentiment, and I’ve finally put a finger on specific reasons why.
Relevance of Estimates to the Long Term
Estimates are, first and foremost, for project planning. The primary use of estimates is to say, “We are roughly 50% through our planned work and 75% to our planned release date. Therefore, we will likely have to shift our scope or schedule.” For those questions, the detailed minutia about “who is going to get that particular story two months later” is not relevant at all.
In the long run, some tasks will get assigned to the “optimal” fastest person, and some won’t be. But over the course of dozens of tasks and months of work, that should all average out. And eventually, as various team members develop familiarity with the codebase and the patterns, the disparities should start to fade away.
Relevance of Estimates in the Short Term
That doesn’t mean estimates have no value when doing sprint planning! When you’re planning the team’s next week or two of work, it is important to realize that user stories aren’t totally fungible. Instead, there are frequent dependencies between stories forcing the team to sequence these serially. Even when two stories aren’t built on one another, they might involve code in the same files. In that case, it’s often useful to work on them in sequence anyway.
In these cases, it can be useful to have a rough guesstimate of task size to ensure that each developer has a full sprint’s worth of work. This is part of AO’s “10-box” exercise we’ve found valuable to keep larger teams productive.
Again, it doesn’t matter whether anyone is faster or slower. We’re more concerned with making sure we have enough actionable work for all team members. So, if there’s a question, then just make sure you have another story ready for a team member to work on.
The Difference Between “Fast” and “Slow” Developers
I think we significantly overestimate the impact of differences between developers. If one developer can do a task in one day and the other developer needs the whole 10-day sprint to complete it, then I think there’s usually something else going on.
What’s most commonly happening, in this case, is that a junior dev is spending eight days ramping into the codebase or researching the task, and then two days implementing it. It’s important to keep these both in mind because the “learning about the codebase” work should also pay off for future work and, therefore, average out over the long run.
This won’t quite be so straightforward for very junior developers since they’re going to need a fair amount of handholding. For example, a fresh graduate who has never worked on the web is going to struggle with a monorepo GraphQL React app. But I’ve found that, once you give the junior a few months to become familiar with the tools and patterns, they can start to follow existing patterns efficiently to implement things. In cases like this, it can be useful to identify a senior “feature lead” who can lead a small group or pair on large chunks of related functionality. Then, you can rotate juniors into that team in to get everyone exposed to that area of the system.
Critical Mass of Fast Developers
I think focusing on “who is going to work on this story” is a distracting detail. If you instead focus on making sure you have enough “fast” developers to support ramping in your juniors, then the details will work themselves out. I feel an optimal team will be somewhere around 30-50% senior folks. We can quibble over the experience mix in the other portion, but the key thing is to have enough seniors so they’re typically available for questions.
If your team is balanced, it doesn’t matter who will work on any given piece of the system. A balanced team will have enough support to find efficient assignments naturally.