Agile implementation in Jira

[Angel Todorov]

Hi there I am working with the company, and we are applying Agile SCRUM framework. Since the team already has some initial knowledge and follows basic task management routines, and I believe we are now ready for the next major leap.

The goal - ideally, we would like to follow Agile Project Management approach, since the idea of having Themes, Initiatives, Epics and Stories seems good. There are however some caveats and I would like to explore them before making this as proposal to the team. Hence I would like to have your opinion on the topic.

The context - currently in our Jira installation we have dev centered projects e.g. Backend, Frontend, Android, IOS, DevOps. Each of these project task has its own workflow tailored to specific deployment/release steps. These were there, when I came and I decided to keep them as they are, just to not stress the team initially. For the moment, when we decide to kickoff the sprint, we plan it by creating tasks from different projects and place them into the SCRUM board - I use filter so my backlog consists of all projects, hence I can see all active sprints on a single board. This approach works well for the moment, since it allows us to clearly identify each task type as long as they are easily distinguished by their keys e.g. WEB-100, AND-200, IOS-300 and etc. This approach however has its downsides .e.g. we miss the product roadmap visibility, since the sprints created don't belong to specific product as they should.

Proposal - now having Themes, Initiatives, Epics and Stories in mind we consider three different approaches, but since each one has its own pros and cons, I would like to hear from Atlassian community as well. It might be a fourth way, which I overseen it. So let's begin:

Approach #1 - Let's map the main logical domain as explained in the above link:

• Theme - we should create a dedicated project for each of our products e.g. Product 1, Product 2 and etc. This Product project will consists of Epics only
• Initiative - this is set of Epics and we can label all Epics in an initiative under a Major Fix Version e.g. 1.X.X, 2.X.X, 3.X.X and etc.
• Release - the release is where we decide to build and deploy something as minor release. This one maps to Agile releasable increment(s). In Jira it will map to minor Fix Version.
• Epic - this is Jira epic.
• Story/Task - we will continue to use dev centered projects to create tasks and link these tasks to the Epics in product projects. Since we intend to move towards advanced roadmap, we will be able to see tickets from different projects in a roadmap.

The main pros in this approach are: 1)the minimum efforts to achieve it; 2) the change management is the simple one.

The cons are 1) Release version cannot naturally span among a couple of projects, we should support unique global version; 2) We might need a story (if we consider it user-centric), where development efforts are required from different dev profiles e.g. we might need backend, frontend and mobile developers to complete a single story. In order to achieve that we should have story (created in product project) and then dev tasks from different dev projects linked as dependencies to the story. 

Approach #2 - The mapping here is a bit different:

• Theme - dedicated project for each product. Each product will consist of Epics, Stories and Tasks
• Initiative identical to #1
• Release - identical to #1
• Epic - identical to #1
• Task - we will have story, where we will describe the specific business requirement that needs to be implemented. The story will belong to the product project. We will have a different Story types e.g. backend story, frontend story and etc. where each story follows its own workflow, tailored to the tech stack. Each story will have story point estimation.

Pros - 1) simplified release - since all stories will be from one project, we can manage per product/project release easily.

Cons 1) we still might need story in more complex cases

Approach #3 - Mapping is:

• Theme - dedicated project for each product. Each product will consist of Epics, Stories and Subtasks.
• Initiative identical to #1
• Release - identical to #1
• Epic - identical to #1
• Story - if we consider it as short requirements or requests written from the perspective of an end user, then it will need specific dev efforts to have the story implemented. The is where subtasks come:
• Subtask - it is related to the story and represents specific dev effort or combination of them e.g. consider we have a following story - "As a customer I want to choose the showroom for pick-up from a list" - in order to deliver the above story, we most like to have at least two backend tasks: 1) to build a API GET endpoint to return all showrooms; 2) another endpoint PUT to submit the selection, and one frontend task to fetch the showroom list and allow the customer to make the selection. So we need at least three dev tasks.
• Task - in some cases, when it's clear what is expected, we won't need a story - we can have just a task. For such cases, we will need tasks that duplicates subtasks types. Alternatively - we can re-use tasks from dev projects, but we won't be able to use same release version to all, unless if we make it global.

Pros - 1) this matches Agile approach best

Cons 1) From my standing point in this approach, story is basically a business requirement - it cannot exist w/o subtasks. So we have first to create a story, then subtasks to it. More efforts and more complex hierarchy; 2) if we want to make story point estimate, we should actually estimate each subtask, and then sum up them to the story parent; 3) If we decide to re-use tasks from dev projects, we will get back to release issue we have in approach #1, if we decide to create a new set of tickets in the scope of product projects, this is additional complication

That's pretty much it - I would be very grateful to hear from everyone what do you guys think. It might be - we can start with #1 and go evolutionary to #3 or it might be even the better path to achieve the goal - let me know.