nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to organize Jira for tiny team with many small projects

Net Palantir

Hello,

my team is just three people, and we do web design. We have basically two kind of projects: building new websites, and supporting (i.e. bugfixing and adding minor features) to the existing ones. We have been using to-do lists for quite a long time, but they are not flexible enough and don't capture process at all.

How would you organize this?

I could create one project for each new website that is to be developed, because there will be many stories, issues, etc.

However, I am in doubt about the websites I am maintaining. If I created one project per website, most of them would be empty, because the objective is to have most of the bugs and feature request done and closed as soon as possible. Those that are active, would usually have just one or two open issues each. Does it make sense to have one project for each of them? Or should I create a general "Support" project and open those issues there?

I do have one BitBucket repository for each project. However, one single Kanban board for all support issues whould be terrifically beneficial to organize this.

Thanks and sorry for the newbie question smile

Accepted answers

Bhushan Nagaraj_zb9hek

Ney Palantir,

First thing to note, you can still have one single Kanban board even if you choose to track your issues in multiple projects. Kanban boards depend on the JQL that you setup to search for issues.

Capturing issues in a single project or multiple projects? There are several factors you might want to consider and I have listed a few below for your consideration.

Who is creating the issues? If your JIRA open to your customers and end users? If yes, determine what would be simpler for the user. Consider using JIRA Service Desk if you are using it for support.
Does each of your website development and design follow a different process/workflow? If yes, you probably want to track them in different JIRA projects. Most projects might be empty, but this is not a concern.
Use Components field. Components allow you to categorize issues within a JIRA project. For example, a website design project can be categorised into issues related to design, database, browser, etc. If you choose to use a single project, you can also use components to track which website you are facing the issue with.

All comments

Bhushan Nagaraj_zb9hek

Ney Palantir,

First thing to note, you can still have one single Kanban board even if you choose to track your issues in multiple projects. Kanban boards depend on the JQL that you setup to search for issues.

Capturing issues in a single project or multiple projects? There are several factors you might want to consider and I have listed a few below for your consideration.

Who is creating the issues? If your JIRA open to your customers and end users? If yes, determine what would be simpler for the user. Consider using JIRA Service Desk if you are using it for support.
Does each of your website development and design follow a different process/workflow? If yes, you probably want to track them in different JIRA projects. Most projects might be empty, but this is not a concern.
Use Components field. Components allow you to categorize issues within a JIRA project. For example, a website design project can be categorised into issues related to design, database, browser, etc. If you choose to use a single project, you can also use components to track which website you are facing the issue with.

Net Palantir

I don't plan to give access to customers for the time being. Also, most projects do follow a similar workflow, although each one has its own peculiarities.
In the third point, are you suggesting to have one big project, with one component for each website? This solution occurred to me, but I dismissed it as a "hack" smile

unknown

I will have to do it one project per website with the relevant issue types ("Development", "Tasks", and "Support Request'). I don't see a problem with empty projects, or just don't create them yet if it does not have any issues on it. One advantage I can think of this is you can take advantage of per website "Versions" (components does not have versions).

Bhushan Nagaraj_zb9hek

Those "peculiarities" are what may require you to setup different projects.

Using components is to simply setup sub-categories within your project. How you choose to categorize, is left to you.

I also agree with @Gabrielle Bautista [ACP-JA] below. Project versions would be another consideration to add the the above list.

Net Palantir

Great, so I'll go with separate projects. Thanks for your quick & helpful support, it was a factor in the decision to purchase your service smile

Net Palantir

Thank you. I will do it this way.

jay vyas_pk3n6n

The most important thing here is your team culture, when it comes to organizing something like this.

For example:

- I wouldn't use JIRA for tracking *any* small (or even "medium" size) project unless the engineers were completely remote...

- Also I'd be cautious using it to track almost any size of project for a co-located team of passionate product owners and engineers.

The best example of this, is ironically, Atlassian's suite of alternate tools:

- Trello, Hipchat, Stride, ... demonstrate that JIRA is not a one size fits all project tool, and that its neither sufficient for tracking work, nor for communication, nor for project management in and of itself.

Why is a tool with so much inertia so ineffective for these use cases?

Because, as a tool ages in time, it has assumptions that are stuck in the past. Similar to CVS (central server) or relational database systems (assumptions around users in the 100s, instead of in the millions), most software technology (with the exception of lower level ones, the linux kernel for example, which is grounded in hardware rules that don't change rapidly) needs to be rebuilt every few years to match current idioms.

So, where does JIRA excel?

It excel's in mitigating risk for agile projects. Of course, nowadays, since agile is the norm, the need to mitigate risk for these projects is very low, unless you're a cell phone company, or the CDC, or some other real-time systems company with life-or-death circumstances.

JIRA excells in making sure there are timelines for execution, and small projects often dont suffer from timeline drift, so that value-add isn't really there to begin with.

Another thing JIRA excels in is accountability, but in a team with lots of small projects, often you dont need accountability because its inherent (the person contributing the most to a smaller project winds up often being the defacto owner, unambiguously).

And finally, JIRA excels at putting hierarchichal process, versioning, and sprint semantics into the way you work. Small projects suffer from this more then they gain. Using JIRA for a small project on a fast moving team is like using a semi truck to deliver a newspaper in manhattan... Its gauranteed to handle the load but also gauranteed to do so slower, with less finesse, and often times with more mistakes and miscommunication along the way then just travelling by foot.

For a team of A players that are prototyping or working on a large spectrum of projects, sometimes a confluence page, a trello board, or just a hipchat/stride channel w/ a status plugin is sufficient.

Lisa Prohuber

@Chris F very interesting

Lisa Prohuber

@Lisa Prohuber

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

jira

jira-software

jira-administration