Best Practices for Managing Development, Support, and Change Requests in Jira

[Shehan Sandeepa]

Hi everyone,

I’m looking for some guidance on industry best practices for managing projects in Jira. Here’s my situation:

• My company often starts new client projects where we receive requirements and begin development. I want to know the best way to set up Jira for the initial project work (adding all initial stories, managing sprints, etc.).
• After the project goes live, we need to handle ongoing support tickets in Jira. Should this be done in the same project or a separate project?
• We frequently receive multiple change requests (CRs) from the client at the same time. What’s the best way to track these CRs in Jira (Epics, separate boards, separate projects, etc.)?
• In what scenarios should we create multiple Jira boards within the same project instead of creating separate projects?
• Finally, how should Jira be structured when working on a project that involves multiple clients (one Jira project per client, or one project with multiple boards/filters for each client)?

I’d love to hear how others in the industry handle these situations and what Jira setup works best to balance development, support, and client change requests without losing visibility or overcomplicating the setup.

Thanks in advance!

[Nikola Perisic]

Hello @Shehan Sandeepa 

• For a development project, the focus should be on developers. They need to be working on user stories that are part of an epic which represents a feature. Depending on your practice, they can log time that they have spent working on a specific user story - this also helps with the reporting, but also creates micromanaging atmosphere which is something that no one likes. Simple workflow needs to be implemented for the SDLC which includes stuff to do, stuff that is in progress, QA review and also the done status. Most development teams use tools like Github or Bitbucket, so the good idea is to connect these tools with Jira since they can make commits with the issue keys attached to the message. That way, PO's can track the commits that were done on the work items. Ideally, you would want to use the Scrum project template because it focuses on estimation, planning which has a backlog and then active sprints that will contain the work items ONCE the sprint has started. Standard work items are just fine, you don't need additional ones. I recommend using components to group work items into one portion, because you have the front end, back end, maybe some DevOps and so on. 
• For the support tickets, the best would be to have a separate service management project. If you have a certain request that is regarding including some of the engineering work, you can include your developers in your service management project as well.
• Service management has its own change management feature that you can enable from Project settings -> Features -> Change management, you can find more here: https://www.atlassian.com/software/jira/service-management/product-guide/getting-started/change-management#how-it-works - overall, you track these types of changes based on the request types. Each request type is tied with it's initial work item type.
• Creating multiple boards in Jira is good when you have different teams: One board is for the finance, other board is for the analysis. Creating a new project would be if you need to have different components, if you need to have different releases (this is for the software projects).
• As for the clients, I would avoid creating multiple projects, because this would create an overhaul. My approach would be to use different boards, create quick filters so the clients can filter out most important things that are relevant to them - this is great because you can have different quick filters for each board. Here, your best choice would be to go with Kanban.