Is Re-estimating a Sign of Incompetence?
Emerging information creates a trigger to re-estimate, but is re-estimating a sign of incompetence? Let us take a look at this aspect in the article.
Among the multiple categories of knowledge, let us start spending some time with ‘Priori’ knowledge and ‘Posteriori’ knowledge. Both are Latin phrases used in philosophy to classify knowledge and justification based on empirical evidence/experience.
A priori knowledge is knowledge free from experience and obtained through analyzing concepts. This is also called ‘Knowledge-before-the-fact’.
A Posteriori knowledge is a knowledge that depends on empirical evidence. This is also called ‘Knowledge-after-the-fact’.
A good example of the above-mentioned types of knowledge is sizing a Product Backlog item when none of the work has started qualifying for Priori and when a Product Backlog item is sized relatively in comparison with several Sprint worth of items are forecasted and implemented earlier qualifying for a Posteriori.
In a complex world filled with a lot of unknowns over knowns and as information emerges every time with working software reaching the hands of the customer, the need for re-estimation becomes inevitable.
“Even with a well-intentioned and highly communicative team, it is possible that the results of an iteration could be found worthless when shown to the broader organization or external users at the conclusion of the iteration.” ― Mike Cohn, Agile Estimating and Planning
This is fine with most of us. But why then re-estimation is treated always as a bad thing?
We need to understand the trigger for re-estimation first. It is primarily due to
When it comes to over-estimation, there is a strong need to understand Dunning – Kruger effect or otherwise called ‘Confident Incompetence’.?It is a type of cognitive bias that causes people to overestimate their knowledge or ability, particularly in areas with which they have little to no experience.
Connecting Dunning – Kruger effect with Cone of Uncertainty gives an interesting dimension of the time and exposure levels Developers do have when they estimate.
领英推荐
The time frame considered for estimation, the time of estimation, the individuals involved in estimation, and the purpose behind such estimation answer all the questions emerging due to Confidence in Incompetence.
If the estimates are for a Sprint long or for a couple of Sprints put together, then it shouldn’t be a problem to stay transparent, inspect and adapt based on emerging information. The real problem comes with long-term planning, knowing there are unknowns waiting at the doorstep to jeopardize the success meet of estimating into the future. We are left with no better choice other than to accept reality and lookout for opportunities to re-estimate.
Yes, it is incompetence from the perspective that we are unable to embrace uncertainty and work in tandem with complex adaptive systems but not from the technique or tool used for estimating such time range.
The latter factor for re-estimating (perfecting) the past to look very much alike is also incompetence from the same perspective that we are not in a simple domain to repeat the same steps every day and end up yielding the reproducible steps every time.
It is by our mindset to acknowledge the abstractness with which we learn and adapt into the future, we show incompetence. But unfortunately, we blame each other on the ability to predict the future accurately. (how big an oxymoron it is ??)
Whenever there is new information emerging through customer collaboration and feedback, re-estimation comes to the rescue for the Developers. It is easier said than done because the Developers always have a hard time working with their Stakeholders.
The Stakeholders simply don’t accept changing the estimate and for them, it's changing an agreement instead of a simple estimate.
It’s useless for Developers to spend time defending the need for re-estimating with the Stakeholders. This is primarily because Stakeholders confusing estimates with the agreement, commitment, contracts, and so on.
This approach by the Stakeholders instills fear in the minds of Developers and creates an environment where re-estimating the Product Backlog Items (PBIs) are seen as a sign of Incompetence. Both the Scrum Master and Product Owner should take this opportunity to help Stakeholders interpret the growing need to re-estimate in the right sense.
Wrap Up!
The game of Agile is not about building a base for estimates or realistic forecasts. Rather it is about the game of staying resilient with uncertainties and changing customer/market and business expectations.
Stakeholders and Management should never spend too much energy on the psyche behind how to look at re-estimates. Instead, it should be the other way round of Stakeholders providing all that the team needs as shared understanding and empowerment to self-manage and continuously emerge serving value to the customers.?
CEO & Co-Founder | Accredited Trainer & Consultant | PMP, ITIL?4 MP, PRINCE2?7, PgMP? @ Woloyem
1 年thanks for sharing!
Scrum Master - NAB
3 年It would depend. If you are re-estimating without reason tends to show incompetence. I tend to get teams to share and document the assumptions used in developing an estimate, then if they learn that an assumption is wrong they have justification to re-estimate. For me, it is more about showing where the learning has been applied.
I help teams deliver better products
3 年I believe that the purpose of estimates is to forecast, how much work could we potentially bring into a sprint ?, based on our velocity, what could be a potential timeline for completing a release ? It cannot be taken as a guarantee of what exactly could be the outcome. In that context, if our estimate is wrong, we learn to estimate better next time and I would not focus too much on re-estimation.
Agile Coach at Fidelity
3 年Absolutely agree with your conclusion. Well, in a service based organization it’s the maturity of customer to keep the contract towards value delivery vs defined product so that developers work towards building the value to customer than sticking to estimate and accomplishing “what’s agreed than what’s needed”