In planning, the team picks refined stories to commit to in the Sprint and estimates them with story points, mainly based on the amount of effort required and the complexity of the topic. Sometimes, teams estimate stories immediately after the story discussion during backlog refinement. This estimate may or may not be exact and depends on how experienced the team is. Estimation improves over time as the experience of the team improves within Agile development. There are a few problems faced by Agile teams initially:
- Accurate estimation expectations: One big mistake is to expect accurate story point estimates from the very first day of creating an Agile team. This is totally the wrong approach. Without proper coaching and experience, no team can provide accurate story points. First, we have to work with the team to coach them on the various techniques involved in estimating stories, then let them experience the work of creating a strategy for the Sprint and designing the functionality. As the time passes, they will be able to provide story points, which match your initial expectations.
- Lack of active participation: Only a few members are actively participating and the rest are agreeing with what others have given as estimates. This might be due to the change of approach inherent in adopting an Agile methodology. A few members might not accept the change. This leads to a blocker situation, which gets out of control when we proceed with work as most of the queries of team members remain unresolved. This is a reflection of a lack of understanding and proper analysis of the requirements for that Sprint. All the effort spent in planning goes to waste due to this.
- Influence of few resources: Few influential team members provide higher estimates. Above average team members who are working in a team having a good understanding of how the architecture leads to stretched refinement and planning meetings. This may affect the story point estimation of other members who are in the learning phase.
- Wasting time: The team also thinks that the backlog refinement and planning meetings are just a waste of time. Those team members who have a better understanding of architecture may presume this, but this is not true. In Agile, we regularly update the architecture and requirements. To understand these changes, we do have to consider regular refinement and planning meetings. We cannot deny or ignore the possibility of a complete architecture change in future Sprints.
As per Dr. Bruce Tuckman’s model published in 1965, there are four stages, which an Agile team goes through is ‘Forming, Storming, Norming and Performing.’ I, being an Agile practitioner, believe that a team will not become agile unless it passes through all of these stages. As we move through these stages, our estimation improves and becomes more accurate.