nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Jeff Wright7

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.

Accepted answers

J. Caldwell

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?

All comments

J. Caldwell

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.

Jeff Wright7

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.

J. Caldwell

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.

Jeff Wright7

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.

J. Caldwell

Make sense?

Jeff Wright7

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira