How can I set an event type to not show up as scope change on the burn down when it is a defect in the code done during the sprint

Question

We estimated the story task 'As a developer, I will code the create user functionality' to include all coding for that unit of work including fixing any bad code that was written.

We estimated story task 'As a QA associated, I will test the create user functionality' to include all testing for that unit of work including defects found during execution of the task.

We want to track open defects and their progress.  Why then would a defect due to faulty coding that is identified during the sprint and must be  fixed during the sprint show up on the burn down as scope change. This is not a scope change.  We never assume that all code will have no defects.  The goal of the sprint is to make sure the code will function at the end of the sprint.

Melissa Thornton · Answer

Thank you.  I just added a defect subtask to a story 'As QA tester, I will test the create new x functionality'.  It did not result in a scope change on the burndown.  the only scope changes shown are when I added story tasks yesterday.  I am a happy woman

burdown.docx

Geert_Graat · Answer

There are many good reasons to track defects, I am not saying you should not do that at all. I was just trying to explain the philosophy behind Agile working, to illustrate why the behavior you see makes sense from that perspective. That should not stop you from adopting your own principles or requirements.

Regarding the subtask (or sub-bug): they result in a scope change as well.

Melissa Thornton · Answer

Thank you Geert.  In response to your question about tracking defects in a sprint.

From a people and task management perspective it is important to know what you are up against.

From a people perspective you can track number of defects a particular developer delivers and the reason for the defect ie bad requirements, bad code, no unit test done etc.

In addition when developing an entirely new piece of software you could have a large number of defects, multiple testing team etc.  We should not expect the QA Manager to track everything going on manually when we purchased a system to do that.

Also entering your defects into JIRA as a unit of work gives you the ability at the end of the sprint to close the sprint and move defects that you decided not to address within the sprint automatically back to the 'backlog'.

Today I will be test using a 'subtask' type of Defect and add the subtask to the original story and see if that results in scope change as well.