Jira (Development) Ticket Analysis

This post will contain the approach towards how a development should be approached and analyzed if you are a beginner or do not know how to go for the same.

Setup & General info:

Markup Language

• So, we use Mark Up language to add the description to the ticket.

  • To know more about this you can visit this link.

  • Otherwise, you can use the UI elements present already. ( in JIRA while writing description/comment)

Markup text editor

• Will suggest using a markup text editor which can be helpful as our tickets use the same.

• To download Mark-Text click here. It’s one of the markup text editors.

• Alternatives to Mark-text: Obsidian, Notion and many more.

• Currently, the application I use is Obsidian.

• (Obsidian is an all-purpose tool for me used heavily for notes which we can cover in another post)

Points which should be covered in the analysis:

Checkboxes

(Things to check while doing or after the analysis)

Brainstorming should cover all the following points:

• Why?

• What?

• How?

• Security Concerns.

• Time analysis (Story points)

• Discuss with the respective UI/Backend person and the above points should then be noted commonly.

• Note down questions (if any) regarding the ticket.

• Call LEAD and Module Lead to brainstorm of ticket together.

• Verify the analysis done by you and the respective UI/Backend person.

• Ask and raise questions/doubts which can be blocker or not mentioned in the ticket.

• If not cleared in the brainstorming session then verify and get confirmation/answers on those points from Clients.

• Put the finalized analysis in the Analysis subtask of the ticket.

• Create subtasks (UI, Backend)

Each of the subtasks should be 2 hours only (depending on your project structure), If it takes more time then we have to break it down further.

• Create and Unit Testing subtask and add the Cases which will need the testing.

Checkbox points explained in detail

• Why?

  • Why this ticket was created?

  • Why these changes are needed?

  • Why we didn't have existing functionality (if any similar functionality is present)

• What?

  • What changes would be needed in a generalized way?

• How?

  • UI changes

    • This should contain UI changes as a subpoint with the required changes (in list format).

    • With Controller name, file name, project name, and function name whichever is relevant in the case.

    • You can add mockups or screenshots with pointers which would help understand the changes more.

  • Backend changes

    • This should contain all the backend changes in list format which should also cover changes in the Database (Table/Column) & Model changes among the code changes

    • With Controller name, Service name, file name, project name, function name whichever is relevant in the case.

    • You can also add new API names, and property names, so that while implementing it will be useful for UI as well as backend developers.

• Security Concerns.

  • This should contain any point which should be checked or paid attention to.

  • This point should be noted and revisited after the completion of the development of the ticket.

  • For example, authentication for API, showing sensitive data on UI without masking, etc.

  • Highlight the same to the team and get the feedback.

• You can add an additional point in the How section if needed like calculation, SDK information, etc.

• To answer this we should:

  • Check the description of the ticket.

  • Check tickets linked to our ticket (if any)

  • Check the functionality mentioned.

  • Check the KT document (if any)

  • Check the code in a project or similar functionality (if any)

  • Discuss with the person who developed or worked on it (if available)

  • Discuss with the Module Lead (if available)