What is our primary use case?
We mainly used Jira for backlog management within IT development landscapes. We used Confluence for early-stage documentation and communication within and across teams.
Since we worked mostly with large enterprises, they typically install and host any server-based solutions on their own.
What is most valuable?
The interesting thing is the connector between Jira and Confluence (it works wiki-like and provides a deep-connection with links between both systems). The alternative is to run for early-stage backlog-items in immature state a separate wiki-instance that would not feature the proper linkage of backlog-entries automatically.
What needs improvement?
With respect to Confluence, it would be interesting if they had graphical templates that allowed typical agile ceremonies to be documented better. For example, one of the agile cadences that we regularly run is risk roaming. Confluence, as of now, doesn't provide any kind of graphical support for creating a two-by-two portfolio matrix design or even something similar. Basically, Confluence is heavily text-based. Some of my customers have actually started to tweak the system a bit and implement workarounds. On the screen, you can make it look as if it is a two-by-two portfolio; however, if there were templates provided, that would be great. The basic graphical templates that are used regularly in management would be fine. It would be great to see them supported in the future.
In regards to Jira, it would be nice if they had two-dimensional features for backlog support. At the moment, backlog management is always a flat, one-dimensional list but our customers actually prefer having the opportunity to have that read out in a graphical fashion as well. That way, there's so much more overview and they can cluster smaller backlog items that come as a bunch. It just provides much more clarity.
Jira still seems to have issues on modelling Kanban-systems - as far as I know it still doesn't support the so-called "commitment point" (i.e. creating a non-romovable time-stamp when moving a ticket onto a board) helpful in creating transparency about start- and end-time of performing an activity — similar to signing a document in writing.
Think of it this way: if you take an item into a boardroom, it must be noted and signed. It should be done in pencil where the data could be erased later on, rather, it should be stamped — basically, you are not losing the data again. That is still an issue with these systems. That's one of the reasons why many teams who want to run Kanban methodology don't want to use Jira. They tend to use other software, which is able to do these sorts of things.
For how long have I used the solution?
Until 2018, I was employed with an applier of Atlassian solutions. Within that context, I used Confluence for a year. I have used Jira 2012—2018 as an end-user myself. From then onwards, I was more of a consultant to other companies implementing and using similar solutions. In short, if you count only end-usage, then it's 6 years with Jira and one year with Confluence.
What do I think about the scalability of the solution?
With respect to our experiences with Confluence, we haven't had any issues; however, we definitely have had issues within the Jira environment back in 2014.
Scalability issues should have been fixed by now - they arose back in 2010-2014 at one of the largest enterprise implementations for multi-1.000s of concurrent users on the system, causing the system to operate very slow - I would expect that by 2020 this is treated accordingly to make the system scale without loss of performance.
How are customer service and technical support?
I have not personally contacted Atlassian's technical support. It was always routed via the respective IT staff, which I was not involved with.
How was the initial setup?
I was not involved with technical administration or the implementation procedure from an IT infrastructure team perspective. For this reason, I can't speak for individual customers.
What's my experience with pricing, setup cost, and licensing?
The problem with the pricing model is not so much the price for the Atlassian basic software itself; the issues I have with the pricing are in respect to the add-ons. The problem with add-on pricing is that it typically is always calculated based on the amount of basic Confluence or Jira licenses. Since some of the add-ons will only get used by a very limited number of users, having to pay for the full implementation (for all the people using Confluence or Jira), seems like an unfair pricing model. It also prohibits the usage of certain add-ons, too. Certain add-ons from a functionality-perspective are much more exclusive to only a few users. That pricing model should be reviewed and potentially edited or amended to make it more flexible.
What other advice do I have?
On a scale from one to ten, I would give this solution a rating of eight. If they added the graphical templates, I would give them a higher rating.
To me, as an end-user, the topical templates are pretty basic. Under the current conditions, since COVID-19, our teams have tried to become more virtual in their collaboration model. The collaboration model that we had installed before, face-to-face, couldn't be transferred, which is kind of a pity because the graphical features are missing.
Which deployment model are you using for this solution?