Update the issue status
In this video you will learn about issue statuses and best practices for using them.
Issues are different from tasks in that an issue represents unplanned work.
In a request queue, they are usually referred to as requests, but they are still an issue object.
In a project, they could be a request to do some work beyond the current project plan, like add a new line of shoes to the fall catalog, or a potential problem to deal with, like the printer is two weeks behind schedule.
When you have open issues on a project, they represent a potential risk to the project schedule or budget, and should be quickly assigned to someone who can investigate them and take or recommend appropriate action.
You would not normally set the percent complete on an issue you鈥檙e assigned. If your project manager agrees that the issue represents work that should become part of the project plan, the issue should be converted to a task, or it can be given a duration and planned hours.
Click the link below to see a tutorial on how to convert an issue to a task.
In cases where the issue should be worked on, but not as part of the project where it was reported, it could be converted to a project and planned accordingly.
Click the link below to see a tutorial on how to convert an issue to a project.
Issues are very important. A project cannot be marked as complete if there are any open issues. Best practice is that the issues list be checked daily by the project manager, and anyone assigned to an issue should update the status daily.
Here are the standard status settings for an issue. Keep in mind that your system administrator can add or rename issue statuses to meet your organization鈥檚 needs.
New and unassigned means that no one has been assigned to this yet. It might be in the process of being reviewed by a manager. You can check the entry date to see how long ago it was created.
New and assigned means that no one has started on this yet, but at least it鈥檚 been assigned.
Again, you can check the entry date to see how long ago it was created.
In progress means someone is working on this.
Again, you might want to check the entry date to see how long ago it was created.
Issues should not be in progress very long. If there鈥檚 more than a little work to be done, consider converting it to a task or a project so the work can be planned. Sometimes you can鈥檛 quickly take care of the issue. That鈥檚 when you might want to use one of these statuses.
On hold means you know about it, but for some reason you can鈥檛 decide what to do about it yet.
Awaiting feedback equates with on hold, but it also indicates that you鈥檙e awaiting feedback from someone else before you decide what to do with it.
Both on hold and awaiting feedback are considered open issues and will prevent the project from being marked as complete. Won鈥檛 resolve, closed, and resolved all equate with closed, so they won鈥檛 prevent the project from being marked as complete.
The reason to use one over another is mainly for your organization鈥檚 reporting standards. In a request queue, issues may be used more like to-do list items.
The need to convert them to a task or a project may be different, but the practice of updating the status in a timely manner is still very important.
Key takeaways
- How are issues different from tasks? Issues are different from tasks in that an issue represents unplanned work. If an issue needs to be included as planned work, it should be converted to a task or a project.
- Why is it important to quickly review issues in a project? When you have open issues on a project they represent a potential risk to the project schedule or budget, and should be quickly assigned to someone who can investigate them and take or recommend appropriate action.
- What about issues in a request queue?: In a request queue, issues may be used more like to-do list items. The need to convert them to a task or project may be different, but the practice of updating the status in a timely manner is still very important.