How would you track a Jira Rollout project? Use Jira? Confluence? Both?

We are rolling out Jira to try out as our centralized ticketing system. I am in charge of the rollout, and it occurs across several, disparate software development projects. Currently, I have 4 different projects, running on 3 different ticketing systems: RT, Trac, Jira.

In order to keep track of the rollout project itself, I was thinking that it would be great to track it in Jira (we have a local installation, as well as an installation of Confluence, and I believe both are running pretty recent versions). How would you all recommend I go about setting this project up? Should I just use plain old Jira to track everything, or is Confluence going to buy me something as well? I should also mention that I would like to investigate any relevant plugins that might be considered essential for project management and project tracking.

2 answers

1 accepted

0 votes
Accepted answer

Scrum. Your Epic would be "Jira as a Support Application", stories would be the larger group of items (e.g. Environment Standup) with specific tasks under that story of "get hardware", get db, configure, etc...

Make sense?

Yeah, it makes sense. I've already built up a project plan using a checklist that's more or less timeline-based. I think the Atlassian stuff is user-friendly enough to where I'll be able to figure it out as I go along. Thanks.

Jira. Get the Greenhopper plugin. Make sure you have a setup for you ticket support base projects that is reusible and doesn't change much. Tracking a project roll out and communicating out the status will be easier with Greenhopper and managing it inside there as well.

Thank you for your response...I will take a look at Greenhopper. (Although I thought Greenhopper was only for Agile projects.) Could you elaborate a little bit on "make sure you have a setup for you ticket support base projects that isreusible and doesn't change much"? I'm not sure exactly what you mean by that.

Greenhopper can me blended to work for your needs. Most of the teams that I support that use it, us it as a blended method where workflow plays heavily on the project management side of things.

Support is support. Most of the stuff that will be going into support projects is probably going to be largely the same definition. If you allow every project doing support to heavily customize, you will either have to make a bunch of folks Admins who shouldn't be, or you are going to have a high overhead. Think of defining a common "template" for a project, so each project is 80% the same. 10% of the customization could be done via context of project for Jira. The last 10% is genuine need for difference, but it shouldn't be common.

For example, in a support instance of Jira we spun up it went from 5 projects for 5 different teams up to now 20. If we didn't define a project template and what is "common", we would be repeating the same discovery over and over again.

OK, got Greenhopper as an eval. Would you recommend starting as a Scrum or Kanban project for this particular situation? It's mostly tasks and milestone tracking that I'm going to be doing here.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,666 views 18 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you