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 · Accepted solution]

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.

[Trent Franklin]

This is probably just my lack of experience with the product thus far, but without versions how can we put a start/end date on a project -- or even down to a task level?  I'm not seeing those fields anywhere outside of versions. I do see an estimated time field but that's not something I can see us filling in often.  

We've already created the customer as a label field so I guess we're one step in the right direction.  In your chain, component would be the highest.  Are you suggesting to treat components as projects, then epics/stories/tasks/subtasks as to-do's within that project? 

[Yevhen Rohovets]

For start and end date you can use custom field Start date, and system field Due Date. 

> Are you suggesting to treat components as projects, then epics/stories/tasks/subtasks as to-do's within that project? 

Yes, I think with Components you can get more information in Reports and filters for different teams. Also, you can assign your PM or Team Lead like component lead. But, if with Versions you feel yourself more comfortable, it is ok, it is not a showstopper for your work

[MB]

Very helpful exchange of information.  I would be interested in seeing a visual of what your board looks like in following this structure or even an update of how you sorted it.

Many Thanks,

M