
Jellyfish Software Engineering Intelligence Platform
Data-driven visibility has transformed planning and now optimizes engineering and QA collaboration
What is our primary use case?
Jellyfish gives us real visibility into engineering work and Q&A bottlenecks that Jira alone could never provide. We are about 45 engineers, including 10 QA test engineers. Our primary use case for Jellyfish is mainly to get end-to-end visibility into our SDLC. Before Jellyfish, we had Jira burndown charts. We had no idea how much time was going into new features versus bug fixes, versus keeping the lights on. Now Jellyfish connects to our Jira, GitHub, Jenkins, and Slack.
How has it helped my organization?
One positive impact Jellyfish has had on my organization is that it reduced unplanned work. We found that 30% of our QA time was going into production hotfix testing, which was not planned. With Jellyfish data, we created a dedicated buffer for unplanned work in sprint planning. Unplanned work dropped to 12% in three months. It has improved developer-QA collaboration and led to better sprint estimation. We started comparing estimated versus actual allocation. Now our sprint predictions are 85% accurate versus 50% earlier. There are no more last-minute release postmortems. It also helped identify bottlenecks in QA where Jellyfish showed that tickets were stuck in 'Ready for QA' status for an average of 1.8 days due to environment unavailability. We then containerized our test environment with Docker and Jenkins, cutting wait time to four hours.
What is most valuable?
The best features Jellyfish offers are Allocation and Investment View, seamless integrations, DevEX and delivery metrics, Team Health and Work Profile, Executive Reports, and justified test automation investments, improved developer and QA collaboration, and better sprint estimation.
The Allocation and Investment View stands out for me as a killer feature. It shows us exactly where engineering time is invested, such as roadmaps, bugs, infrastructure, and KTLO. This helped us balance feature work and quality work. When it comes to Executive Reports, they provide very clean dashboards that even non-technical managers can understand. There is no need to explain Jira queries anymore.
I would also say the seamless integrations are impressive. The Jira plus GitHub plus Jenkins integration took less than 30 minutes. It automatically maps commits to Jira tickets, so no manual tagging is needed.
One positive impact Jellyfish has had on my organization is that it reduced unplanned work. We found that 30% of our QA time was going into production hotfix testing, which was not planned. With Jellyfish data, we created a dedicated buffer for unplanned work in sprint planning. Unplanned work dropped to 12% in three months. It has also improved developer-QA collaboration and led to better sprint estimation. We started comparing estimated versus actual allocation. Now our sprint predictions are 85% accurate versus 50% earlier. There are no more last-minute release postmortems. It also helped identify bottlenecks in QA where Jellyfish showed that tickets were stuck in 'Ready for QA' status for an average of 1.8 days due to environment unavailability. We then containerized our test environment with Docker and Jenkins, cutting wait time to four hours.
What needs improvement?
A few areas for improvement are that the initial onboarding period needs patience. The first two to three weeks, the data looks inaccurate until it learns your Jira workflow and Git patterns. The documentation for investment categories is confusing. Additionally, the interface can be slow when you filter data for six or more months.
I would also say the pricing is on the higher side, especially for smaller teams working under a tight budget. This means it may not be suitable for startups below 20 engineers. Jellyfish should improve the mobile dashboard view as well.
For how long have I used the solution?
I have been using Jellyfish for the past nine years, even in my previous organization.
What do I think about the stability of the solution?
Our stability experience with Jellyfish over the last five years has been excellent. I would rate it a nine out of ten. It is a very stable SaaS platform. We have not seen a single major outage where the platform was completely down. In about three years, I remember only two times when dashboards were slow to load for about 15 to 20 minutes, and their status page showed they were doing database maintenance. They have a status page at status.jellyfish.co, and they are very transparent.
What do I think about the scalability of the solution?
Scalability experience with Jellyfish has been very positive. We started with 35 engineers in our department, and now we are over 50 engineers, going to 60 next quarter, and Jellyfish handled the scale without any issues.
How are customer service and support?
I have had to reach out to them a couple of times, and my experience with them was great. They are quick to respond to any of our questions or disasters, and they are also solution-oriented and very professional.
Which solution did I use previously and why did I switch?
We still use Jira. We did not switch from it. We switched from only Jira reporting to Jellyfish plus Jira combined.
How was the initial setup?
The deployment of Jellyfish in our environment is very easy and straightforward. It is a SaaS platform, so there is no heavy infrastructure to manage from our side. We did not need to provision any servers or databases.
The configuration process experience with Jellyfish was smooth, guided, and well-supported. It is not a plug-and-play tool where you just connect and forget. You do need to configure it properly to get real value, but the Jellyfish team makes it very easy.
What was our ROI?
Before Jellyfish, we saved $15,000 per year in reporting time. Because before Jellyfish, our engineering manager, QA lead, and I spent 10 to 12 hours per week manually creating reports from Jira, GitHub, and Jenkins in Excel. Now Jellyfish automates all of it. This is approximately 40 hours per month saved across the team. If we calculate at $40 per hour engineer cost, that is around $19,200 per year saved just in reporting. We have also seen faster release cycles with a 30% improvement, a reduction in unplanned work, enhanced QA efficiency and cost savings, better resource planning, and a 40% reduction in bug leakage into production.
The deployment frequency has increased by 30%. Lead time for changes, especially commit to production, reduced by 42%. Cycle time in progress to done reduced by 28%.
What's my experience with pricing, setup cost, and licensing?
Jellyfish pricing is based mainly on the number of engineering or contributors whose data is being tracked, not per viewer. If you have 45 engineers committing code, you pay for 45 contributors, but you can have unlimited managers or viewers for free. This was good for us because we had 10 managers who needed view access but do not code. The price or the plan depends on your number of engineers.
Jellyfish is a premium price tool, not a cheap tool, but for us, the return on investment justified the cost.
What other advice do I have?
My advice to others evaluating Jellyfish, as a software test engineer who has used Jellyfish for about nine years and was part of the evaluation team, is to not evaluate with fake data users. Use your real Jira and Git data. Spend time on investment model configuration. Do not try to replace Jira.
If you are 20 or more engineers and tired of Jira plus Excel reporting, Jellyfish is worth every dollar. It changed how we manage engineering from gut feel to data-driven within a period of three to four months, which was a great thing. I would rate this product an eight out of ten.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Powerful AI Insights and Clear UI That Unify Engineering Data in One Place
Insightful AI Usage Tracker with Easy Setup
Quick, Clear Team Progress Metrics at a Glance
Strong effort-allocation engine for engineering exec reporting
On top of that, I've seen the per-tool detail figures and their aggregate rollups diverge by around 10 percentage points, which is a real problem when the aggregate is the number going in front of the board. Both issues are workable, but they add reconciliation and extraction steps to what should be a clean pull.