When working in an agile team, what’s the first thought that comes to mind when you hear  “Team Velocity“, or “Sprint Burndown“? and yes, both are related to Estimation.

I’ve experienced that some agile teams found estimation useful while others considered it less beneficial to the team and process. However, for the management, perhaps it is important to know how the team is progressing on the Product/Sprint Backlog and achieving Sprint Goal. Thus “Team Velocity” and “Sprint Burndown” are there for planning purposes in terms of next Sprint velocity, release planning, resource planning, budgeting, and XYZ.

I think estimation is effective when product backlog and user stories are well understood by PO and Development Team. If there is more uncertainty, then it might not produce desirable results.

The most amazing and beautiful thing I’ve learned so far is that everyone is different, and there is a reason behind it, the “Diversity of thoughts“. if we all think alike, then we can easily miss the growing opportunities. However, to benefit from diversity, we need to focus on inclusion. We need to provide ways to achieve that inclusion, and I think working in Agile ways can help achieve it.

I have used Estimation in terms of complexity to build a shared understanding in the development teams. Even though some teams measured velocity for sprint planning and used burndown charts to track progress, this part remained a good foundation.

Planning Poker, shirt size (S, M,x/L) or any other numeric technique can help achieve the inclusion of thoughts.

While estimating a work item during backlog refinement or sprint planning event,  I often ask the team “How complex do you think this work item is?” and the team member gives their personal estimations (in terms of complexity) revealed at once, which could be e.g. 3, or 8 or 13 or X. That’s the golden moment to ask the question “Why do you think this is less complex / more complex” and then wait for the magic to happen when the team starts sharing their thoughts about possible limitations and opportunities. The light bulb moment engages the team in a useful conversation that leads to developing a shared ground and understanding for that work item. This is also beneficial for the PO to assess if the work item has been understood correctly by the development team, and how much more information is needed by the team.

This approach has been very helpful for me when working with distributed agile teams we well. It triggered more conversations and bonus benefits. creating bonds and relationships in team members, and removing conversation barriers.

There are also other #NoEstimation #NoProjects initiatives out there. However, I think let’s take the part which can fulfil a particular need and adds value to the team and value delivery process.

Images source: unsplash.com