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
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.
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"
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.
You will may also find these tutorials really helpful for your team (beta free till May).
JIRA for Software Teams
Git the Atlassian Way
Picking up on something you said above that might be of use in my business...
"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."
I am a Jira Core newbie also. How do I create one Kanban board to see issues across all my projects? Many thanks in advance!
Kanban boards can be based on JQLs. Setup a search across all the projects you would like to include, save it as a filter and set the permissions to public access.
Then go to your Kanban board configuration and select the filter as your issue source.
Hope that helps.
Have a look at the link Bhushan gave in his last comment. JQL is a language for doing advanced queries (filters) in Jira. You don't need specialist knowledge, Jira's advanced search does quite a lot of hand-holding, pre-filling and auto-suggesting things for you.
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).
The most important thing here is your team culture, when it comes to organizing something like this.
- 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.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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