How to use bug tracking to track tasks and bugs

The purpose

We do use bug tracking tool Bugzilla for company project management needs. This has been proven by years of experience. Using bugzilla helps us to make the development process clear and transparent for the buyer (customer), project management, and developer.

Buyer advantages

  • Track real time progress of work
  • Estimating time & cost: at any moment, bugzilla can answer questions: (a) What are current project costs. (b) How much time would take to develop feature X
  • Direct control to the "next bug" selection process by setting appropriate priority/severity

Rules

There are a few simple rules which are important when you are working with any kind of bug tracking system. May be the mostly important are three rules:

Most important rules and facts

  • Assignee is the single only responsible person for the task.Conclusion: if you do not know why bug is assigned to you, its a good indication that it must be reassigned to someone who can continue. If you finished your part of work, assign bug to person who ordered the work. If work is finished, close the bug - do not keep thousands old and stale bugs open.
  • Every bug is a work on a single task for a single person. If more tasks or more people involved, bug(task) must be split to a few smaller ones.
  • This is advice for customers: when you answered the question, and bug was assigned to you, please do not forget to reassign bug to developer, otherwise developer would not know that he should start working on it. You should not rely on a mail notifications: as you see, the rule is that person is responsible for a bug only when bug is assigned to this person, otherwise, you are responsible for a progress.

Other rules and recommendations

  1. When you start working on task, you must mark at as ASSIGNED (#2 on picture):
    This is visual indicator for others (There are situations when tasks in NEW state will be taken out from being assigned to you if you don't work on them). This also means that if you see that bug/task is ASSIGNED by someone, that would normally require to ask permission of assignee if you would like to participate in it. Normally, when bug is assigned, we expect that developer will put short work plan, estimate time (or time needed to provide estimate).
  2. Report every finished stage. Normally, shortly, at least once per day - report what has been done, why and how. Allow some detail, but not full - only to overview that work is done in which direction.
  3. When work is finished, please submit report of what has been done, why and how. Don't post short mesages like "Done" or "Fixed" - this is not enough detailed description of even small fixed bug. Report should include short summary of work done, link to VC revision number, - usually link to trac Timeline entry for this changeset.
  4. In a project, after requirements has been discussed, every separate task of the low level of abstraction should be added as a separate task(bug entry) in bugzilla.
  5. There should not be a big tasks which take long 90 Hrs for example. Normally, task is implemented during 1-10 hrs. All tasks which take longer needs be split to sub-tasks.
  6. You should break task to subtasks when its assumed to be implemented in parallel by different people. There should not be situation when 2 people are responsible for a single task
  7. Even if you finished some task or bugfix and it was not mentioned in bugzilla, you have to submit report to bugzilla for accounting reasons.
  8. when customer submits a bug, it will be assigned to default owner. You should reassign it to yourself or to me, or to some other person which is working on that.
  9. if there are questions on some task / bug, please reassign the bug to the person which will take care about it.
  10. When you have a very long list of bugs assigned to you, but can not work on any of them due to bugs being blocked by other bugs or waiting for something to happen, please mark this in subject. Like (blocked), (waiting for Event to happen), (wait). This will be very helpful for a customer to see if you have enough actual work planned or not

Estimation process

Introduction

Estimation is very important for customer because it allows to plan budget, deadlines, advertisement, new feature announcements and other business related things. So, every developer of Halogen D.G. must learn how to estimate correctly, and always improve his skills.

Learn to plan your work

For each task you always should try to put estimates. Estimating is not easy, but it is very critical for many projects. The more you try, the better your skills will be.

There are good books on estimation, for example "Rapid Development", "Code complete", most of XP related books are talking about estimating techniques. Books are available in Halogen D.G. book shelves.

Questions

This document is a work in progress. The rules which you see are a result of our 10 years experience of using bugzilla. This document does not cover all tips & tricks, so we constantly updating and describe best approaches.

Please feel free to ask me any additional questions, or tell me the corrections which you seems to be reasonable to be made to this document.

One question which you should never ask is about how to change your password.

Recommended reading

Comments: 0

No comments.

Post a comment

Guests can\'t leave comments.