Should Agile Teams Estimate Defects?

Should agile teams estimate defects?

This a one question that teams often find themselves debate and my perspectives has changed over the years on this. The short answer is … it depends on your team context and what you are trying to achieve with estimation.

Estimation is a practice that helps Agile Teams forecast the effort that is required to get a task done e.g. deliver a feature and as such, it contributes to capacity planning for the team. This implies that would be impossible for a Scrum Team to forecast how much work it can complete within a sprint if the Product Backlog Items are not estimated.

Agile teams should endeavour to deliver a usable increment every sprint, and using the Definition of Done as a guide, all defects that are found within the sprint and related to the work being done in the sprint, should be fixed within the sprint. These defects do not require an estimate provided for it as the estimate provided for the related Backlog Item covers the effort to create an increment for the affected Product Backlog item.

However, the team might decide not to fix the defect immediately and as such the defect is placed into the Product Backlog for future consideration. Over time due to a build up of such defects, the quality of the product begins to degrade and this lead to customer / stakeholder complaints and support request. These complaints and customer request leads to pressure on the agile team to start fixing defects and technical debt PBIs alongside new features. The scenario just described represents 95% of teams that are faced with the estimation question in my experience.

There are 2 approaches that might be considered in the scenario described above:

Estimate all items including defects

Over the years I have come to understand that the purpose of estimation is for establishing a shared understanding of the work to be done for a PBI within the team. In addition if the team is to provide a forecast of how many items it can complete within the sprint, then all Product Back Items (feature and defects) should be estimated.

Reserve a portion of the sprint capacity for defect fixes and tech debt

Almost every single product backlog that i have worked contains tech debt items and defects. An approach might be to reserve a portion of the sprint timebox, for instance 10 percent of the time for fixing defects and tech debt. The implication is that the agile team works on as many defects and tech debt item that it can complete within the alloted timebox. e.g if the average velocity of a team is 40points a sprint and the team decided to reserve 10 percent of its capacity for fixing defect and tech debt, then the team should just plan for 36 points (40point minus (10% of 40)).

These approaches do not apply to teams that have adopted flow metrics in place of estimation and story points.

Are there any other approaches that you have experimented with to deal with defects within your sprints?

comments powered by Disqus