JIRA Project Structure and Versions with Vendor Software

[Scott Spyrison]

Hello,

We are a lean IT organization that does both custom development and manages off-the-shelf products from vendors. Additionally, we handle the integration, maintenance, identity management, and reporting needs between all our various systems.

We are new to JIRA and Greenhopper. My question is, can anyone offer guidance or lessons learned about representing vendor software in JIRA along side software development projects? Perhaps like DevOps, but including off-the-shelf software (lots of it).

Right now, I am leaning towards breaking out each vendor's off-the-shelf system as a project, and using components to represent things like Database, Significant Submodule1, Hardware, etc.

I am also leaning towards using JIRA Project Versions to represent the currently installed version, as well as major milestones or projects (like MS Project) in the continuous lifecycle of that system, such as Major Upgrade 5.1.

If I were to use PeopleSoft as an example, I might do the following as a project structure. We do not actually use PeopleSoft, so if I have any terminology wrong please forgive me:

• PeopleSoft JIRA Project
  • Components
    • Database Component
    • Network Component
    • System Component (Hardware/OS/Storage)
    • HRMS Component (HR Module)
    • FMS Component (Finance Module)
  • Versions
    • HRMS 9.0 (Released - represents currently installed version, could be used on issues with Affects Version)
    • FMS 9.0 (Released - represents currently installed version, could be used on issues with Affects Version)
    • FMS 9.1 Upgrade Project (Start and End Date, used on issues with Fixed Version to associate them as project tasks. Can be renamed to FMS 9.1 when released.)
    • HRMS 9.1 Upgrade Project (Start and End Date, used on issues with Fixed Version to associate them as project tasks. Can be renamed to HRMS 9.1 when released.)
    • HRMS Address Form Customization Project (Start and End Date, used on issues with Fixed Version to associate them as project tasks.)

From that structure, I think we could effectively use JIRA versions to represent milestones, MS Projects, as well as actual version numbers.

I have left GreenHopper out of the mix here, but I think that's OK. If project managers can effectively use Epics and Sprints to organize work, I believe that complements the above JIRA project structure.

Feedback and advice would be welcomed and appreciated!

best,

scott

[AhmadDanial]

Hey there, Scott.

Just a suggestion here. Have you tried to look into Atlassian University (http://www.atlassian.com/software/university/overview)? It is a training tool that provides you with user-friendly tutorial on how to make the most of the Atlassian product (in this case we are dealing with JIRA and/or GreenHopper). Not too sure whether it applies to this but hope that it might be able to shed some light on this.

Warm regards,

Danial

[Scott Spyrison]

Atlassian University is great, but I'm not really looking for training here. Just looking for advice and lessons learned from the field. The scenario I describe is not unique to me, and JIRA can be configured many different ways to cope. The only answer may be, "whatever works for us," but any advice welcomed.

[AhmadDanial]

Hey there, Scott.

Thank you for the prompt response. With that being the case, I would also like to recommend you to contact our Atlassian Expers (http://www.atlassian.com/resources/experts#find-an-expert) as another alternative that you can consider. They might be able to advice and give recommendations to this. Good luck!

Warm regards,

Danial