Question regarding defects
Hi all. I have a quick question regarding how a situation should be handed regarding defects. Lets say the team has commited for a sprint to develop the feature X, and the criteria of the definition of done must be that the developement have no defects.
At the end of the sprint the development was completed, and the feature has been tested in the test environment with no issues. The PO decides to release the feature X to production and then one week later, the end users report some errors.
The feature X user story was already marked as "done" so my questions are:
1. A new story has to be created to handle the defect?
2. or .. we use the same user story for the feature X and move it back to the back log?
3. I assume if its critical, the team must include it in the current sprint backlog and handle it right away, if not critical, then it can be incluided in the next sprint? Is this assumption correct?
Thanks in advance
Ad 1. I would advise to make a new PBI.
Ad 3. I would agree with your assumptions.
A user story is a placeholder for a conversation about a possible requirement. Once the work is understood to be complete then the conversation ends, and the story is retired. New conversations in subsequent Sprints, even if they relate to the same old requirement, imply a new story to represent them.
I put together a blog post on this topic in October:
https://www.scrum.org/resources/blog/zombie-stories-conversations-beyond-grave
Firstly, this scenario is assumtion only; apart its not advised to have exhustive set of tests for a given feature to ensure 0 defects, which in reality is impossible. So DOD(Defination of Done) of this kind should never be set.
Ideally, DOD should ensure the release should be free of Priority 1 and Priority 2 bugs(impact of bug on the system).
Now, how to handle the Customer bugs(Fault Report / Tickets)/ Internal fault reports.
--------------------------------------------------------------------------------------------------------------------
There are 2 major events which occurs at the begnning of each sprint life cycle.
1) Phase 1 Meeting- User Stories(items) Planning phase-1 meeting, for estimation( user stories are commited in phase 1).This phase includes multiple teams for a given project.
2) Phase 2 Meeting - Deriving tasks and sub-tasks for Commited user stories, furthermore a buffer time (free man hours) should be provisioned for each and every team in order to address tasks entering middle of the sprint.
Ex: Bug fix with very high priority, which demands deviation from planned tasks/activities.
what is buffer time in project management http://www.velaction.com/buffer-time/
------------------------------------------------------------------------------------------------------------------------
When should be a Fault report / bug should be considered as New User Story.
After a fault report analysis is done and effort estimation is quoted, its time to check if the fault correction can fit into current sprint or else it should be taken in the upcoming sprint.
If the effort required for the fix is considerably high, a new user story should be created for the same and its has to be a potential cadidate for sprint planning phase 1(Next sprint life cycle ofcourse).
-------------------------------------------------------------------------------------------------------------------------
Every Battle is won before its fought !!! ~Sun Tzu