Issue Management

In the Redmine Support Portal chapter we introduced tickets, and went into some detail on the Trackers that are used for different types of activities (Bug, Enhancement, etc.).

In this chapter we go into more detail on how issues are progressed through the system.

We deal with the mechanics of how issues are dealt with as they are raised, the triage process.

We also describe some of the processes involved in managing different types of tickets, focusing in particular on the distinction between Problem Issues and Solution Requests. We describe as our conventions for deciding when to raise new tickets to cover different aspects of an overall task.

We also go into some detail on the use of states as an indicator for how different types of issues are being progressed.

Triage of New Issues

Triage is the first thing that happens when a new ticket is raised. An initial assessment needs to be made on the nature and the severity of the problem.

The first step is to determine whether the issue is having any immediate business impact due to impairment of existing functionality (a Problem), or whether it reflects a change requires the scoping and scheduling of the required to meet a new business requirement (a Solution Request).

These questions need to be answered in order to determine the next step for each ticket raised.

Problem Issues

If a problem is reported, the first question is to determine the severity of this impact. This will determine the priority given to the ticket.

The priority will influence the speed of response of the OrderFlow support team.

Priority	Impact	Target Response
Immediate	System not accessible, or mission critical part of system is not usable, causing major operational impact.	Immediate
Urgent	A mission critical part of the system is not functioning correctly, resulting in significant operational impact.	2 hours
High	A part of the system is not functioning correctly, resulting in a loss of efficiency and operational delays.	Within 1 working day
Normal	A part of the system is not functioning correctly, but an acceptable temporary workaround is possible at least in the short term.	Scheduled Release
Low	A part of the system is not functioning correctly, but with no noticeable business impact.	Scheduled Release

As the name suggests, tickets that are identified as Immediate will be addressed without delay during business hours. In practice, Urgent tickets typically get actioned without delay as well, and High priority tickets will be addressed on the same day.

It is worth clarifying what we mean by Target Response in the table above. This indicates the period within which we will begin a meaningful and serious engagement with the customer towards resolving the problem.

Setting Priorities

Setting the ticket priority is normally the job of the OrderFlow support team. On occasions, the priority will be changed to reflect a revised judgment on the severity of the impact of the problem.

In some cases, the resolution will be through a single action, such as restarting a server. In other cases, the resolution will be done in stages. Here, the question we ask is as follows:

What can be done in the very short term to reduce the impact of the problem in the short term?
What needs to be done in the medium to longer term to provide a complete resolution of the issue. For example, is any development required.

Determining the answers to these questions often involves further interactions, including

requests for further information
investigation on the customer system
work to replicate the problem in a local development environment

Often it is possible to perform a short term tactical fix to reduce the impact of the reported problem. If further longer term fixes are required, these will be addressed through separate (possibly development) tickets as required.

Responsibilities

The responsibility of the Support Team here will be to:

perform the initial triage on the new ticket.
identify and perform the short term remedial actions that will resolve the issue or lessen its impact.
raise new tickets to cover any longer term fixes required to address the underlying cause of the problem, or to reduce the likelihood of it occurring.

If longer terms fixes are required, it will be the responsibility of the Development and/or Implementation Team to schedule the work required to provide these.

Trackers

The Trackers used for problem issues are as follows:

the ticket will initially be raised as a Support ticket.
any short term remedial action that is done will be recorded against the original Support ticket.
if during the investigation of the ticket, it is determined that there is an underlying software defect causing the issue, this will be addressed through a new Bug ticket.
on some occasions, additional development work will be helpful in delivering new functionality to reduce the long term impact of the problem or its frequency of occurrence. These will be handled through a new Enhancement ticket.
similarly, it may be possible on occasions to identify longer term non-development changes that will be helpful in managing the issue. These will be handled through separately raised Implementation tickets.
if a software defect is identified, but no short term remedial action is required, it may be appropriate to reclassify the original ticket as a Bug. For example, a broken link may be raised as a Support issue, but reclassified as a Bug if there is a simple workaround.

The key to these rules is that the Tracker used should reflect the nature and timing of the work being delivered. We should never end up, for example, with short term remedial actions being tracked in the same ticket as the longer term resolutions, or with support or implementation work being tracked in the same ticket as the development work.

Best practices in raising new issues

In order to get the speediest, most helpful and most cost effective response from Realtime Despatch, we recommend the following when raising tickets.

If a problem is being reported, please:

use specific examples of where you expect a problem.
if the system is not behaving correctly, try to describe how you think this is occurring. Detail on what you expect to happen versus what is actually happening is very useful.
ensure that you mention which environment this is is occurring (test, live, etc.).
give us an indication of how severely this is impacting your operations. What the consequences of each occurrence, and what are you doing to work around the problem?
add links to the tickets where possible.

If any of this information is missing when the ticket is first raised, we may ask for it which may result in a delay in resolving the issue.

For solution requests (see below), please try to:

make it clear that you are requesting a change rather than reporting an issue on an existing customer environment.
give clear information on the business problem you are trying to solve.
focus on the requirement rather than on the solution.
give some indication of how urgently the change is required, so that we can prioritise it appropriately.

Solution Requests

Unlike problems, solution requests don't typically require an immediate response. However, we will always acknowledge the receipt of a change request on the same business day, usually giving an indication of when the next action is likely to take place.

The first meaningful engagement after a change request is raised will be towards get a very high level understanding of the required change and the possible scope involved. Initial questions to answer here are:

what is the essence of the problem being addressed?
do we need input from the Development Team to determine whether the problem will require code changes?
how much design work will be required to fully understand the problem and present a solution?

The solution request will be received initially by the support team. The first response will often involve further questions to the customer to validate or clarify their understanding of the requirement.

In very simple cases it will be possible to deliver the solution as part of the Support Function. For example, this may be possible for simple custom reports. As a rule, if the solution is likely to involve comfortably less than two hours of testing and implementation time, then it might be carried out by the support team.

For any more substantial change, the next step after initial clarification of the requirement will to be to schedule time to:

scope the requirement in more detail
present and agree on a candidate solution
identify the tasks involved in delivering the solution
provide an estimate for the time required to perform these tasks

Responsibilities

The Support Team's responsibility for Solution Requests will be to:

obtain clarification on the requirement that needs to be addressed.
in very simple cases, to implement the solution as part of the Support Function. Otherwise,
hand the ticket over to the Development or Implementation Team for a solution design.

Trackers

The approach to the use of Trackers is similar in essence to that used for Problem Issues.

the ticket will initially be raised as a Support ticket.
if the solution can be delivered as part of the support function, it will remain a Support ticket.
if the solution does not require any development (code changes), then the original ticket will be reclassified as an Implementation ticket.
if the solution does require development work, then one of the following can happen:
if the solution involves a significant amount of implementation work and but little development, then the the original ticket will be reclassified as an Implementation ticket, and a new Enhancement will be raised.
if the solution is primarily a development solution, that is, requiring a substantial amount of development but only a small amount of implementation, then the the original ticket will be reclassified as an an Enhancement. If any subsequent work is required to deliver the solution, a new Implementation ticket will be raised to cover the subsequent implementation work that will follow.

Milestones

Milestones are used to control the timing of the delivery of all work that needs to be scheduled; this includes both development and implementation work.

The use of milestones depends entirely on whether development work is required to deliver a solution.

Milestone Usage when Development Work is Required

Development work needs to be added to a release milestone. If implementation work is required, it will only be possible to deliver this implementation work into the customer environment after the development release has been release has been prepared and the associated upgrade performed on the customer environment.

For these cases, the following will apply:

the development ticket will be associated with a numbered release milestone (e.g. 3.6.7-london)
the implementation ticket will be associated with the same release milestone

On some occasions, if the development change is small and simple, it may be possible to back port the development change to an earlier release. Once the associated patch has been delivered and deployed, the constraint on the development milestone requirement can be removed.

Milestone Usage when No Development Work Required

If no development work required, then the Implementation ticket will not need to be associated with any development milestone, as the timing for this implementation work is not constrained by the delivery of development changes.

The issue Next Action Date field is used to actively track implementation work that is currently being addressed, or is scheduled for further work on a particular date in the short term.

Other implementation work that is not yet scheduled, can be added to one of two non-development milestones:

current-nonrelease milestone: for implementation work to be scheduled in the short term.
deferred-nonrelease milestone: for implementation work that needs to be considered in the longer term.

For solutions which can be addressed as part of the Support Function as Support tickets, there is no need to set a milestone. Instead, the Next Action Date action date is used to manage the timing of delivery of these tickets.

Non-release Milestone

It has been mentioned earlier that Support tickets are tracked through the Next Action Date mechanism, and that development tickets are tracked using a development release milestone.

Another category of tickets are Implementation tickets that may involve a substantial amount of work (several hours or more), but don't require any development work. It doesn't make sense for these tickets to be tracked within a development release milestone.

These tickets are instead placed in one of two special milestones:

Current Non-release Milestone: this contains a list of substantial tickets for which work is required in the short term, but hasn't necessarily be scheduled using the Next Action Date mechanism.
Deferred Non-release Milestone: this includes implementation tickets for which work is required in the more medium term, but still need to be visible for scheduling or planning purposes.

Issue States

Exactly what happens to a ticket over the course of its lifetime depends on the type of ticket involved. The state provides a good indicator of what is happening to a particular issue at any point in time.

Support

The Support tracker is the default tracker that is used for all tickets. Both Problem reports as well as Solution Requests are received initially as Support tickets. The states used for Support issues are as follows:

Name	Description
New	The default state for new tickets
Further Info Requested	Used when further information is required or will be helpful to understand a reported problem.
Investigating	The state used by Realtime Despatch when actively investigating an issue.
In Progress	This is a post-triage state which indicates that Realtime Despatch is currently carrying out work to achieve a resolution to a ticket.
Customer to Verify	This is the state that typically follows the handover of work from Realtime Despatch to the customer. If verification fails or further work needs to be done, the ticket can move back to 'In Progress'.
Closed	This indicates that a ticket is no longer active, and that the problem has been resolved.

The workflow is shown graphically in the diagram below.

Support Workflow

Implementation

Implementation is the other main tracker used for tickets that do not require development work.

The main states used for this tracker are.

Name	Description
Pending	Work on the implementation ticket is not yet active, and is waiting to begin.
Further Info Requested	Used when further information is required or will be helpful to get a better initial understanding of a solution requirement.
Investigating	The state doing the initial scoping work. If more detailed scoping work is required, then approval for this is sought.
Design Approval Requested	An optional state for more involved implementation work, where specific design time needs to be approved to scope and estimate a solution.
Awaiting Estimate	An implementation ticket will tend to be in this state during the design phase, during which time the scoping, solution design and time estimation will occur.
Approved	Once scoping and estimation is complete, a ticket will be submitted for approval for the main body of the implementation work.
In Progress	Work is currently under way to prepare the solution.
Customer to Verify	The solution has been delivered, and the ticket is now with the customer for approval. This state is also used when a part of the solution has been delivered, and verification is sought on specific work covered so far.

Note that some of the above steps will be bypassed for smaller tickets. For example, design approval will only be requested if the design time is expected to take two hours or more. Similarly, approval for the main implementation work will only be sought if this work is expected to exceed two hours of effort.

The implementation workflow is shown graphically in the diagram below.

Implementation Workflow

Bugs

The workflow for development tickets such as bugs and enhancements is a little more complicated, as a number of the states used are internal to the development process.

Some of the main states in use for Bugs are listed below:

Name	Description
Investigating	This state is used when a bug is suspected, but has not yet been reproduced.
Accepted	The bug has been accepted, but work on resolving the issue has not yet started.
In Progress	Work is currently under way to resolve the issue.
Customer to Verify	This state is sometimes used if further verification from the customer is required in order to determine that the bug has been resolved.
Fixed when Deployed	Indicates that the bug has been fixed, and that this fix will be applied at the point where the software release containing the bug has been deployed

Note that the development work required to fix a bug will normally need to take place against a software release milestones.

Enhancements

Most of the states used for the Implementation tracker, including all of the states listed above, are used for Enhancements. A number of additional states are used for enhancements.

As with Bugs, the Fixed When Deployed state is used to indicate that the feature covered by the enhancement will be present and available for use at the point when the software release containing the enhancement is deployed.

Customer Acceptance Testing

On completion of work on any non-development ticket, Realtime Despatch will move the ticket to the state Customer to Verify. Non-development work will be implemented on an existing test or live release, so it is important that the change is brought explicitly to the customer's attention to allow for verification that the change has worked as expected and not introduced any further issues.

For development work, the Customer to Verify state is used, but a little bit more sparingly. It tends to be used only when specific verification is required against a piece of development work to ensure that the change it has introduced has had the desired effect.

However, it would not be realistic to expect customers to verify the behaviour of every single change that has been introduced with each release. Instead, we recommend that with each release, that the customer performs a full regression test of the main processes in a test environment prior to scheduling an upgrade to a live platform.

For many tickets we consider it appropriate to point out areas where we think extra testing may be required following the inclusion of a ticket in a release. Here, we identify such tickets with an entry in the Customer Testing Notes field.

In addition, the release information we include in customer upgrade tickets specifically aim to identify the following:

High Risk Changes: where substantial or fundamental changes to the way a part of the system works have been introduced, extra testing may be recommended in affected areas, even when no obvious functional changes have been introduced.
Backward Incompatible Changes: this occurs when changes are introduced that may prevent custom reports or scripts from working as before. In this case, the release information will include details on the affected change and the likely impact.

We plan in the coming months to introduce support for generating customer release notes to coincide with upgrades, which will be helpful in making this information more visible.

Next Action Date

An important feature of support system are mechanisms to ensure that issues that have been raised don't get 'lost' or 'forgotten about'.

The Next Action Date field is used to indicate that date at which the next action is scheduled to occur on a ticket. When that date arrives, it will be the responsibility of the issue's Assignee to ensure that some action is taken on the ticket. The use of the Next Action Date does not mandate what this action is. In some cases, the issue will be resolved on that day. In other cases, some steps will be taken towards the resolution of that issue. On other occasions, there won't be the opportunity or the time to take further steps on the current day, at which point it will be responsibility of the assignee to set a new Next Action Date for that ticket.

Tickets which have a Next Action Date set for the current date or some date in the past will be visible to the Support User, who will if necessary remind the assignee of this responsibility.

The importance of the Next Action Date is in ensuring that current or outstanding work remains visible to customers as well as the Realtime Despatch Support Team.

A Next Action Date will be set automatically for all new tickets, so unsetting this date will require an explicit choice on the part of the user.

The Next Action Date is mainly useful for non-development tickets (including Support or Implementation tickets). For development tickets (including Bugs and Enhancements) that are assosciated with a release Milestone, the progress of that work is tracked within the development release.