Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start 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

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

When is a Defect not a Defect?

No description
by

karl lock

on 27 January 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of When is a Defect not a Defect?

When is a Defect not a Defect?
Agile
It is important to appreciate that programming and testing need to be conducted together rather than after one another.
Issues
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.
Bugs
A defect is a bug if it is identified after a user story has been completed and accepted by the product owner.
Collaborate
Product Backlog
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
Full transcript