From the first time I did an estimate, it seemed evident to me that . For instance, if you’ve installed a library a bunch of times, you should at this point have a good idea about how long that usually takes you, right? previous experience with a task is tremendously helpful in estimating it accurately particular What the current methodologies do Each person on a team has different levels of familiarity with each task, so it doesn’t matter if one person estimates all tasks, or if you take an average from estimates done by several people. In both cases, there is loss of valuable information. Strangely, this familiarity factor has been largely ignored by teams I’ve worked in. My current one does “planning poker” for example, which tries to have a few people agree on an estimate. Problem is, what if only one of them has actually implemented such a task before? The weight is on that guy to get everyone else to agree with him. Averaging estimates can lead to completely useless results. Waterfall had a similar, if not worse, problem. Usually in that kind of environment, the team leader would do the estimating, or he would defer that to another team member. Again, experience was ignored. programmer Never have a single person do all the estimating. Peer pressure sweeps the problem under the carpet Another relevant factor that is usually ignored during estimates is: Certainly, the estimate cannot be accurate if you label a task as low complexity and then assign it to someone with zero previous experience with such a task. This problem cannot be avoided by any system that separates estimating from implementation. who is actually going to implement it? Some teams try to mitigate this by having the implementer re-estimate it, but then you are wasting time estimating it twice and, in my experience, to try to get him to agree with the previous estimate. if the estimates differ greatly, there is going to be peer pressure on the implementer The benefits of focusing on task familiarity An interesting thing about paying attention to task familiarity, is that it seems like people have no interest at all in gaming this metric. They know that they either do or do not know something, so there is naturally going to be less guesswork. If you love numbers, you can run a survey in your team to measure how familiar each person is with each task. By starting from more accurate data, your conclusions should be more valuable. Start by building a table with team members and tasks, and have each cell be a number from 0 to 10 measuring how familiar each member is with that task. Having done that, you can use that table to help you make decisions and to calculate valuable things. Measuring how familiar each person is with a task can give you valuable insight on your team To , simply assign each task to the person most familiar with it. maximize implementation speed To , have people learn more by assigning somewhat unfamiliar tasks to each one. Keep them in a challenging but not pharaonic effort level. maximize the potential of your team by teaming up new members with those that are already familiar with the tasks you’ve assigned to the new guys. Get people up to speed quickly Build a general technology familiarity table for your team, measuring each tech (React, Angular, etc.) against how familiar each member is with it, which will let you . know how much of an impact you’ll have by introducing the new tech into your stack
