Thursday, April 18, 2013

Defects During Sprint


Observations

During the sprint, since the developer “owns” the entire duration of the sprint, it’s impossible to say that there’s a defect because the developer may retort that they just aren’t finished with that task yet. 

  • If the tester observes functionality that is inconsistent with the acceptance criteria for the story, the tester needs to log that “observation” (in their personal spreadsheet or other tool) and point it out to the developer immediately, hopefully giving the developer time to complete the functionality in the manner that the Product Owner expects before the end of the sprint. 
  • If the observation is not “satisfied” by the last day of the sprint, then the observation is “converted” to a defect, which means that the tester opens a true defect in the defect tracking system, and removes the item from their observation log (The observation to defect conversation rate is a metric that will be tracked). 

Defects are created in one of two ways
  • Observations are converted to Defects on the last day of the sprint. 
  • Defects are discovered post-sprint. 
  • Once logged, defects may be treated one of two ways: 
  • Bundle several small defects into one user story. 
  • Map one-for-one: one major defect to one user story. 
  • For teams that are not as strict about only working on user stories, the team may try these approaches: 
  • Allocate a “fix defects” story & task with a specific number of hours during sprint planning. Developers fix as many defects as possible within the hours associated with the story. 
  • Allocate one day per sprint for the entire team to work only on fixing defects. 
However, remember that postponing the defect fixing to future sprints is not a right approach. We need to log the defects if the code is not meeting the acceptance criteria and/or not meeting the definition of done. This clearly shows that we are trying the deliver the potentially shippable code instead of shippable code by end of the sprint. We always need to try to deliver the shippable code all the time than potentially shippable code. Don’t you think that the feedback cycle ( inspect <-> Adapt in agile world) increased to 2 sprints instead of one sprint? Larger the feedback cycle, lessor the improvement is …

As a scrum master we need to arrest this anti-pattern so that the end customer will get higher business value at the end of every sprint.


No comments:

Post a Comment