Skip to content
Lab651 Process

Tickets

Tickets

Section titled “Tickets”

Having a defined way in tickets are created and managed is key to a successful project.  The following are the way that Lab651 classifies and uses tickets.

Story Versus Task Tickets

Section titled “Story Versus Task Tickets”

Stories should be considered to be in the user’s voice and Tasks should be considered engineering tasks.  After a Story is reviewed by the engineers, separate Tasks should be created that reference (“block”) the original user Story.  A Story will not be considered completed until all the referenced Tasks are completed.  Do not create Child Tasks under the Story unless they are considered part of the Story, itself.

Child Issues in Tickets

Section titled “Child Issues in Tickets”

Child Issues are tied directly to the Story/Task and they cannot be independently loaded into a Sprint or Kanban board.  Use them as exclusively checklists to get the work done or have them be related To-Do’s for someone else.  For example, if the Task is to “update a login page after successful login”, a Child Issue may be to receive valid credentials from someone (and that Child Issue would be assigned to that someone).  As a note, tickets cannot be closed with open Child Issues.

Epics

Section titled “Epics”

Epics are collections of smaller Stories that all belong together.  The Stories in Epics can be worked on by separated teams (e.g. Development and DevOps), but belong together in order to complete the overarching goal.

Quality Assurance Tickets

Section titled “Quality Assurance Tickets”

The QA team should create their own Tasks for a Developer Task and “block” that originating Developer Task.  Any defects should be called out in a separate Bug ticket and assigned to the original developer.  Link the Bug to the both the QA Task and the Developer Task with a “blocks”.

Ticket Assignment

Section titled “Ticket Assignment”

Ticket assignments will change many times of the lifetime of a ticket.  The ticket should always be assigned to the person who is supposed to do the work and an explanation for the assignment should be placed in the ticket notes.  For example, when a developer needs a code review after completing code, the developer should add a note in the notes field, “@A.Dev - Please code review” and assign the ticket to “A.Dev” in the ticket.

Section titled “Related”