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:
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.
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:
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.
Thanks very much for the suggestion. I agree that it sounds like the best compromise. I think we're going to move to a self-hosted implementation so I hope this will also enable some time-roll-up kludging, somehow. I don't think that bit should really be high priority anyway, on reflection. (Although if you've got any suggestions on that front, I'd be grateful for them too! Hopefully there's something a bit more 'out of the box' than writing some custom REST API stuff from scratch...)
Sorry for the late reply. Work caught up on me! :)
I would agree that the time roll-up is a tough implementation to integrate into your system, but I guess that's how JIRA works on this front; because we are looking at JIRA in the perspective of a project management tool and it remains a tool to ensure that a user would remain in focus on the projects that are related to them (devs focus on development projects, managers focus on managerial projects).
It would throughly depend on how you have drawn up the idea of utilising the time tracking module in JIRA. Would you like to track specific management projects? Or would it be easier to manually input the time spent into a custom field for managers to view? It would all depend actually. :)
To answer “How scrum works,” most of the teams I've worked with first addressed the question: “where to start?” That question applies to both implementation and improvements on the Scrum framew...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs