I was recently struggling with a dilemma about how to make story estimates with a hypothetical team that is fairly colorful in experience. The team would consist of four senior developers, one junior developer who just recently joined the team (and the company) and two designers.
We estimate stories using planning poker cards where each team member assesses a story and puts down the chosen card backsides, so other members don’t see the decision yet. After every member puts down their cards, they are revealed simultaneous, so there’s no chance of influencing decisions by one another. The final estimate SP is declared after a consensus between all team members.
And here’s the catch, effort needed for a particular story will differ for a senior and a junior developer. Which is expected, since juniors don’t have experience in particular frameworks, architecture, and so on. But what to do now, if a consensus is needed and you want the estimates to be fair and realistic.
The answer is: you can’t have both for all members, especially if the team has members with different experiences. There are things that can be done.
The first thing that might pop into your head is to skip planning poker and let only the junior to make his own estimate for a story he might own. But this would defeat the purpose of estimates, which is to give you a team velocity and how the whole team is productive. You effectively divide the team into two standards. And you probably don’t want to do that. The second reason is that the junior developer might try to sandbag and overestimate a story. Also, the stories, in this case, must have an owner. This might not be a bad idea but the team is less agile and the team will have to sync if another member takes over the story, which again means the initial estimate might be wrong.
The other way, and in my opinion the correct way, is to let the whole team participate in planning poker, but the scrum master must consider that a story might be picked by the junior who might or might not complete it by the end of the sprint. There was a discussion somewhere on the internet that such sprints push too much pressure on the junior who just recently joined the company and the expectations for him are high. This might be true as stress is always involved when someone joins the company, but the job of the scrum master must be to keep an eye on the junior and helping him complete his work. This way, the junior developer will be forced to keep up with the team standard, will have the chance to learn quickly and eventually blossom into a senior.
There’s another scenario where two of the four senior developers are front-end and two back-end developers and a back-end story needs to be estimated. The general rule is to let the experts estimate. This applies if the team works in a way where you have specialized members for specific subsets of problems. So, we’re not talking about experience here, like in the previous example, but people with different skill sets. Experts play the planning poker, leaving non-experts, like front-end developers and graphical designers on a back-end story, out of the game.
I hope this post helps others that were in such a dilemma.