Tips and tricks for using JIRA, Confluence at Product Maintenance project phase

[Mezosi_Jozsef]

Dear Atlassian Community!

We have purchased JIRA and Confluence Atlassian product enterprise licenses for quite some time.

Our ongoing iOS application project is also supported by these Atlassian products. At the moment we are past publication to Appstore.
The design and development product phases went quite well with the help of Atlassian products (JIRA, Confluence).

Now, after publication we are transitioning from design & development to Maintenance & Support product phase, in which maintenance activities are expected paralell to new feature development and bug fixes and technology (iOS or swift) upgrades and changes.

Please advise on tools, techniques, best practices on how to professionally handle the “maintenance & Support” phase with the help of Atlassian tools, products.

We are kindly asking, beside the above mentioned general question answers for the following specific dilemmas and questions:
- how to professionally handle periodically repeating activities (maintenance, marketing etc.) or
- are there best practices to handle maintenance type of activities (for example maintenance type sprints)
- how to handle paralell the new feature development type sprints and maintenance type sprints.
- are there any best practice issue types, workflows, confluence templates that support professional support & maintenance product phase handling.

Thanks for your thoughts and replies in advance.

Jozsef Mezosi

[Krister Broman _Advania_]

So i would probably do it something like this

Projects

Support (Customer Facing) - Jira Service Desk, where your customers contact you in regards to orders, bugs and so forth.
Maintenance (Internal Facing) - Jira Software Kanban Project, schedueled activities not related, i would probably push to have a plugin added for handling recurring activities https://marketplace.atlassian.com/search?product=jira&query=recurring, there are other ways but this is the easiest one to get the functionality. 
Development (Internal Process) - Jira Software Scrum Project, Projects, Feature development, bug fixes etc that you find is needed by listening to sales, maintenance and support. 

You may have some other Projects like Sales, Customer Order, Internal Projects etc as well but not going to go into that, just think of them in the same way for example a Marketing campaign project might be the internal facing project, an order project might be the customer facing project and a Sales project might be the Internal Process. 

Teams

Depending on how many persons you have working you may have one team per project or one team that handles them all then it may warrant to share statuses and such things to allow for one streamlined board with issues from all projects. 

Process

So in general it would work like this: A customer facing project i.e. Support would take in issues from customers, you want to handle things fast in a customer facing project. Lets say that a bug is reported, check it out and verify if it is or isn't a bug. Once verified you only have two options, either A: it is a bug or B: it is not a bug.

If A then support will not handle this instead you create a development issue of the bug. You link the support issue with the development issue and then close the support issue with the comment to the customer that this is a bug and will be handled through the development process, you might want to inform the client of the development issue id to look for. 

If another client report the same issue, you would reference the already created development issue and close the issue. This way you reuse the information and still give good customer support. 

The development team would now own the handling of the bug based on their development methodology, some handle all bugs first, while some set a priority and work with them in an organized fashion while balancing feature development. 

General Principles

As for the specifics of workflows issuetypes etc, i would say use the KISS principle https://en.wikipedia.org/wiki/KISS_principle . Many try to build gigantic workflows and configure a lot in Jira, without really knowing if they need it.

Always start with the preconfigured projects in Jira and just start working, once you find that you need something then make an informed decision and add more complexity.

A less complex issue handling process that is used correctly is always better than a complex one with lots of data that have invalid data or is just not used!