I opened an agile card deck I have at random to “Story Estimation Fundamentals” or “the ABC(DE) of Task Estimation”. Here are my views …

All contributors estimate

I like to encourage a culture where the team is responsible for meeting the goals of a sprint, not individuals. By this I mean team members should be willing, even eager, to help each other out. The responsibility is then balanced across the team. Individuals can feel more like they can take that day off they need to do occasionally. Estimation responsibility ties into this as well – I think it’s good to share the responsibility of estimation across multiple team members. It may be one or two team members dig deeper to understand one area, but all team members should be involved in review and estimation, as the team as a whole is responsible. What if someone is off sick? Or called off for a production issue? The other team members should expect this to occur, and be willing to take on getting the sprint goals for the team across the line. That is, this should be allowed for during estimation – I do NOT mean they should just work harder. Team members should expect to frequently work on tasks that were not identified as for them at the start of the sprint. Shared code knowledge should be encouraged.

There are other benefits of course. If everyone has to provide an estimate, then everyone is more motivated to understand what the other team members are doing. They cannot just stick to their own area. Getting less senior members to provide estimates along with senior people helps them learn how estimates are made. (There is a question of course whether more senior staff actually generate more accurate estimates! 😉 Poker planning I think is a really useful technique to get the whole team to contribute and be involved in a meaningful way. I have done a post on poker planning before, so won’t repeat it here.

Bottom line is I truly believe involvement of ALL team members in the planning and estimation phase is mandatory. It’s wrong for tech leads (for example) to take full responsibility for this. The responsibility (and knowledge and skill transfer) should be shared.

Break story into tasks to verify scope

Some time back in talking to the team I was with we had been talking about allocating more time to “planning”. Really this should have been “design and planning”. It’s not more time just to plan – the real goal is to delve into design more and so have more confidence that the correct tasks are identified and the estimates for those tasks are more likely to be correct. I expect the team to break into smaller groups to investigate particular areas, review requirements, come up with proposed designs, float ideas past other team members, etc. Then the team comes back together to do poker planning or similar sessions. This may be dynamic and iterative. The goal is to end up with a list of tasks with estimates. The team then decides how many tasks to commit to in the sprint.

Come to Consensus with Planning Poker

I don’t mandate Planning Poker, but I think it has really sound reasons as to why it works. Again, the important thing is the team reaches some degree of agreement on the estimates. If there are big discrepancies, spend some time to dig deeper. The tech leads are there however to make the final call if consensus is not reached.

Decrease estimation granularity as story size increases

The bigger the task, the harder it is to estimate. Big projects are really hard to estimate. I dislike tasks longer than a day or two. A 4 day task, for example, if out by 50% becomes 6 days, which is a large percentage of a sprint. By that time, it’s too late to take corrective action. Smaller tasks makes it easier to determine that progress is made right from the start of the sprint. Corrective action can be taken earlier if required. I would also note that I am not a big fan of recording “remaining work” for tasks. I prefer just saying ‘done’. How many 80% complete estimates of programmers do you trust? There can be a lot lurking in the last 20%. 100% is much safer. So smaller tasks I find better.

I will add however I have seen problems at the other extreme. When tasks become too small, sometimes they have too much time allocated to them. 10 minute tasks get allocated an hour. This can blow out estimates in the other direction.

Estimate using relative sizes, not calendar days

I don’t care that much about this one actually. Relative sizes can be T-shirt sizes (S, M, L, XL). Personally I have found programmers understand “hours” or “days” better than arbitrary units. It’s not that I trust the number of hours estimate that much. It’s more a concrete unit that humans understand and stick to from sprint to sprint. Measuring how much got done in previous sprints comes up with a total of how much is done per sprint. This may not be how many hours were actually performed. That does not matter. The goal (for me) is to work out how much work the team can do in the next sprint so we can work out early whether the longer term goals will be met. If the estimates are reliably out by a factor of two – fine! The team’s capacity can be worked out and used to pick how much work to commit to for the next sprint.

There is value in the team getting their estimates more accurate in absolute terms. So trying to improve the absolute estimates is useful. I am happy for people to try and improve it. However I don’t have high expectations here. That is, every task is probably different to previous tasks, so estimation will never be that accurate. That’s OK. The only purpose of estimates is to work out how much can be bitten off for a sprint. They have no other purpose. If the right amount of work is undertaken for that sprint, the goal has been achieved. It may be in practice, if tasks are all broken down into 1 or 2 day tasks, then simply counting the number of tasks (and not doing any estimation) would be good enough. I personally would not go that far. I think there are smaller logical tasks and bigger ones. So taking that into account is worthwhile. (But it might be ½ day, 1 day, 2 days are the only task sizes ever picked.)

You may not agree with all the above. That is fine. The above is my opinions based on my personal experience and I am happy to put it out there. Feel free to leave a comment on your experiences and how they differ!