Agile and waterfall ignore a huge element of task estimation

From the first time I did an estimate, it seemed evident to me that previous experience with a task is tremendously helpful in estimating it accurately. For instance, if you’ve installed a particular library a bunch of times, you should at this point have a good idea about how long that usually takes you, right?

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, programmer experience was ignored. 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: who is actually going to implement it? 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.

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, if the estimates differ greatly, there is going to be peer pressure on the implementer to try to get him to agree with the previous estimate.

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 maximize implementation speed, simply assign each task to the person most familiar with it.
• To maximize the potential of your team, have people learn more by assigning somewhat unfamiliar tasks to each one. Keep them in a challenging but not pharaonic effort level.
• Get people up to speed quickly by teaming up new members with those that are already familiar with the tasks you’ve assigned to the new guys.
• 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.