OrganIQ Blog

Resources For Your Learning

How not to Track defects within your Sprints

Now that the business team had started the User Acceptance Testing on the delivered functionality, Tim, the Scrum Master for the Mobility App team, needed to figure out how to capture and manage defects that the business folks will raise.
In the past, he had asked the business to prioritize the defects (P0, P1, P2, P3), capture them in JIRA and then assign them to the respective developers who would work on these defects once they had time available from their regular work within the ongoing sprint. He also used to have a daily defect triage call where all the developers working on the defects would join and discuss the status of the defects with business.
However, this process was time consuming and Tim wanted to try a less painful and faster approach to managing defects.

Tim’s discuss this challenge with his old colleague Edwards who had been implementing Agile at lot of smaller organizations where the turnaround time on defects is of essence.

“How do you manage to turn around defects so quickly to your customers?”, asked Tim
“We don’t track defects, none of them” responded Nick.
“What? You don’t track defects!!!” exclaimed Tim. He was flabbergasted.
“Yes” responded Edwards.

Edwards added further, “We fix defects real time instead of tracking them. Whenever a customer or an internal application developer or tester raises a defect, it gets immediate attention of the developer who wrote the piece of code in which the defect was found. The developer identifies the root cause of the defect, fixes the defect, carries out the build and deploys the build to the right environment where it is ready for testing by the person who raised it. If it needs a production deployment, it is done via the Continuous Deployment pipeline and a communication is sent back to the Customer informing of the fix”.

“Wow, that is awesome”, said Tim. “And how much time does it take to get this cycle completed?”, asked Tim.

Edwards explained to Tim, “We maintain our codebase in such a way that it is easy to fix defects. This ensures that the Average Bug Age (ABA) or Bug Cycle Time is very less. It varies from a few minutes for a small bug to a few hours if the root cause identification takes time for a more complex bug. But it hardly goes beyond a day or two in the most extreme scenarios.”

Edwards continued further, “We categorize our defects as ‘Fix immediate’ – for genuine defects, ‘Won’t fix’ – for non-issues and ‘New Feature’ – for something that is a new feature that has not been though of earlier. This process has enabled us to resolve defects faster, improve code quality and improve the effectiveness of the team while responding quickly to our customers”.

Tim was enthused with this new knowledge around managing defects and wanted to try this new approach as soon as possible with his team and get amazing results.
Have you ever tried something similar for managing defects? Or do you follow a traditional approach to tracking, fixing and managing defects?

Leave a Reply

Your email address will not be published. Required fields are marked *

Address

  • 336, 2nd Floor,
    Udyog Vihar, Phase IV,
    Gurugram, Haryana 122015 India
  •   info@organiq.in
  • +91-9968070799
  • +91-9818167629

Support

Partnered with

Partnered with
Copyright © 2017 Organiq. All Rights Reserved.