Show all posts
6 years ago

Agile Teams and Bug Analysis

Have you ever asked the question, ‘When are we planning to do bug analysis?’ in a Sprint retrospective? This is one of those questions that is thought about but not asked during the initial iterations of Agile projects. Also, unfortunately, this question is forgotten over several subsequent iterations and asked during the end of projects when it becomes too late. By ‘bug analysis’ I mean the analysis of a group of bugs to study factors such as distribution of defects on priority, severity or application module as well as other aspects such as reproducibility or dependencies.

Several years ago, I became cognizant of asking this question. It was never an ideal situation for us to deliver bug free production ready software at the end of iteration. I am sure, even these days delivering production ready software at the end of iteration is not very common across projects. It is a tough goal. If you have achieved this goal, I should say you belong to a high performance team. In all general circumstances, bugs do accumulate, get prioritized, and fixed. Is this an adequate approach to execute projects? Don’t we need to identify the right time to initiate bug analysis and have a consensus on the frequency of performing bug analysis?

The first time when I asked this question the answer was, ‘The product is not stable enough to perform bug analysis.’ That took me by surprise and triggered additional thoughts. I asked further, ‘Should we wait for the product to become stable to do bug analysis? Or should we perform bug analysis in order to find ways to make the product stable? Also, shouldn’t we use visual boards to display bug trends and analysis so that the team understand not only the progress of user stories but also trends on product quality?.’ That’s when our approach matured to the next level.

Essentially, it makes sense to have a sizeable number of bugs to perform bug analysis and it depends on your project. Also, how detailed you perform bug analysis depends on your project as well. Bug analysis can reveal variety of useful information such as distribution of bugs across modules, distribution in terms of bug priority or severity, distribution of bugs in terms of bug status etc., The earlier we analyze and understand these parameters, the better it is for us to improve product quality.

Thinking of bug analysis late in the game seldom yields efficient measures to improve product quality. Next time when you talk to your Agile team try to trigger this question. Am sure you will come across interesting responses.

All said and done, bug analysis is a practice that can yield results in Agile projects. Do you use a visual board that displays bug analysis results and trends in your work area? What has been your experience in performing bug analysis? How frequently you do it? Is it beneficial?

Raja Bavani is Technical Director of MindTree’s Product Engineering Services (PES) group and plays the role of Product Engineering Evangelist and Agile Coach. Check his Product Engineering blog.

  • Rafajagua

    Hi, it is a excellent post. On my teams, we did meetings to talk about bugs. On the team’s boards, bugs are registred with pink post-it, and stories are yellow. For each team, we analise and propose a meeting. The frequently of meetings is defined by members of teams. They saw the frequently and account of bugs and/or the impact of the bugs on system. We use a “root cause analysis” and we try to improve the process and the people. The primordial lesson that i saw is: Show the bugs, keep a historical data of bugs and conscientize the team to talk about a quality. The often of meeting can be defined by the team.

  • Aquarius

    Hi Raja,

    We end up iteration having potentially shippable (=>tested + no bugs) software very often (in ~70% cases). This I believe is a right vector that is impossible to achieve without having focus on automated testing and good coverage with unit tests, etc. Otherwise (testing manually) will increase investment heavily.

    Regarding bug reviews: we do “missed bugs retrospectives” to analyze how come this or that bug had been missed and what we can do to avoid those popping up in the future. Usually release-wise, so every ~2-3 sprints or so.


  • Raja Bavani

    Dear Rafajagua,  Thanks!  The approach followed by your team is very practical. Keep it up!

  • Raja Bavani

    Dear Aquarius,  Delivering potentially shippable product in ~70% cases is the way to go!  Good to know that you conduct ‘missed bugs retrospectives’.

Try for free

Account url: *
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy