Simple project management - best practice / how?

XDarren Jones

I'm wondering how to set things up so that JIRA works well from a developer point of view, but can also give a high-level project overview at the same time.

Say we've got ~15 teams, and ~6 people per team. Each team might 'own' ~10 development projects at any given time. Devs might work on projects owned by other teams. (I'll call these devprojects, to avoid confusion with the JIRA concept of Projects).

I think that the Greenhopper Boards are really intuitive, in terms of easily visualising backlog and statuses of where the work is up to, so would like to base the setup around that, for both devs and management (but obviously with different views). I also want to keep things as simple as possible, generally.

The obvious solution would be, I think:

1. Have 1 JIRA Project per team
2. Use a 3-level Issue Type hierarchy: Devproject -> Tasks -> Subtasks. (So mgmt would only be interested in the top level; devs in the other two levels; team leaders would be interested in all 3 levels).
3. Have Board(s) showing only issues of type 'Devproject', for mgmt
4. Have Board(s) showing only issues of type 'Task' and 'Subtask', for devs
5. Have Board(s) showing all issue types, for team leaders.

Advantages:

• Very simple and intuitive
• Time tracking can be easily rolled up to the parent ('Devproject') issues, for reporting etc

Disadvantage:

• JIRA won't let me set up a 3-level hierarchy, only a 2-level hierarchy (tasks/subtasks)

So, what are my other options here? I'm also considering:

1. Use a Devproject issue type as parent, then every 'task' in that project is a subtask.

Advantages: Still very simple; time tracking rolls up perfectly; reporting easy.

Disadvantages: Large projects may have very large numbers of subtasks; lose ability to break down complex tasks for the devs, because they only have 1 layer in the hierarchy - everything is already a subtask.

2. Use Epic/Story/Task.

Advantages: That *is* a 3-level hierarchy, so solves the problem.

Disadvantages: Only applies in Scrum(?) - we'd want to use Kanban boards too; problems with roll ups(?); would want to use different names than Epic/Story/Subtask, which isn't possible(?); generally more kludgy and far less intuitive(?) - see eg https://answers.atlassian.com/questions/72394/manage-epic-stories-in-jira-greenhopper for some of these concerns.

3. Set up a separate org-wide JIRA Project for the mgmt view - so all devprojects are represented as an Issue in this project. Each team still has their own JIRA Project, where all the work lives, as tasks/subtasks. All these tasks/subtasks are linked back to a devproject, using Issue Links.

Advantages: Simple-ish, esp from the mgmt point of view, in terms of seeing project statuses etc

Disadvantages: devs have to remember to create links back to the appropriate "mgmt project" issue for each new dev issue; time doesn't roll up to the "mgmt project" issues (but perhaps this would be achievable using scripting?)

4. Just use Labels, Components, Versions etc to tag things together into devprojects.

Advantages: Easier for the devs, probably

Disadvantages: The mgmt view becomes much harder, as how do you record the devproject metadata (status, time worked, etc?); labels can't contain spaces, which complicates things, and are case sensitive, so unreliable for this purpose; components can't be shared across JIRA Projects; want to use Versions to identify 'phases' of devprojects, ideally.

5. Use Structure plugin.

Advantages: Would obviously allow a n-level hierarchy of issues.

Disadvantages: A lot more complicated, overkill really; not baseline JIRA; not available OnDemand (which we currently are); reporting issues?

Excluded: I have ruled out creating a JIRA Project for each devproject, because there would just be too much admin overhead, and I'm not sure how one could do simple mgmt reporting, at-a-glance, for >50 projects (whereas this is doable on a Greenhopper board, having an issue per project).

Please, any thoughts? Anything I've got wrong, or missed? In some ways, #3 looks like the best approach, subject to being able to kludge the time tracking somehow. But given the lack of resource we've got for customising etc, I'm thinking that reluctantly #1 is the sensible approach.

It's incredibly frustrating, because if we could just have subtasks of subtasks, this would be a total non-issue.

Thanks!

Justin Alex Paramanandan

I've been reading this issue for some time, and thinking hard on a possible structure to perform such a monumental implementation, but I have an idea on how you can do this.

*I'm suggesting this based on the requirements you gave, and in particular, point no. 3*

The idea here is to have a general overview of a particular issue from the management perspective, and a breakdown of that perspective into several sub-issues; and each sub-issue would have their respective sub-tasks.

The usage of a general development project only for the manager would be an ideal solution, as the project is only populated with issue overviews rather than development issues (in which the developers logged their work against).

Then, have another project specifically for development purposes and issues created in this project would have their related sub-tasks for a breakdown of tasks that requires some logged work.

Now, the above suggestion would be the ideal solution for your requirements. However, that still leave two areas:

• "devs have to remember to create links back to the appropriate "mgmt project" issue for each new dev issue"
• "time doesn't roll up to the "mgmt project" issues"

For the first scenario, what you can do is to set the Linked Issues field in the field configuration as Required. This will ensure that issues created in the development project would have to have the issue links set (which is linking the development issue to the parent management issue). Also, do remember to set this field configuration for the main issue types rather than the Default; this is to avoid sub-tasks from being affected by this as well.

I guess for the second part, I can't think of a better way to properly integrate this but to use a notification scheme setup to ensure that managers/lead developers will get notified when a development issue has been resolved/closed, and update the appropriate section in the management issue (maybe a new custom field, or perhaps updating the time spent/estimate values?).

The suggestion above might be a tedious and tough process to consider, since I'm looking at this question and putting the OnDemand restrictions into the mix.