To estimate, or to not estimate? – How to build a common understanding of product using estimations

tim-gouw-73926-unsplashWhen working in an agile team, what’s the first thought that comes to your 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 purpose 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 both by PO and Development Team. If there is more uncertainty then it might not produce desirable results.

mindmap-2123973_640The most amazing and beautiful thing that 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, in order to benefit from diversity, we need to focus on inclusion. What we need is to provide ways to achieve that inclusion and I think working in Agile ways can help achieve it.

Here is how I have been using Estimation in terms of complexity to build a common product user story understanding in the development teams. Even though some teams went ahead to measure velocity for sprint planning and use burndown charts to track progress but this part remained a good foundation.

rawpixel-651335-unsplash

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. It’s the light bulb moment that engages the team in a useful conversation that leads to developing a common 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 benefit? creating bonds and relationship in team members, removing conversation barriers.

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

Images source: unsplash.com

One thought on “To estimate, or to not estimate? – How to build a common understanding of product using estimations

Leave a Reply to junaidsagheer Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s