3

My team estimates task which is easier for someone who already knows Swagger but harder for someone who doesn't. The person who knows Swagger will likely have other tasks to do so this one may fall to someone who needs to educate himself on the topic before he can do any work.

I've read Mike Cohn's It's Effort, Not Complexity that supposedly deals with this problem, but I'm not convinced. In my example, less knowledge requires more effort and we obviously cannot estimate "X points if Tim will do it, but Y points if Brad will". What is correct way to estimate in such a case?

  • IMO avoid Mike Cohn, and MGS, as he is highly traditional in his mindset. – Alan Larimer Dec 29 '17 at 20:55
  • Your mistake is assuming one person does a story. The whole team collectively delivers work, so the efforts (and drag) of the entire team need to be factored into the estimation. – Todd A. Jacobs Dec 30 '17 at 17:55
  • @AlanLarimer If by traditional you mean "systematic," that certainly seems preferable to following cowboy agile, ScrumBut, or some other unstructured system. If you simply mean you disagree with him on technical or philosophical grounds (which you're certainly entitled to do), your comment comes across as an attempt to discredit the referenced article by discrediting the author, rather than as a substantiated counterclaim. It does nothing to address the OP's question about how to estimate when levels of expertise vary. – Todd A. Jacobs Dec 31 '17 at 15:47
  • For this article, and others, it would be that he expects story points to behave directly as time. – Alan Larimer Jan 13 '18 at 21:41
8

In Mike Cohn's example about the surgeon and the kid, I'd go through the following approach:

Estimate with the brain surgeon estimation, but making explicit that the brain surgeon will be training the kid during the process.

The main issue you'll have will be the planning, as you still have the constrain of your Swagger hero, having to train the other guys. As Mike says, brain surgery can be done only by brain surgeons, but you may train quickly more brain surgeons.

Think about this: you don't want a team in which only one of your guys is the hero (you'll have a bus factor of 1, and that's never good), you want A TEAM of people being able of working in the different technologies you use. Of course, you'll have issues whilst the training, as you explicitly have a constrain of one developer having to do so, but if the tasks are done by two developers, one of them actively doing knowledge transfer, you'll reduce that knowledge gap quickly, you'll build a better and cohesive team (having team members helping each others is a good way of doing that), and at the end you won't have neither big differences nor bus factor of 1, being able to deliver much more and with less risks.

0

If Swagger is on the critical path for your team, then try strategies like pair programing to ensure that over the time knowledge is distributed in the team.

If you need estimates use techniques like planning poker and get opinion of different team members until you have agreement in the team.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.