Need advice on setting up project(s)

Dina Barnese

I am in need of some advice for the best way to set this project up. We are running JIRA 5.2.5 with Greenhopper. I have been tasked with taking a set of small related projects and putting them into the system. These are not development projects, but rather projects to produce printed materials from a marketing department. The person who was managing this previously has volumes of emails and documentation scattered. I am charged with getting it all organized and using JIRA and Confluence to do it.

My questions here relate specifically with setting the project(s) up in JIRA and/or Greenhopper.

In the past the teams have been using a kanban board (not in JIRA). They set up a card which includes a checklist of items that need to be completed. They move the card through the columns as items are completed and the person managing the project checks off items as they're completed (whether by her or others).

Problems that I need to address: There is no issue assignment - a single card moves through the board but different people are responsible; there are no notifications of when a project is ready for the next step or when items are completed without manual intervention by the project manager. People don't know when things are due without checking individual cards. The projects need to be presented in a visual environment (as opposed to ticket/issue lists)

My questions:

1. Should I set this up as a single project with multiple components? What would be the advantage of either?
2. Should I still use one card and have it reassigned throughout the process? Using workflow or training people to reassign? (Problem here is that I don't see how I can do resource leveling if we only have one card/issue?)

As an aside - I've been using/learning JIRA and Greenhopper for about three months. I've taken all of the end-user training and have attended a JIRA workflow training session (online). I have a lot of concepts in my head but figuring out how to configure things is challenging.

Thanks!

Dina

J. Caldwell

So...my two-bits worth.

If you have an overall item you need to do, that needs to be managed, but tasks are done by different people, you should be looking at the scrum model instead of Kanban and be using epics/stories. That gives you that cascade of item responsibilities. Best way to think about it:

Project - Should be the big bucket. If you have a BU/Area, but all this work is happening for that BU/Area/Product, having that be your project would be good.

The specific for the printed matrials - E.G. you have a new product pamplet for Q1, could be either your story or epic. It depends on how many levels/splitting you want to keep track of. If you chose that to be the epic, you could have a story be "Photography", with tasks/technical tasks of "Take pictures", "Select pictures", "clean up pictures." Another story could be "Text for product", with tasks of "Product 1 copy", "Product 2 copy". Your story can't complete until all the stuff under it is done, likewise with your epic. The nice part about that is you have ownership of the tasks. You can make the person who owns the epic be the assignee, likewise with the storys and subtasks.

Componets can be used as an extra layer of granularity for reporting. Adding filters for the project in Greenhopper will allow folks to see the stuff that they care about.

So what I'm saying is "Multiple Cards."