Everyone loves to plan project tasks and engineering iterations. How much will we release this sprint? Will some of the tasks from backlog fit in? Will the external stake holders get a feature we all have been talking about for ages? Oh, the excitement is in the air!
Task queue in PivotalTracker with several tasks. Some tasks have hours, while bottom ones have not been estimated yet.
We look at the tasks and try to estimate how long each would take. Having rough time estimate allows to judge how many tasks would fit in the next iteration given N developers and M business days. Yet there is a giant missing feature: a time estimate of X hours to implement a particular feature does not take into account WHO is going to work on the feature. Given different level of experience and familiarity with the code, each feature might take developer A exactly X hours, and developer B 2X hours.
In a small team that assigns (implicitly) tasks during planning, this might not be a big problem. In a team with several people, where tasks might be picked from the queue, the widely changing time estimates throw off any kind of plan.
proposal
Allow adding multiple time estimates for each feature. At least have two numbers: pro and beginner. A pro would be time estimate for someone very familiar with the code, while beginner would be time estimate that includes getting to know the system and code before programming.
This would lead to each sprint having a range of total hours / fuzzy list of tasks that fit. That is ok, at least now there is a way to pick a person / next task based on better information, rather than looking at each developer as having exactly the same skills and knowledge for each item.
An additional possible benefit of this system would be detecting wide spread between the time estimates. If there is a large difference, it might be a red flag that there is high code or system complexity that needs to be minimized.