1. Documenting an agile defect
Shirly Ronen-Harel
Oct 2010

2. What is an agile
level of defect
documentation?

3. Moving fast means also
to be able to document
defects to a level of
“just enough” and not
to much.

4. The level documentation
of defects in an agile
environment changes for
deferent types and
process stages related
defects.

5. Defects management is one
of Highly important process
to manage efficiently and
effectively.

6. Defects management is a
costly process : documenting
, reproducing , managing,
fixing , closing.

7. Managing and resolving
defects should be done in a
timely and efficient manner.

8. Outstanding defects can hold
up the release of
functionality to the business.

9. Defect should be related
to functionality – not
to a module.

10. Quality in : Finding ,fixing
and testing Defects Early
is a must.

11. deferent agile defects phases
Each phase holds a deferent
agile attention to the defect
documentation

12. Defect detected during peering , developer & tester.
Defect detected while continuously merging code.
Defect detected during acceptance tests of a user
story/epic/process/functionality.
Defect detected during regression tests.
Defects detected during customer lab testing.
Customer defect – from customer production.
Inherent defects.
And more

13. • Keep it simple – we don't have to document
all defects at the same level of details for
all deferent phases of detection.
• It depends on the value the documentation
holds against the effort of documenting it.

14. Tips
The far we move from the
developer who fix the bug
(or reproduce it), the
more detailed the defect
documentation should be
and the procedure should
be more official.

15. The distance between development
operations to those who supply the
defects to fix is curtail since
communication barriers hold expensive
waste potential
For example : tester located in an off shore team
should send detailed bugs with the most relevant
details to the group of developers. The flow of
communication may hold a time/ distance gap that
may delay the bug fix, reproduction on the bug
or even understanding it.

16. Other needs that defines the level
of documentation of a defect
Just enough documentation
level for the following.
each level require a
procedure of deferent
documentation details.

17. Defect that we can learn from in the future , will be
document to the level of learning value only.
Defect to add to automated tests, will be documented with
the relevant information.
Non reproducible defects , will be documented for future
use.
Defects to move to future versions should be highly
document to the level of ease of reproduction.
Peering defects/ check-in defects – may not even be
documented in case they are fixed on the spot.

18. Less detailed
•Check-in defects •Almost nothing – not cost
•Detected during tester – effective
developer Peering.
•Fixed on the spot
•Minor fixed on the spot
Co-located Distributed
teams teams
•High priority (?) •Off shore testing. Detailed
•Not fixed this issues and bugs
iteration/release
•Faster support operations
•Needs further
•Customer data defects
testing/investigation
•Regression •Customer regression
•Manual Bugs to add for production bug related to 3rd
automated testing level support
•Not fixed toady Detailed

19. Decide for each type of defect
the agile level of
documentation
• For example : since we don’t always have the
opportunity to talk to the defect reporter when we
want to fix the defect ,defects coming from
customer site , may need to hold configuration
details, customer data and scenario as a must.
• For example : defects related to an acceptance
tests may hold only a clear title to them since the
entire tests detailed is automated or already
documented into the user story acceptance.

20. Tractability
• Functional Defects
• are Always traced to a user story – functionality
– A defect is a user story child.
– It is born from a task testing or user story acceptance, regression,
sanity testing
• Or epic
• Not to a module
• Regression defects
– Detected at customer site or not related to a current open user
story
– Should be added to the sprint/ product backlog and prioritized as
part of a backlog item.

21. Therefore

22. Big defects list is out!

23. Functional backlog progress
and quality view – is IN!
• The focus is on the release
functionality quality . defects are only a
small part of it.

24. Big bug meeting are out, short
“just on time“ functional
health discussions are IN.

25. Defect view is not relevant
Two new views becomes more relevant :
backlog view & functional user stories
view.
• Release view drill to functional status –
progress , coverage, bugs.
• Backlog view – change management for the
entire release : functional and bugs.

26. Epic
In progress planed
actual remaining
User story task
task
task
defect
task

27. Epic
In progress planed
actual remaining
User story task
task
task
defect
task
Epic
planed
User story done actual
task
defect
task

28. planed
Epic actual remaining
In progress planed
actual remaining
User story task
task
task
defect
task
planed
User story In progress actual remaining
task
task
defect

30. http://codesion.com/images/collabnet-scrumworks-pro.jpg