Does Jira really suck?
Recently I went to a Product Manager Meetup and I couldn't help but notice that throughout the conversations almost everyone present complained about how much Jira sucks at least once - including myself.
Recently I went to a Product Manager Meetup and I couldn't help but notice that throughout the conversations almost everyone present complained about how much Jira sucks at least once - including myself. Yet again, everyone is using it, including myself and it's definitely not for a lack of alternatives available on the market. So I was reflecting on the tools that I work with on an everyday basis for my work at Educatly and noticed that Jira is invaluable to us - because we learned to use it for its strength which is allowing engineers to collaborate in an agile project - and for everything else we integrated Jira with Google Sheets!
Educatly is one of the hottest early-stage startups for the MENA region. I joined them last year to serve on the board as VP Product to support their mission to provide an educational opportunity to every education seeker, as it deeply resonates with my mission to reduce borders in the world. I’m here to make it easier for students to find educational opportunities abroad.
As an early-stage start-up that has yet to receive major funding, we started with minimal investment from its founders. A major portion of this investment of our platform which is currently developed and maintained with a fixed scope contract by our trusted development partner Commutatus, a start-up based in Chennai, India.
As of now, our platform development might not be the fastest (for a lack of resources), yet there's a lot to do. Much more than what could fit in a single sprint and with our priorities sometimes changing very quickly, it was imperative for me to always keep an overview of each sprint's progress as well as the high-level roadmap. As I also wanted to provide visibility and transparency to my other stakeholders in Educatly, I couldn't rely on tools such as Confluence or Jira. It wouldn't offer me the tools, visualizations or sharability that I was looking for on a daily basis, so I went and created my own.
Cue in, my own Sprint Tracker.
At first glance, the sprint planning tracker is not an immense feat of engineering. It was born out of the need to know whether we're putting our effort into the right initiatives (by giving visibility of % effort spent on component and ticket type), whether our vendor is consistently performing (% sprint completion) and how much money we're spending (Time Spent). What I'm proud of is that it is always updated, even as the sprint progresses. If I wouldn't be able to update it so swiftly, there'd always be a pain in using it which would lead to me not using it and thus not updating it and thus not serving transparency for my stakeholders. I myself, I simply have to open this report and see a birds-eye view on the first glance. As we're paying our developers based on the Time Spent and not Story Points, Jira is not able to give me any such reports.
Now, where does the information come from? This is where the Sprint Planning Sheet comes in.
For every sprint, there is a sheet just like this. It is where I plan my sprint, communicate the priorities to our vendor and where all calculations for the Sprint Tracker are being made. Whenever a new sprint starts, I simply have to create a copy of this sheet, put the tickets that I want the developers to focus on and let the magic unfold.
So let’s see how we can build it on our own. Don’t want to go through the trouble of building it on your own? You can get it here directly.
The idea is quite simple. The main source of information is the Jira Cloud For Sheets Add-on with which you can predefine the fields you want to import, automatically on a recurring basis. The sprint sheets automatically pull the right tickets to build reports on each individual sprint and then combine it to the overall report.
For this, we create a new tab called Jira import and open the Jira Cloud for Sheets add-on.
It gives you the ability to either use a JQL query or an existing Filter that you created in Jira to pull your tickets. A suggestion is not to pull all tickets from your project but only the ones you would want to be tracking. Then you can select the Fields that you want to pull. This is important. You would want to pull only the most important fields, in order not to reach the Google Sheet limit of rows too fast. In my case, I am pulling only the information I am actually going to need to create my reports: Issue Type, Key, Priority, Summary, Status, Created, Components, Time Spent, Sprint. Sprint needs to be the last one. Do not forget to set up a recurring automated import, by selecting Refresh Data Sheet. After your first successful import, it will give you the option to Scheduled update.
This is because properly analyzing Sprints is where the major difficulty lies: in Jira, a ticket can be part of multiple sprints (if it doesn't get finished in a sprint it moves to the next). Importing this leads to multiple values concatenated with ; in the Sprint column. So if we are going to import your sprints dynamically into the sheets for individual sprints, how would we reference the specific sprint, when there are multiple? The same is also true for Components. At Educatly, there are 4 components. You might have less or more. Sprints, however, can have indefinite. Let's dig into it.
This blog post was published on my Medium Publication. Click here to read the full post.