Estimating Defect Effort
How do we capture the unknown effort required for defect resolution that arises from UAT?
A Jira ticket can be created but not sure how to estimate as the defect resolution could be a simple fix to something more complex.
Is it necessary to attempt to estimate the effort needed to fix a defect?
Once you have a defect report, there are analysis steps that the team can take to attempt to estimate the level of effort needed to fix the defect. They can analyze system logs from the UAT, reproduce the defect in a different location that may have more instrumentation, determine the underlying cause, and propose changes to fix the issue. In my experience, when all this necessary work to estimate the effort of fixing a defect is done, it's very easy to fix the defect.
Instead of investing this time, I've found it easier to have a policy in place. One option would be to establish a zero-defect policy. In a zero-defect policy, any reported and confirmed valid defect takes precedence over any other work before the team. The other option would be to prioritize the defect exclusively based on the report and an estimation of the impact and severity of the defect. If the defect crosses an acceptable threshold of impact and/or severity, it can be prioritized sooner. Otherwise, it can be considered among other work, such as developing product enhancements or technical work needed to sustain the product.
How do we capture the unknown effort required for defect resolution that arises from UAT?
Why bother? It's all still work in progress, and the Developers have made a commitment this Sprint to craft a Done increment of immediately usable quality.
The only purpose of estimation is for the Developers to get their arms around how much work they can take on before any commitments are made.
Rather than estimating defects it is more worthwhile to do an RCA (and triaging based on priority, severity and environment) as to why the defect came up. Why could we not capture it as a part of unit testing/QA testing? What did we miss? Should we update our Definition of done? Like Ian mentioned the only reason you might estimate the defect is to make that balance between bugs and features (considering your sprint velocity). I have worked with teams who estimate and do not estimate defects (they might put the estimate as 0 but will have some value at the back of their mind though).
In my opinion, your first mistake is treating a defect differently than a requirement. How do you account for unknown requirements that are discovered during the development work? Treat everything as a change that is needed to improve the product. By viewing everything equally, bias can be removed. I even advocate that you use the same form for capturing the information.
Why do you feel that an estimate is needed? What do the Developers think? What purpose does it serve to complete the exercise?
The effort is unknown even for the planned user stories ! thats why relative estimation came into practice.
IMO, Does the PO and developers see it has an Unrealised value(refer Evidence Based Management) adding to the Current value(refer Evidence Based Management) of the product, then team should prioritise to do it. What about the effort ? Doesn't matter. Team will find a way to finish it in sprint, whether it is simple or complex.