Project Organization Help

Trent Franklin

Hey all,

 

My department is responsible for working on multiple different customer projects.  Each customer can also have multiple projects going on at the same time.  As a company, we have two development groups in addition to our service/project team.  The development groups are already well down the line in using JIRA for task tracking and customer support.  I've only recently started evaluating it as a solution for our group. In total, there are currently ~10 projects on the main company workspace, ours now included.

 

What I'm struggling with right now is trying to understand how to effectively group our agile board such that we can track, view, and work through projects effectively.  My first instinct is that I would probably want a separate project for each customer, then to maintain a board separately for each customer based on their active projects.  The reason I think this is a bad idea is because from a global view when logging into the main JIRA page, everyone would be inundated with every project we've created.  With the granularity of filtering it also seems pretty unnecessary since I'd be able to mimic most of this within the same board anyway.

 

So the next best thing -- put everything into a "Project Team" project.  Inside each project will just be epics/stories/subtasks/bugs.  We then created a field for "Customer" specific to this project that we can roll into each task and filter by.  This is where I'm a bit stuck at the best way to group it.    I'm not sure if we should consider using versions or not since this isn't a "true" software design, but instead a project with a start/end date.  I tested using versions as the project, then tested using epic as the project and I can't really see a pro or con to using one over the other for my purposes. 

 

In my head it seems like the workflow would go: Version->Epic->Story->Task->Subtask, but it seems like story and subtask are the same. So in my case, a Version is a project, an epic is a big task, a story/task is a story/task, and a subtask is a subtask.  Consequently, I can just ignore Versions altogether and assume an Epic is the customer project with a ton of tasks/subtasks underneath it.  Again, not sure of the pros/cons here long term.

 

Any advice on the best way to proceed with this would be much appreciated!

Yevhen Rohovets

Hi, thanks for the detailed description.

First of all, I want to say that you can create one board for different projects, thereby distinguishing between visibility. The board can also be made separately for each developer or by the team.

Secondly, look at using a Component instead of Versions, this seems to be a more logical phenomenon. Indeed, conducting everything in one project seems right if you do not have a huge stream of tasks for all projects.

The chain of tasks I would do this: Component-Epic-Story-Task-Subtask.
You will still try out the hierarchical difference between the Epic of History and the Task, and you can better group tasks using components and epics.

 

For field Customer, you can use a label. It is a cross-project field, and you can use it for filtering.