Effort estimates within agile teams. A topic that provokes a lot of discussion in many organizations and many teams. During many years I had to deal with “effort estimates” within many contexts, so I am going to share my take on this topic with you, based on the many (different) experiences I have had.
First of all, there is some value in estimating work. However, I believe that there is more value in (discovering) value. A big benefit of estimating work is that you have a plan, so you know where you deviate from the plan during execution, so you are able to respond to change. So you have some data that you can use to reflect on and interact about it within your team.
I am already almost 30 years active within the IT industry. And I have learnt that effort estimates are actually never correct, though reflecting on estimates and reducing the number of unknowns tends to help us in getting better in nearing better estimates if you take a lot of numbers (estimates) and calculate the sum or average. This is highly related to the complex domain, since we can be very sure that the info we had when we needed to estimate things is not the full story.
My statement is therefore: estimates are never correct, and the sum/average of a lot estimates might be correct. So if you zoom out, look at a broader scale, you might get better data. And that is the reason why I think that narrowing down and trying the obtain more precise values, is actually equal to moving away from getting better effort estimates. Within that perspective I think that story points as commonly used within the agile community is relatively better than direct time estimates, simply because time is typically translated to a fixed very precise value and connected to fixed deadlines.
That last effect is as far as I am concerned a toxic element in a complex domain, because people or teams may be blamed for not achieving some piece of work. And honestly, I believe that taking e.g. 1.5 times the estimated time for delivering a high quality product that has double the anticipated value is much better than delivering a product in time with x known defects, delivering what management asked for 2 years ago. Furthermore, we already know that effort estimates are not correct, so we “calculate” some (huge) slack in our “estimations”, making the effort estimations even less correct. And with that it makes some fixed price overly expensive.
So my statement is that only a focus on estimates it not providing a complete picture. You need at least take elements as value and quality into the equation as well. And that requires a shift of focus.
How do I deal with this topic? I simply start with observing what kind of estimate related things happening throughout teams and the surrounding organisation. And I qualify the effect (either increasing or decreasing) towards the desire to enable teams and organisations to build great valuable products. Examples of positive effects are: quantifying value, clear definition of done (quality), start with the why. Examples of negative effects are: automatically calculated three digit precise velocity, long discussions or detailed preparation before estimating, big chunks of work with a large time horizon.
Within the boundaries of given space to change, I try to get rid of the practises that are not helping us to focus on the right things as soon as possible. Next step is to discuss how to correlate value, quality and effort. I still think having some numbers available has some value, specifically for the teams to inspect and adapt. And not hiding them for the whole organization might be helpful to define a broader strategy, though for most “dashboards” I often observe that the (end user) value is zero, because there is only a focus on the effort estimates (and related deadlines).
So my conclusion would be that it is good to reflect on what goals you would like to achieve with effort numbers, or how that is helping you in understanding your value proposition towards your customers.
As last remark, because I have been dealing with this topic so many times during my career, my experience is that doing nothing with (numbered) estimates quite often is a better approach, given the wrongfully use of effort estimations in many organizations. On the other hand, I still think it is valuable to have discussions within your team about maximizing insight on understanding the problem you are going to address and the chosen solution for that. And for that the typically way with planning poker as used within agile teams is valuable, because is showcases different views (and pieces of information) and helps in getting an as clear picture as possible at that moment in time.
