Agile Walk Through - Free Beta

Bugs

 

Bug is a term used to describe encountered situation when delivered result doesn't behave, look or feel as it should.

  • Show-bug

Life-cycle

Bugs life-cycle is similar to the one of tasks. Verification/rejection of bugs is configured per project.

Create

Since bug is defined as something which doesn't work as it should, AWT encourages to create the bug for the requirement which describes correct target result.

Associating a bug with a parent requirement brings following benefits:

  • You track whole time spent on work on particular requirement - implementation of tasks and fixing of bugs, so that you compare it with the initial estimate more precisely (please note, that that requirement's estimated time is composed of tasks estimates, and not bugs, whilst spent and remaining time - is of both tasks and bugs),
  • It's easier to find the most appropriate person to fix the bug since you can see people who were working on this requirement's tasks,
  • It gives information to make better decisions if certain bug should be treated as such or it's rather improvement that should be transformed into a new requirement.

However it's still possible to create bug without selecting a requirement, for the cases when person reporting the bug doesn't know the product design well enough and can't find appropriate requirement. Still it's strongly recommended to associate it with requirement before starting working on it.

  • Bugs-list-not-linked

Assign

Depending on organization of your team, responsible person can assign bugs to appropriate members, or they can take bugs themselves.

Work

Owner can work on any of his tasks or bugs. Recommended practice is to change the state of the bug when work on it started (especially when it wasn't assigned to anybody) to prevent other team-members starting doing the same work, informing them about your current occupation and finally to facilitate time-tracking. This state is called in progress.

When you done with work on the bug and there's no more work to do you fix the bug, and when there's some work remaining you pause it. Whilst making any of these actions you can enter time you spent on the work.

Verify

When the bug is completed (fixed) it should be verified (unless project has configuration not to verify bugs). Verification is usually performed by the person who reported the bug.

Cancel

It is possible to cancel bug at any time (e.g. when duplicate or not reproducible bug was submitted).

Copyright 2007-2010 Agile Walkthrough