How can a Web Development Agency use JIRA

[Emanuel]

I've been trying to figure out how to best use JIRA for my company (or if it's even a best fit) but I need some assistance. We do not need a Service Desk, but rather an internal system to manage our work.

I run a web development and design agency and we have ongoing projects, short term projects and also clients who come back to us for more work. We have separate departments for development, marketing / SEO and WordPress websites, and we want to make sure that we keep them separate (i.e. we don't want the SEO guys to be able to see the work performed by any of the other departments).

Since we want to make sure that we can easily go back and see all the work that was done for a specific client, I was thinking of creating a Project for each of our clients, then using Sprints inside the Project and having separate Sprint for each of our departments. For example, Client Bob could have a Sprint for SEO, another one for his custom web app and another Sprint for his WordPress website. However, the problem with this is that everyone who has access to Bob's Project, would be able to see all the Sprints, which we don't want.

What would be the best way to set something like this up and make sure that the departments don't have access to each others work, while at the same time making sure that it's easy for the admins to see all the current and past work that was done for a particular client?

[Capi [resolution]]

Hey Emanuel,

Your setup is a bit complex but I think you should be able to get closer to what you need if you just replace sprints with components in what you said above.

• You can configure component-based permissions and group your users accordingly, so they only can see the piece of the project that affects them
• You can work on separate components at the same time (you wouldn't be able to do that with sprints, for which there can be only one open at any given moment inside a project)
• Creating one project per customer is a good idea!
• You can also check the Marketplace for more advanced functionalities. For example, if you use DEISER's Profields (for full disclosure, I work at DEISER and Profields is a product I know well so I can give you a working example) you could create cumulative fields to give you an automated overview of how much time has been spent in each of the components and how it compares to your original estimates. It's also a good practice to create project layouts so you have standardized information about your clients within each Jira project in your instance.

Without knowing the requirements a little bit closer I can't say much more, but I hope this helps. I'm sure you can get Jira to work for you.

By the way, are you trying cloud or server?

[Emanuel]

Thanks for the fast reply and good advice Jaime. 

I'm trying JIRA Cloud, not server.

Would we lose any important functionality if we used Components instead of Sprints? Can we still set a start and end time for components and will we be able to easily see all the past work that was done for a particular client?

[Capi [resolution]]

@Emanuel: No, components don't have start and end dates. Depending on how you manage timelines you could still use sprints for planning iterations, though, and include in each sprint work from different components that needs to be done within that time. You could have some sprints with work for SEO exclusively, one with design and also testing tasks, etc...

And if you don't assign issues to any component, they will be visible to everyone. 

[Tomaz Alexandre Macedo Rodrigues]

I advise you to take the Jira Admin Jumpstart Kit course, you will see the best ways to accomplish what you want, have a way of blocking so that only the dev team can access some areas, to document a glance at the confluence.

[Mike Rathwell]

Hi @Emanuel ,

I actually run a Jira instance that covers not only the Devs and other technoweenies but also for all the Marketing, Creative, Legal... well... basically if something moves here and there is a process attached to it, it's in Jira. SO.... what you're trying to do isn't out of the realm of reason. In your case, while I've got some reservations about a project per client (can easily get out of hand) I can see your logic there.

One bit that isn't being talked about and is hyper-useful in this instance is "versions" and setting the "Fix Version/s" value there. Using this and the issue type Epic, I have a 4 level gradation of any project:

• Version (in your case might well be the particular project for a given client, rolls up all the issues under that version AND has a start/end date along with the ability to "release" it when the project is done.
  • Epic (use this for a container of relatively big tasks)
    • Standard issue type (the things you need to do)
      • Sub-tasks (the specific items to deliver the elements that make up the epics)

You can also use Issue Security (kind of a PITA but not THAT bad when you get into it). That way you could either manually or in a workflow set an issue security level (named human usable things) that certain groups of people can see... That way you could, for example in a given project, have an issue security for Wordpress and another for whatever. That way you COULD have all the stuff for a client in a given single client project AND hide certain issues from some people. With Jira, it's not that they see it but can't access them... to them they just don't exist

[Emanuel]

Thank you for the detailed response Mike. I'm a bit confused on how I would limit the access of certain groups with the "Version" example that you provided. Would I need to use Issue Security for that?

I'm not sure why there is no easy way to limit what tasks a certain user (or group) has access to inside a project.

[Michael Schoolcraft]

Hi @Emanuel 

Did you ever manage to find a solution for this?

Our agency has a similar setup to your from what I can understand, and we have been looking into Jira.

We especially want to have a clear segmentation between our Clients, but aren't sure that using Jira's "Projects" is the correct way.

I know this is 2 years late, but if you managed anything, we'd be interested in hearing about it! Cheers