How to use JIRA for my project.

fastersaec

Hello Guys,

Im Badly looking into solution for my project.

Example: i have different team for everything like Design, UI, Coding and Testing

Each team has different set of activity to perform to complete one modules. Note: we have around 50 modules as part of single project.

I'm not sure what would be best way to use it in JIRA.

Note: using Sprint as development methodology for our project.

 

Can any body explain: how epic , user stories will be used and what to mapped to it... please help

 

 

Mike Rathwell

Hi @fastersaec ,

Welcome to the world of Jira and its new user feeling of the weird dichotomy of "it doesn't do much out of the box" and that feeling of "this thing is huge" lurking in the background. That said, from your question, you are already heading a good direction to keep each of your different teams in their own projects so their processes and work can work in their own way without impacting other teams.

As such, I'll start with your immediate discrete question about epics, stories, etc., and then some general things to help you on your way (or at least things to start looking for as you start this journey).

In Jira, the base element of a "thing" is the issue. What you cited are a set of different issue types and, with that , different categories of issue types. In brief, and as delivered out of the box, Jira has as an issue hierarchy: 

• Epic (big "thing" that contains the smaller things to make it happen)
  • Story (the set of things to make the big thing happen)
    • Subtask (the small detailed things to make the story a reality

Of these issue types/categories, the one that is "locked down" is the "Epic" with it being (out of the box) the only issue type that can exist at that level of the hierarchy. However, a "Story" is merely a pre-packaged issue type in the "regular issue" category and "Subtask" is a pre-packaged issue type in the "subtask" category. As such, you can create new issue types called whatever is meaningful in your environment in the regular and subtask categories and have them respect the above hierarchy.

With that stated, now, there is the rest of this giant thing to look at and, while that is rather larger than a breadbox, I'll give you a few places to start looking as you get started with this.

• Visualization and project management
  • Your PMO (and your teams, actually) will need a way to see all of this stuff. Kanban and Scrum boards can sweep in relevant elements to a component of your overall project from multiple teams to single boards. Additionally, adding a tool like one our PMO uses and loves, ALM Works"Structure" plugin provides a great way to visualize and manage all the issues that make up a given project.
• Workflows
  • The basic workflows will work to let you run stuff. However, as you progress, remember to not try to force fit your process to the stock workflows. Make workflows that fit your process. Start small. Copy a default one and make small incremental changes as you go along to alter to fit.
• Issue types
  • The default set of issue types will get you going. However, you eventually will want to start to build out issue types that are semantically meaningful to your environment beyond the base set of Epic, Story, Task, Sub-Task, etc.
• Statuses
  • As with issue types, the default status set will get you going. However you also will start to want to make statuses to put in your own workflows to fit your world.
• Custom Fields
  • You will want to start keeping specific information in a specific way for each of your issues in the various realms. Make custom fields for this. If you try to rely on open text fields like the default summary and description, searching for issues will be... problematic. You also will likely want to do things like add extra date values to issues beyond the "due date".
• Issue linking
  • Use this. A lot. It helps. Also, you can make new link types that are meaningful to your environment with meaningful inward and outward descriptions.

With that bit of drinking from a firehose now stated, and remembering that you will eventually fall into the issue security, etc realm, that should get you started on places to start working with this thing. I highly recommend that you spin a test instance and a methodology to migrate your production data to test so you can try things there with little consequence. Any of the well written Atlassian pages or very good examples in the Community here of how to migrate a Jira instance to a new server (which is what making a test instance really is) will serve you well.

With that... good luck and as you have more questions which will become more specific once you get past the "what the heck do I do with this thing now" feeling all of us went through, do reach out here and/or look here for potential answers. There are a lot of us that, while some might suggest we question our life choices that got us here, enjoy working with Jira and are happy to help.

Mike