Development JIRA Guidelines

Author: John Rellis

Dev Ticket Creation in Jira Presentation Slides

Dev Ticket Creation in Jira Webex Link

A nocuser should be able to see venues in the nocportal and also view venue reports

• This is bad! This should be two jiras, one for noc portal and one for specific report changes

• All requirements should be in the JIRA description, otherwise the JIRA becomes too disjointed, this includes copying in email chains with customer names scrubbed out of them if required
• The description should further explain the title of the story. It should not add additional requirements such as “report edits are also required for this jira”, any additional requirements require a user story, these stories should be linked and their required completion order stated in the descriptions. This probably needs more fleshing out.
• Storypoint or LOE estimate should not be added by the support team unless discussed with a developer and agreed upon - leave 0 otherwise

The JIRA Description should contain the following subsections

• Feature/Bug Summary - This should elaborate on the user story or bug title and describe the problems it is solving
• Steps to Reproduce Issue - Typically only relevant for bugs
• Background Information - Information on the history of the item
• Related Tickets - For example “IDMS-1234 Needs to be completed before this”, “SUPPORT-1234 will be rectified by this”
• Proposed Solutions - Any information that should be considered as part of the solution including pointers, warnings etc
• Potential Additional Tasks - Any tasks, like database loading, that might need to be considered in the LOE, this can remain here during grooming
  • These tasks should become subtasks to be deemed sprint ready, they should be noted here once grooming is complete
• Unresolved Questions - All of the questions that must be answered before considering the item sprint ready
  • Note, all unresolved questions should be crossed out and the person crossing it out should be tagged, a resolution should also be provided
    • Verify customer would like to see two separate buttons - RESOLVED by @johnrellis - Customer verified they would like two buttons
      • This information is then required to be added to the proposed solution or new subtasks if necessary

Paste this into your JIRA description before beginning

{panel:title=Feature/Bug Summary}
{panel}

{panel:title=Steps to Reproduce Issue}
{panel}

{panel:title=Background Information}
{panel}

{panel:title=Related Tickets}
{panel}

{panel:title=Proposed Solution}
{panel}

{panel:title=Potential Additional Tasks}
{panel}

{panel:title=Unresolved Questions}
{panel}

• Comments should only be used by the implementing developer to track progress so that if they need to leave the item, someone can pick up where they left off. This will also serve as a progress marker to the Scrum master
• Comments should not be used to add requirements, ask open ended questions, give opinions
• If you absolutely have to store sensitive information in a restricted comment, there may be one comment entitled, “Private Requirement Additions” that is edited as things are added to it. No more than one comment may have these “Private Requirement Additions” and it must be clearly mentioned in the description, “PLEASE NOTE : THERE ARE REQUIREMENT ADDITIONS”

During backlog grooming, the following labels should be used on each JIRA until they reach Sprint Ready in the Sprint Planning meeting

• CUSTOMER_CLARIFICATION_REQUIRED
• INTERNAL_R&D_REQUIRED
• SPRINT_READY
  • All unresolved questions have to be resolved before this label can be applied. See the note on Unresolved Questions above.
  • All additional tasks need to be quantified and made subtasks, see the note on Potential Additional Tasks above.