Years of project management has taught me that one of the keys to a project’s success is managing stakeholder expectations. The only medium we have to influence expectations is effective communication.

Autonomy allows teams to open up their creativity and solve hard problems by being self-organized. It expects an extraordinary degree of commitment but also an important sense of accountability, which often puts teams under pressure that are asked to provide forecasting on their work. I noticed this especially with brand new teams, who go so far as to refuse to provide estimations of their efforts. The reason? To avoid making promises that are hard to keep.

A common misunderstanding

A new team, with a completely new project to implement, starts providing really high estimates to try and discourage the expectations of a Product Owner. Iteration after iteration, no value is delivered and the team decides to stop using estimation to avoid uncomfortable situations after their alignment meeting.

An opposite example yields the same result:

The team is asked to provide estimates for upcoming work. A well defined scope and high team maturity spreads optimism, which influences estimates to be too low, even without an explicit deadline in the project. During the iteration it turns out that the effort required is actually more than estimated.

A team member might start feeling uncomfortable, and in order to reduce the time, sacrifices the quality of their work. The outcome is an announced iteration dedicated entirely to bug fixing or refactoring. Any increase in time or reduction in scope is seen as a defeat. It leads to a vicious cycle which pushes people to have an aversion towards estimations and, sprint after sprint, the planning meeting becomes the worst appointment of the week.

In both cases, at certain point in the story, someone will state that their software development methodology is not Agile but only a variant of developer micromanagement.

A misunderstanding on the purpose of the estimation tool can indeed disrupt a team’s harmony and productivity: From one side the team doesn't understand the real purpose of estimating a piece of work, while on the customer side it can create unrealistic expectations.

The tool

I believe that estimations are a powerful tool – especially if you work in a complex and super challenging environment. Estimations establish a shared understanding of the user story between product and development parties, and within the whole team. It is THE decision-making tool.

If one person considers a task small and another large, they are most probably not on the same page. Whether you have to go for A or B solution, it must be understood which box we need to pack the problem in. A letter envelope or a big IKEA box?

Creating expectation is just a natural consequence of the process, but it is essential to share a common mindset of the ambition level that your stakeholders wish to reach. A crucial appointment is the "user story grooming session" (or backlog refinement), when the team can re-estimate their stories as soon as they realize an assumption is wrong.

This activity should occur on a regular basis and could be an officially scheduled meeting or an ongoing activity. In my experience, it has helped teams a lot; Some of the activities that occur during these sessions include:

• Removing user stories that no longer appear relevant
• Creating new user stories in response to newly discovered needs
• Re-assessing the relative priority of stories
• Assigning estimates to stories which have yet to receive one
• Correcting estimates in light of newly discovered information
• Splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration

The Product Owner then clearly defines and updates the Acceptance Criteria and indicates or reassesses their expectations.

Conclusion

I strongly support that even in the first stages of a project when everything will be highly unpredictable because of requirements, use cases, planning, staffing, and other unclear variables, that estimations should occur. No matter the estimation technique, as soon as you receive the first data points and the sooner you can test your assumptions, the better the variability in the project diminishes.

If you’re interested to know more or share your experience you can get in touch with me via Twitter at @FaustoSannino.