Ticket Workflow

Ticket workflow is the process from the posting of a requirement to its fulfilment or rejection.

Every ticket workflow starts with a new ticket of ticket type requirement which will be in the ticket status open.

Step 1: Assignment of requirements

A project manager picks a requirement ticket with status open, assigns himself as the owner of the ticket and sets status to assigned. He is now responsible for the evaluation of the requirements of the ticket.

Step 2: Evaluation of requirements

Ticket status is assigned. The ticket is being evaluated by the project manager who has to decide whether this ticket should be implemented and when.

• Defect reports are being evaluated for reproducibility.
• Enhancement request may have to be discussed with the creator and the project team for evaluation. Discussion should be documented in the ticket.
  It may be necessary to delegate parts of this evaluation to a developer. In this case the procedure described in the following steps is being followed by creation and implementation of corresponding task assignments.

In the case where a defect report cannot be reproduced or will not be fixed for other reasons or if the evaluation of the enhancement request turns out negative, the project manager sets the ticket status to rejected. The ticket will not be dealt with any further.

Otherwise he assigns a milestone to the ticket (see section milestone assignment) and sets the ticket status to accepted. He thereby commits himself to complete the ticket in the timeframe defined by the milestone.

Step 3: Task assignment to the developer

The project manager creates one or more tickets of type task assignment for an accepted requirement. Those tickets are initially in the status open. In order to manage the implementation in a timely manner, he assigns every tickets to a developer, assigns a developer milestone to it (see section milestone assignment) and sets the status assigned.

He documents the association between the requirement ticket and the corresponding task assignment tickets as follows:

• At the bottom of the text of the requirement ticket, he adds a section labeled "associated task assignments", followed by a list of links to the associated tickets by ticket number.
• At the top of each task assignment ticket, he adds the text "Implements requirement ", followed by a link to the associated requirement ticket by ticket number.

In the further process of development, the task manager may add or change task assignments as needed. He may also add task assignments for special actions like developer peer reviews, integration tests, performance tests and so on.

Step 4: Implementation by the developer

As soon as the developer gets a new task assignment with status assigned (or one he has already work upon and which has been rejected by the project manager), he analyses within one working day whether he is able to complete the task timely and according to the quality guidelines. He either accepts the assignment (status accepted) or rejects it (status rejected) and documents the reasons for his decision in the ticket.

If the developer accepts the ticket, he is now responsible for the completion of the assignment in time and quality. That means that he has execute the task and the necessary developer tests. If he realizes that this is not any more possible for any reason, he documents the reasons in the ticket and sets its status to rejected.

As soon as the developer is sure that he has completed the task and the necessary development tests, he sets the status to closed and thereby informs the project manager of the completion of the task assignment.

Step 5: Task management and quality assurance

The project manager is responsible for the management and quality assurance of the ongoing development process for an assigned requirement. Depending on different situations, this might include the following actions:

Ordinary process flow

• As soon as a task assignment has been completed, the project manager reviews the documentation, tests and code produced by the developer and evaluates them. If he has any findings, he documents them in the task assignment ticket and sets its status to assigned in order that the developer fixes the findings.
• As soon as all task assignments for the requirement have been completed, the project manager does the final integration test and review and decides whether the requirements of the creator have been met. If this is the case, he sets the status of the requirement ticket to closed. Otherwise he activates further development activities.

Disturbed process flow

• If a task assignment has been rejected by the developer, the project manager works this situation out and changes the assignment or assigns it to a different developer.
• If the project manager comes to the decision that the timeline of the requirement ticket cannot be met, he documents this in the requirement ticket and changes the milestone so that the owner is being informed and can intervene.
• If the creator of the requirement ticket changes or enhances the ticket, the project manager reacts and decides how to work this out by discussion this with the creator or by changing the milestones of the requirement ticket and/or the task description or development milestones of the corresponding task assignments.
• If the project manager decides that further development is not reasonable at a certain point, he stops implementation by revoking the assignment of developers to all task assignments and setting their status to open. He then discusses the situation with the creator of the requirement and acts accordingly.
• If the project manager and the creator agree that further pursuit of the requirements is not reasonable, the project manager stops implementation by revoking the assignment of developers to all task assignments and setting their status to rejected. He then sets the status of the requirement also to rejected. The process comes to an end.

Adding information to tickets

All annotations, decisions and reasons for actions are documented as comments to the corresponding ticket.
All changes to requirements or tasks are documented by direct changes to the text of the corresponding ticket. The difference of the change is automatically appended as a comment.

\ Back to Ticket Management Guidelines.