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:
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:
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:
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.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event