“What was that thing you were going to follow up on?
“I’m trying to remember… It must not be that important”
Ok, so you clearly wouldn’t give up so easily, but what about all the other requirements issues and discussed items that no one remembers to take care of? These become the ghosts that haunt your project.
Most people think issue tracking should be used to track software bugs after a product is released. Some people use them to track bugs during testing of the software. Some brave souls may even use issue tracking to defects during software development. However we rarely, if ever, see issue tracking being used at the start of a project, during the requirements phase.
We have found that this is a time when issue tracking is absolutely critical. When you have multiple people in multiple sessions all generating tasks to follow up on with regards to the requirements, there is simply no way you can effectively track those issues without an issue tracking system.
Some of the benefits of an issue tracking system are:
1) Track the issues coming out of multiple review meetings so that no issue ever gets dropped
2) The current status of all issues is known by project management
3) Define a single owner who must resolve the issue (usually finding out how something has to work)
4) Track the history of discussion around an issue
5) Ability to enter the development phase earlier with a known set of issues rather than requiring a perfect SRS
There are many more benefits than these, but these are certainly enough.
When issues are tracked at all, the most common way we see issues tracked is through excel spreadsheets.
For small projects Excel spreadsheets can be a reasonable tool. However as the project size gets beyond 5 or 6 team members then using issue tracking becomes imperative. Either one person has to be responsible for collecting all the status information on issues or everyone writes to a shared file. In the first case, this creates a delay in pushing out information as it becomes a full time job just to do data entry on the issues. In the second case, the first time someone overwrites the master sheet or there is a merge conflict everyone will realize that there is a serious problem.
Integrating issue tracking into the requirements process is painless and actually saves so much time and energy it becomes a necessity. It is one of those applications that you wonder how you ever lived without. Depending on the ease of use of your issue tracking system, you may be able to enter the issues during a review session itself. Some of the issues may be with specific requirements, other issues may just be action items related to the requirements process.
As people get resolution on issues or have email conversations about an issue, those artifacts are attached to the issue so that anyone can see the status and a history of the issue is maintained.
One last thing, don’t get too caught up in states, configuration, issue types and workflow. The key is to have the triggers to your memory that an issue even exists. Keep the process and workflow simple and use the issue tracking system simply as a list of overall requirements action items. If you do this, you will find yourself ensuring that nothing slips through the cracks.
