Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
When is a Defect not a Defect?
Transcript of When is a Defect not a Defect?
It is important to appreciate that programming and testing need to be conducted together rather than after one another.
An issue is a problem that occurs during the sprint and is tightly coupled to a user story that has not yet met its definition of done.
A defect is a bug if it is identified after a user story has been completed and accepted by the product owner.
An issue is not a product backlog item. Instead, an issue should be seen as part of the evolving acceptance criteria for a user story.
Through collaboration bugs in the code can be found early, fix / amended without the need to document the bug as technically the code was never DONE.
Remember an increasing number of bugs generally mean there's a problem with quality, maybe there's a bigger issue to deal with
So what happens when your issues slip through the sprint?
This is were your issues become bugs and then generally they are fed back into the Product Backlog to be prioritized.
In the Agile world working together help's to deliver regular bite sized offerings with reduced risks but it is reliant on the self discipline of the team.
Typically picked up by users (post-release)
or via an automated regression test
(following the implementation of
subsequent user stories).
Is a Bug a Story or a Task?
In my opinion a bug is a task.
A story is something that is valuable to the user
A task is a step to produce that value for the user
Not that it's not valuable to the user, more that there are steps that need to be carried out to produce the value to the user - i.e. the fix
What does this mean to us?
Testers and Developers review unit tests together
Developers, Testers, Product Owner and BA's working together on acceptance criteria / stories
Retrospectives - sharing what went well, what didn't go so well & ideas for improvements
Automated smoke tests as part of the build process
Teams owning the products - not just handing off to the business
Definition of Done
A DoD is a list of important concepts.
It sets out the requirements that software must adhere too where as Acceptance Criteria are applicable to specific user stories.
It binds what the Product Owner wants to what the development team delivers
This could be as simple as - “Product Owner has to agree that the feature is done”
By Karl Lock