This tutorial takes about 30 minutes and is intended for all users of Ketura.
Every organization has a myriad of small-scale goals that need to be accomplished. These goals are recorded in Ketura as issues. Because it is so easy to work with issues, the best way to use Ketura is to create an issue for everything that you or your organization wishes to do, and even for the things that it might wish to do. An issue can always be reviewed and rejected later.
For background information on issues, please see the Ketura Tour Step 2: Issues.
This tutorial covers:
- Reporting a new issue;
- What happens when an issue is created;
- Recording additional information about an issue.
This tutorial assumes that you have the example database installed. This database illustrates various Ketura concepts applied to a fictional firm, XYZ, Inc.
In this tutorial, an issue is created to cover the creation of a set of management reports for XYZ’s forthcoming monthly management meeting.
1. Go to the Report a New Issue page
Ensure that you are logged onto the example database as Andrew Wright, XYZ’s administrator and office manager. Andrew’s log on id is ‘aw’, and the password for this account is the same as the password for the ‘admin’ account that was provided during the installation of the Ketura server.
Check that you are viewing the Home Page for Andrew Wright. If not, click the Home navigation tab, near the top-left of the page.
Follow the New Issue link, near the top-right corner of the page.
This link is also conveniently present on many other Ketura pages.
- The Report a New Issue page appears, ready for you to record your new issue.
2. Summarize the issue
An issue’s summary succinctly describes the nature of the small-scale goal that the issue is about. This summary will be shown alongside the issue’s unique id wherever the issue is listed in Ketura.
- In the Issue summary text field, enter ‘Monthly management reports for January should be compiled’.
For consistency when creating issue summaries:
Keep the summary to a single sentence.
Do not place a period (full-stop) at the end.
Describe succinctly how things would be if the issue were to be resolved, rather than the current situation.
For this issue, the issue’s summary is therefore better expressed as ‘Monthly management reports for January should be compiled’, rather than ‘Compile monthly management reports for January’.
3. Choose what the issue is about
An issue’s topic identifies what the issue is about and serves as a way to categorize the issue. XYZ has decided to create a topic for each of six main areas of its operation: internal company administration, audit and tax work (one topic for each), maintenance of its website, marketing activities and the asset tracking system it is developing for one of its clients.
The creation of monthly management reports is an administrative function for XYZ so, for this issue, it makes sense to select ‘General’ as the issue topic.
- In the Topic drop-down list box, select the topic General.
Further categorizing what an issue is about
To further refine what an issue is about, issue topics can have a number of subtopics (or topic versions). However, this might not be appropriate for some topics and having subtopics is therefore optional.
For example, a book publisher might create a subtopic for each edition of its books. Thus, a typographical error could be recorded for a particular edition of a particular book. A software company might instead use this field to record the version of a software component for which an issue is reported.
XYZ has decided that the ‘General’ topic does not need further categorizing and, therefore, the Reported in drop-down list box and associated build field are not displayed.
4. The type of issue
An issue’s type is used to identify what sort of issue is being recorded. XYZ has decided to create the following types: ‘Administrative Activity’, ‘Problem’, ‘Meeting’, ‘Documentation’, ‘Enhancement’, ‘Review Note’, ‘Requirement’ and ‘Ongoing Activity’. For this issue, ‘Administrative Activity’ is most appropriate.
Sometimes, an issue’s topic (in this case, ‘General’) and type (‘Administrative Activity’) are quite similar. The distinction is clear if you think of an issue’s topic as saying what the issue is about, and its type as indicating what sort of issue it is. Here, the issue is about a general function in the company, so its topic is ‘General’. In another company, the same issue might just have easily been more precisely categorized by assigning it to a ‘Finance’ topic, or something similar. The issue is a request to perform an administrative activity so, in the example database, the ‘Administrative Activity’ type seems most appropriate. Another example would be if we were instead creating an issue to record a defect in XYZ’s asset tracking system. In that case, the topic would be ‘Asset Tracking System’ (because that’s what the issue is about), and the type would be ‘Problem’ (because that’s the sort of issue that is being created).
- In the Type drop-down list box, select the type Administrative Activity
Throughout Ketura, wherever lists of issues are shown, it is possible to filter the lists by type. This makes it easy, for example, to view only those issues that are related to administrative activity.
5. The importance of the issue
An issue’s severity indicates the importance of the issue as perceived by the person experiencing the problem (or making the request) that resulted in the issue being created. Thus, if a customer reports a problem, any consequent issue should indicate the severity of the problem as the customer perceives it.
The severity of the issue is for information only, and does not necessarily affect when, or even if, a manager might subsequently schedule the issue to be resolved.
If importance is not an appropriate concept for your organization’s small-scale goals, it might be more helpful to think of severity as reflecting the urgency of an issue as perceived by its originator. The available severity types could then be configured to reflect this. For example, they could be set to ‘Critical’, ‘Urgent’ and ‘Not Urgent’. XYZ has decided to use the default severity types, ‘Critical’, ‘Important’ and ‘Minor’. However, you have the option to create whatever severities suit your organization’s requirements.
The creation of XYZ’s monthly management reports is regarded by the relevant Partner as being important so, for this issue, the severity will be set to ‘Important’.
- In the Severity drop-down list box, select Important.
Throughout Ketura, it is possible to filter lists of issues by severity. This makes it easy, for example, to view only those issues that are perceived to be ‘Critical’.
6. Explain the issue in detail
Because an issue’s summary has to be succinct, it is probable that further background information needs to be recorded for the issue. An issue’s Description field is the ideal place to do this.
- In the Detailed description (optional) field, enter As well as the usual monthly management reports, expenses as a percentage of income needs to be included.
The administrator of the system can provide a default, template, description for each different issue type. A new issue’s description is then pre-populated with the appropriate template text. Template descriptions can therefore serve as a useful reminder of the information your organization wishes to record for particular types of issue.
7. Submit the issue
Preliminary information about the issue has now been entered. This information must now be submitted to Ketura, so that a new issue can be created from it.
- Click the Apply button.
- The issue will be created and its page shown.
8. Understanding what happens when an issue is created
When an issue is created, it is assigned a unique id, such as ‘I8423’. This is shown clearly at the top of the issue page. The id begins with the letter ‘I’ to identify it as being the id of an issue. Ketura uses a unique prefix for different types of items. For example, tasks are assigned unique ids beginning with the letter ‘T’.
The issue is scheduled (depending on the workflow of its topic)
An issue is said to be scheduled if it is associated with a project’s milestone. The workflow configured for the ‘General’ topic has caused the issue we have just created to be added automatically to the O1 – Review New Issues (ongoing) milestone of the General project. You can check this on the Schedule tab of the issue.
Because the O1 – Review New Issues (ongoing) milestone is current, and belongs an active project, the tasks of the issue now show up in the Pending tab of the relevant task assignees’ Home pages. Thus, the task assignees are made aware of the new issue.
The issue’s state is set to ‘New’
When an issue is first created, its state is set to indicate that it is new and has not yet been processed. By default, this state is called ‘New [Issue is awaiting attention]’, but it can be renamed if desired.
An issue’s state identifies how far the issue has progressed in the workflow defined for it. The available states are typically set by the person who administers the Ketura system, although the system comes with several states already defined as a starting point. Each state is either active (issues in that state are still outstanding) or inactive (issue in that state have been dealt with and no longer need to be considered).
Tasks are added (depending on the workflow of the issue’s topic)
An issue captures what needs to be achieved, but it doesn’t of itself describe how the issue will be resolved or who would do the work. To address this, tasks are added to an issue for each work item that needs to be completed for the issue to be resolved. The tasks for an issue thus form a mini ‘to do’ list for the issue. The process of adding tasks to an issue is covered in detail in Tutorial 3: Using Tasks to Define and Assign Work for an Issue.
Workflow can be used to define automatically the tasks that must be completed for an issue to be resolved. This is done by specifying a set of tasks (see Task sets in Ketura Tour Step 3: Tasks) that should be added to the issue when it enters a particular state. Each task in the task set can be assigned to a particular person by default, but can subsequently be reassigned if desired. Tasks can also manually be added to or removed from an individual issue, as required.
In this example, the Tasks tab of the issue shows a single task ‘Review new issue’ has been added automatically to the issue by the workflow configured for the ‘General’ topic. This task is assigned to Eric Samet, the relevant project manager. The task enables Eric to review the issue and decide if work should proceed to address the issue, when work will be scheduled for the issue, and who is required to do work on the issue. Notice also that the task has a number of associated work values. These are explained in Ketura Tour Step 3: Tasks.
As the task is assigned to the Eric Samet, it appears on the Pending tab of his Home Page. It appears at the top of this list because the issue was automatically added to the ‘Review New Issues’ milestone by the configured workflow, which is the first milestone in the ‘General’ project.
9. Additional issue information
As well as the basic information about an issue discussed above, a significant amount of other information is potentially available for an issue.
History and comments
The History section on the Details tab shows what has happened to the issue since it was created. Comments can also be added to the issue here. These are useful for recording additional information about the issue, for example, as work progresses.
When an issue changes Issue State, it is sometimes useful to have Ketura prompt automatically for a comment explaining what caused the change. This is a configurable option for each state within the workflow configured for the issue’s topic.
Indicating when work should start on an issue and/or by when the issue should be resolved
The Schedule tab shows scheduling information for the issue. It also enables the dates to be recorded by when it is desired that work on the issue starts or ends.
Setting a desired start or end date for the issue does not alter its actual scheduling; that is controlled by its priority within any milestone to which it belongs. However, Ketura indicates (for example, by showing a warning on the Issues tab of a milestone page) if the desired dates are not likely to be achieved. A project manager can then take appropriate action to ensure that work on the issue will start or end within the desired timescale.
Related issues, attachments and contacts
An issue can have related information recorded against it for reference purposes on its Related tab. The different types of related information are:
- Related issues. These are issues, such as duplicates, that have a bearing on the issue and, therefore, of which anyone working on the issue should be aware.
- Related attachments. These are typically documents, pictures and other files that are related to the issue in some way. For example, it might be useful to attach a screenshot when recording a defect about a software product.
- Related contacts. These are contacts who are interested in the issue, or related to it in some other way. For example, customers who report the issue might be added so that they can be easily contacted once the issue has been resolved.
The Activity tab shows all activity related to the issue. Is shows a table of the changes submitted to SCM systems for the issue. It shows the work recorded against the issue’s tasks as work journal entries. It also summarizes the amount of work done by each user.
The work journal is discussed further in Ketura Tour Step 8: Workflow.