You probably have a defect or issue tracker for your project (if you don’t, you should): Quality Center, Bugzilla and Jira are popular choices.

When you set up an issue tracker, you have to set up the workflow or modify the default workflow: you need to specify:

• Statuses: the list of states in which issue can be, including the initial and final states
• Transitions: the allowable status changes
• User roles: who is allowed to make each transition

Here is the default workflow for Jira (you can find it at: https://confluence.atlassian.com/display/JIRA/What+is+Workflow)

This workflow has 5 statuses and 12 transitions. It isn’t shown on the diagram, but by default, Jira allows all users to execute any transition, so for the purposes of this discussion, it has just one user role.

Soon after you set up your issue tracker, the Test team will probably ask for new statuses ‘Ready for Testing’ and ‘In Testing’. The Deployment team will ask for ‘Ready for Deployment’ and the Support team will ask for ‘Under Investigation’ and ‘Awaiting Customer Information’. Maybe someone will ask for ‘Awaiting UI approval’. If you agree to all these requests, you very quickly end up with a large number of statuses. And for each one, you need to manage the transitions between them and the roles allowed to make those transitions. That can quickly become a lot of work.

It can also become time-consuming for reporting: you will probably have unproductive debates over whether or not you should count ‘Ready for Deployment’ as an Open defect or a Resolved. These discussions are a distraction from the real work of getting the defects fixed. Only you can decide which statuses are entirely necessary, but always question the need for a new status, and keep the number to the minimum.

Some other suggestions:

• Minimise the number of user roles – unless you have some compelling business reason to restrict transtions, allow anyone to make any allowable transition. It is much easier to manage and on the rare occasion that someone makes a transition they shouldn’t, education is far more effective than locking down the system. Virtually all issue trackers log the history, so it is very easy for anyone in the team to figure out who messed up and correct it.
• There should be just one final status, and it should be called Closed. If you have more than one final state, you have to spend time reminding people and answering questions about it – it just confuses people.