This post covers the approach toward how a development ticket should be approached and analyzed — useful if you're a beginner or don't yet know how to go about it.

Setup & general info

Markup language

  • We use a markup language to add the description to the ticket.
  • If you want to learn more, look up a markdown reference — otherwise you can use the UI elements already present in Jira while writing a description or comment.

Markup text editor

  • I'd suggest using a markup text editor, since our tickets use the same syntax.
  • Editors like Mark Text work well; alternatives include Obsidian, Notion and many more.
  • Currently the application I use is Obsidian — an all-purpose tool I lean on heavily for notes (worth its own post).

Points to cover in the analysis

Treat these as a checklist — things to verify while doing, or after, the analysis. Brainstorming should cover all of the following:

  • Why?, What?, How? and Security concerns
  • Time analysis (story points)
  • Discuss with the respective UI/Backend person; note the agreed points commonly
  • Note down any open questions regarding the ticket
  • Pull in the Lead and Module Lead to brainstorm the ticket together
  • Cross-verify the analysis done by you and the UI/Backend person
  • Raise questions or doubts that could be blockers or aren't mentioned in the ticket
  • If not cleared during brainstorming, confirm those points with the client
  • Record the finalized analysis in the Analysis subtask of the ticket
  • Create UI and Backend subtasks — each ideally ~2 hours; break down further if larger
  • Create a Unit Testing subtask and add the cases that need testing

The checklist, explained

Why?

  • Why was this ticket created?
  • Why are these changes needed?
  • Why didn't existing functionality cover it (if something similar is present)?

What?

  • What changes are needed, described in a generalized way?

How?

  • UI changes — list the required UI changes, with controller name, file name, project name and function name wherever relevant. Add mockups or annotated screenshots to make the changes clearer.
  • Backend changes — list all backend changes, including Database (table/column) and model changes. Note controller/service/file/project/function names, plus any new API names and properties, so both UI and backend developers can implement smoothly.

Security concerns

  • Note anything that should be checked or paid attention to — and revisit it after development is complete.
  • For example: authentication for an API, or showing sensitive data on the UI without masking.
  • Highlight these to the team and gather feedback.

You can add an extra item under How when needed — e.g. a calculation, SDK details, and so on.

To answer all this, you should

  • Read the ticket description carefully
  • Check any linked tickets
  • Check the functionality mentioned
  • Check the KT document (if any)
  • Check the code in the project or similar functionality (if any)
  • Talk to whoever developed or worked on it (if available)
  • Discuss with the Module Lead (if available)