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

[Melissa Thornton]

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]

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

[Melissa Thornton]

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. 

[Geert Graat]

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.

[Geert Graat]

Hi,

When you start a sprint, the scope is locked down. If an issue is added to the sprint after that, be it a defect on functionality realized in that sprint, or a support call that needs immediate attention, it is considered a scope change.

The easy answer is that JIRA cannot determine the difference between a defect or a support call that is added to a sprint and therefore considers everything a scope change.

The underlying question to this is: why do you need to track defects in a sprint? In a true agile, cross-functional team, a potentially shippable product is realized by the team. If the team finds a mistake, it is corrected (rather than logged). If they make a lot of mistakes during the realization, they probably need longer than anticipated or cannot finish everything. At the end of a sprint the team has a retrospective and can investigate why that happened (task was more complex than estimated, team lacks certain skills etc.), in order to improve performance for the next sprints.

Given that JIRA Agile is designed to support the "true agile" team, I think it makes sense to list defects as scope changes. I absolutely understand your reasoning as well, but in this case you use the tool slightly different than intended and therefore you have to take some things for granted.

So, long story, I hope it makes sense. 

Regards,

Geert