Sometimes when a team is asked to estimate a backlog item, one or more people with expertise in an area are asked to estimate the item, but this is not the best way for an agile team to get a good estimate.
There are benefits to involving a larger part of the team in the estimation process. The challenge is that people feel that involving the whole team is wasteful if the estimation process takes too much time. On the other hand, inaccurate estimates have their own costs for the team and the other stakeholders.
Planning Poker, an estimating method popular with Agile Teams can address some of these issues. Briefly, planning poker involves getting the developers on a team together to estimate stories using a deck of cards that have numbers that represent units of work. The numbers are often spaced in a Fibonacci sequence, the theory being that the larger the estimate, the lower the precision. Planning planning poker can be a really useful tool to both improve estimation and discover uncertainty in requirements.
People resist planning poker for reasons like:
- It seems inaccurate if the person doing the estimating does not having the "appropriate" expertise. A UI developer may not feel qualified to estimate a story that seems to be mostly backend processing, for example.
- It seems like a waste of time because people believe that one person can estimate for everyone.
- It seems inaccurate since the person who's been assigned the work should estimate it based on their skills.
If you find that your estimates are inaccurate, or your estimation process takes too long, consider the following approach:
- Gather team members who are working on all aspects of the application. You need not have the whole team, but be sure to represent each "architectural layer". If your team is less than 7 people or so, include everyone.
- Look at the description of each story or problem report in priority order. Ask the team to pick cards based on what they read.
- See how close the estimates are.
- If they are close, ask someone to explain what they envisioned doing to implement the issue. If someone has a vastly different idea, they should speak up.
- If they are different, as someone with one of the extreme estimates to explain their reasoning. This will start a conversation about what the requirement means, and what implementation strategy makes sense.