What is an issue? It’s something smaller, less relevant, agile than a task.
To-dos, remember to, bugs, notes, suggestion, tickets, prospects, opportunities etc. are perfect examples of what Twproject call “issues”.
In Twproject issues are always related to a project or task, in this case a task is a collector of “issues”.
“Issue” is a common term in the programmer’s world, but issues usage is wider.
If you are used to bug-tracking, an issue can be seen as a wider notion than a bug.
Issues are a perfect solution for avoiding to create over complex tree structures; when your project has many sub-sub…sub tasks, you could stop creating new tasks, and start adding issues. In this sense an issue is a “task’s to-do”.
Issues are by far simpler to manage than tasks, so use them whenever you can.
In order to create an “issue” go to one of your projects and add one.
Just insert the description (task is assigned automatically) and save it; quite simple!
Have a look to the main information on issues:
Description: is the “body” of your activity. Write whatever you want, there is no limit in length. The description will be full-text indexed, so will be easy to retrieve issues.
Task: this is a key information. Every issue refers to a project, so that work done, alerts, reminders, security are inherited from the task
Assigned to: is the resource responsible to perform the activities described The assigned resource must be involved on the project too, so if you select a resource non yet assigned on the project, a new assignment will be created automatically (using project defaults). An issue can be “passed” from a resource to another; every change will be recorded on the issue history.
Severity: key information. Severity should impact on the order of execution; blocking issues must be resolved before critical or low ones. Severity is hard-coded and cannot be changed. By default severity is used for sorting issues.
Status: key information. Status is used for managing a resolution flow. The simpler flows are open -> close or open -> paused -> test -> close. You can modify statuses or create new ones. Statuses can behave as “open” (need activity) or as “closed” (do not need activity). Every status change is recorded on issue history.
Type (optionable): could be used to classify your issues.
Impact (optionable): reflects the impact that your issue will have on the project.
Do on: this is the date the issue should be done. If the issue has an estimated work, from the point of view of the operator work load, it is supposed to be done on that date.
Estimated work: is an estimation on hours of the work necessary to close the issue. Usually an issue should be small enough to be resolved within a working day, but this is absolutely not mandatory.
Tag: issues can be tagged. Tags are defined on-the-fly and can be reused once defined
Attachments: you can attach as many files you need on every issue. Drag and Drop your files on the issue row.
Comments: issues can be commented.
Click on the issue row to edit it:
you can edit multiple lines at once and save all with one click; ctrl+enter will save the current row.
Issue descriptions and notes both support clickable links and Twproject smart link.
Issue list is sortable by using drag&drop, but consider the “severity”….
If you have to insert several issues for the same project and the same assignee consider to use the “copy” button, to speed-up the insert.
You can register work done on every issue you are assigned to (or on the issues related to a project where you are assigned to as well); the work recorded will always be collected on the related task and will be “linked” to the originating issue.
Issues are extremely flexible, and can be used for different purposes; to access the full spectrum of functionality open the complete editor using the edit icon:
Up to 6 custom fields can be created on issues.
Sometimes what has been inserted as a small issue generates a new project.
For instance one of your customers require a new feature on an existing product, and after the analysis you discovered that this requires several days of work with several resources involved. In this case you could “upgrade” the issue to task. The originating issue will be closed and a new task (as child of the current one) will be created.
Another aspect of issues that increases usability is related to security. Permissions required to insert issues are distinct from permissions on task, so for instance you can create security profiles with read-only permission on tasks and creation permission on issues: we can call this set of permissions “customer” and create an ad-hoc role. Assigning customers with this role will allow them to insert issues right at developer’s hand; it also facilitates creation of a “backlog” that is very common on agile methodologies.
A smart Scrum team leader that is using Twproject remarked the following: suppose that you are a developer and are assigned on a set of issues, on which you do your development and record development time spent. You did with the team the initial evaluation of needed development time, and suppose for a particular issue you decided to put 10 hours.
You recorded time elapsed, but as happens in real life all the time, you have to reschedule some of the issues. Now the users remarked that it is quite cumbersome to reason on the base of estimated duration – worklog done, because all you are actually focused on is time remaining to close the issue.
So, here is the change: by clicking on worklog done, a time remaining panel appears, and its editable right there.
This little practical change can make a difference; think when you planned 34 hours, and have done 27:30, how many hours to go, will it suffice.. I don’t want spend time on that: just let me reschedule that.
If you want to link directly to an issue via a URL, use: http://[your root]/issue/X where X is the ID of the issue.
Issues are a perfect solution for Agile approach to project management and for planning your work. See how on the following sections.