Product review - JIRA and how to set it up for success

Welcome everyone to the Product Bakery, the podcast about everything related to products. I'm here today with Christian, he's the product manager of our group. Hi, Christian. Hey, Alex, how's it going? And for the ones who don't know me, I am the product designer of this group. And yeah, I mean, today, we're sitting here again, we just had dinner. And therefore, yeah, just another session or brain dump just from the two of us. Exactly. And before we jump to the conversation, just the usual information, you can find all the episodes on our website. If you go to product-bakery.com slash episodes, you find it with some episode minutes so that you know what we discussed and where to jump in if there's something that you're interested in. You have the possibility to leave some comments and interact directly with our speakers or with Christian and myself directly. And besides that, you can also find us on all the social media channels for some additional materials. Did I forget something, Christian? Yeah, you forgot to mention that these episodes can also be shared with your friends and colleagues. They should be shared. They should. I knew I missed something. Cool. So Christian, I mean, we started with the last episodes to do some lightweight product reviews. And I think like since the very first day where I was thinking of product reviews, there was one product that I always wanted to review with you. And it's a product that I know, like, you know, you use it a lot. I know that you use that product a lot. You are, to some extent, I would almost say advocate of the product. You like it. I see your hat nodding. He already knows what are we going to talk about. But I think at the same time, it's also a product that is, I wouldn't say hate it, but not everyone loves it. I think it's a very discussed product that still everyone uses. And I mean, for the ones who don't know, what are we going to talk about? Do you want to say the name? Is it WhatsApp or Facebook? It's not WhatsApp or Facebook. It's more relevant for product people. Is it Jira? Is that how you spell it? So I actually figured out it's not Jira. It's called Jira because it has some Asian roots as far as I understood. Okay. Is this an information that we can like, are we sure about this before we put it out in the world? If I'm wrong, then I'm happy to get feedback on how to correctly say it. Yeah, you can write him directly. It's christian at product-bakery.com. No. Okay. But yeah, we want to talk about Jira. Do you love or do you hate it? Yeah. So, I mean, since you are the designer of the group, I would say they definitely don't win a UI and UX award, but I have to say it can be a very powerful tool. Well, I have to disagree. And I know I told you this already. I think in the last years, they improved a lot. And I mean, you have to admit, right, they're an engineering driven, founded whatever company. Design was never like really their top priority, I would say. But I think especially with their last head of design, I think he's now working for Dropbox, was just recently checking his profile. They actually really improved. And it's like when all this next gen kind of came out and we can talk about next gen. I'm not sure, like from a pro perspective, that's the right thing. But I think that one was like where I was like, okay, from a user experience perspective, they managed to reduce a lot of the complexity, it became lightweight, it became easier to use, easier to understand. I would say yes and no. So it depends a little bit. You covered already the part of the complexity that has been reduced, which I agree with. It's definitely simpler to use. But if you are a power user, the user experience is harder to understand because there are many things that you can eventually not find anymore that are not there at all. So, yeah, it's a little bit of hate and love. But for this conversation, I think I would like to dive a little bit into this whole topic of the way you can use Jira, because we talked about backlog management in the past, and I think it's a good idea to actually catch up on the previous conversation we've had, because it is important to master your tools in the first place. And I think in 2019, we visited the product management festival together and there was a survey made to figure out what kind of tools people use. And back then, the survey was saying that almost 70 percent of all product people use Jira. We can definitely say it's a business standard or an industry standard that has been established over the years. So that's the first thing I would say. And when it comes to Jira itself, so before we talk about the UI and the UX, I think it's first of all important to understand what you can do with Jira and what you should not do. So I just pulled up the Jira website, I think that should become our theme. And as you say, industry standard, they themselves promoted as the number one software development tool used by agile teams. I hear already people saying that no, Jira is not agile and project management tools are going the agile thinking and stuff like that. So yeah, let's not go into that. But yeah, first things first. So it's as you said, right, it's definitely used by a lot of teams. And I believe it's not only about the tool, but the tool can definitely help you to make agile practices easier. So how would you use it, especially like around like all the different functionalities that come with Jira? Yeah, I think the very first thing is you need to ask yourself, what do you want to get out of it? And since we are working mainly in agile environments these days, you do either Scrum or you do either Kanban. So one of those, and based on that, you should choose a project in Jira that supports your Scrum or Kanban framework. So that's the first thing. And what I see many times is that people making not full use of Jira, they have maybe a board and this board has like this three columns or they create maybe a couple of more and then end up in a way that tickets getting lost or it's hard to understand how they are moving through the workflow and things like that, which is a little bit sad because due to the bad UI and the bad UX for Jira Classic, it's also hard to set up all those things. So what is my workflow? How do I use it? So you almost need to study that in order to be able to create a board that suits your needs. But like just out of curiosity, right? I obviously have like a view on it, but if you say bad UI and bad UX, what's bad about the UX and the UI? So let's say you and I, we are working with an engineering team and we want to do Scrum and we have a certain workflow. So we have tickets that are first of all open. Then we have a preparation phase where we do our discovery and also sit down with the teams and refine the tickets. And once everything is clarified, we pull it to ready for development. And from that point on, we're going to develop the feature. It's in progress. Right after that, we have a review state. Then we're going to have a QA state. Then we merge it to master. Then we merge it to staging and then we merge it to production. It's maybe one of the most common workflows. I'm not saying that everyone does it, but this is a very realistic scenario. So how do you set this up in Jira? It's a pain in the ass. So you need to create a new board. This board has a standard workflow. So then you need to go into the deepest Jira settings to create a new workflow. You have to add all those statuses that I just described. Then you have to define transition states. Can you go from in preparation to done? Can you go from in preparation to ready for development? Yes or no. So first of all, questions you need to answer for yourself, and then you need to configure it in that fucking backend. Then you go back to your board, into your board settings. You're going to choose this workflow. And then you have identified that there needs something to be changed in the workflow, but what you then need to do is you need to create a new workflow because you cannot change an existing one. So I don't want to continue because you see already it's a pain in the ass. Yeah, you're getting angry. I didn't, I didn't want to get to that, but, but I think it's, it's, it's obviously like good to, to, I mean, if we discuss or if we have like feedback on a specific tool to like touch on the details and this is actually something, and I'm fully with you, right? The complexity of setting up such a project is massive. And, and this was something where obviously when I was using Next Gen a lot, it was like very early stage and beta and so on. But the thing was like, they really worked on trying to fix this. And I think you obviously have a lot of legacy. As I said, I mean, I think it's, it's just like, it was a company that was mainly driven by engineers and I don't think there was a lot of, maybe there was, I don't know, but it doesn't look like there was a lot of feedback and that's like, I mean, we've seen it as well, like in, in other companies where you start like having this feature mindset and then the question is where do we place it? And then it ends up in settings and then it's kind of there and it grows in complexity and blah, blah, blah. And then it just sucks. But. The reason why I mentioned this particular example is the success of a project, especially when you are multiple teams, that rises or falls with the configuration of Jira. So with Next Gen, you can obviously skip a couple of those steps that I've just explained, but with that, you will also lose certain information that might be relevant for you because Jira Classic provides you with much more details regarding your velocity, regarding your ticket throughput, et cetera, that Next Gen is not very good on reporting at as much as Classic is. So that's why I think, yeah, I would love to have it a little bit more easier to use in Classic terms. But my assumption here is that like seeing the way they started with Next Gen and how they're developing it, and then we can skip, I know you want to talk about other stuff and not Next Gen. But I like from looking at the development, I definitely think that they're using it like as the starting point and a little bit the playground and they take in a lot of like the prioritization from feedback that they get from people. And I think you will see more and more of these, let's say, more sophisticated solutions on the Next Gen boards allowing you to track these things, but at the same time, like making it easier to use. And hopefully then at one point the Classic version dies and we have the full power in a better interface. And I fully agree. And I would say they are definitely doing a good job in making Jira Next Gen as usable as possible. I would assume they are focusing on the main needs that companies have, like being able to quickly create a board, defining the certain stages and the certain steps in the workflow, and then being able to get started. And this is exactly the reason why I wanted to talk about this topic today with you, Alex. I think it's very important to understand that having a basic workflow is nice, but you should not underestimate the power of going deeper and setting up Jira in a way that you get as much data out of it as possible. And I'm not talking about data in terms of tracking how much time an engineer spent working on a ticket. That's not what I'm talking about. What I'm talking about is understanding how Jira works. For example, being able to add fixed versions to tickets that are related to a feature that are eventually linked to an Epic and then create version reports out of it. So you're going to create burn up charts that calculate your velocity or your ticket throughput and can give you an estimated time of arrivals on ETA when the ticket will be finished or the whole feature, and that's something that many people are not aware of that you can do such things with Jira. There is also the Jira dashboard function where you can create filters, which is also a pain in the ass by the way, and then create certain charts like pie charts or how many tickets are lying in different teams to get an overview of the ticket and the project status. And that's something that I would like to emphasize on to not underestimate the power of a well-maintained backlog and adding enough information to those tickets with the underlying infrastructure. And what do you say, who should be the person responsible or maintaining Jira to really get the benefits out of it that you just mentioned? That's the billion dollar question, Alex. It's hard to answer. Is it design? I know that there are companies who are hiring Jira admins who are doing that. But back then when I was Jira admin, when we worked together, there was no one else who was doing it. I also had admin rights. But having admin rights and being an admin are two different things. But yeah, I mean, whenever you feel comfortable in doing it, I would say just do it, so I just went through the pain of going through the Jira documentation and teaching myself how this whole product works and then just getting started with it. Adding to the $1 million question, I think probably the $2 million question. Or at least something that I've seen. And I think especially when it comes to setting it up the right way, I think different teams, different people also have different requirements. And I think this is also a conversation that I've seen in so many companies. Do I work with one project? Do I work with multiple projects? Because at the end, the settings are kind of on a project level and then I would just filter differently, the admin speaking. But yeah, I mean, how do you work with different requirements? Because I would assume with also having multiple product managers, they would just set it up differently, right? And right now I'm seeing this with a couple of clients I'm working with, that there are these different requirements that you just mentioned. So there are actually two types. So especially in environments where you have many teams working on one product, so cross-functional collaboration and cross-functional development, there's either the scenario of people just using NextGen and trying to squeeze everything into it, so having multiple boards. But then you have, for example, at least back then, the problem that you can only start one sprint for all the teams. And some people are simply not working synchronized and they necessarily don't want to have one big backlog where everything is inside. And the problem is also with one big sprint, it's hard to measure velocity of each team, so it doesn't make sense necessarily if you are working in such an environment. So therefore you can decide to either have multiple projects, which makes it on the other hand, harder to link the tickets between those projects, because in every project you have your own workflow, your own ticket types, your own project ID, which is linked to the ticket. So which makes it more complex. And then there is another solution that I like doing is having one project that is set up well with a generic workflow that hopefully suits to your different team's needs, which means you also need to talk to them and align on something, and then having different boards where you can filter on for each team and start your individual sprints. Yeah, I've seen that a lot with the filtering. I have to say, I'm also coming a little bit from a different perspective where I'm still trying to find the best way also to get like the design workflow integrated in the normal work, because that's another thing, right? A lot of teams, then design teams have their own projects and boards, which, yes, makes sense. I think it makes sense because the workflow can be so different. At the same time, one thing that I now want to try more is to have that workflow simply mapped on a traditional workflow for the software development team and then just have this one additional step that on a design board can give you the whole complexity and still like pull all the different tickets from all the different projects. But at the same time, at the project level or for the developers and for the sprint specifically, only be like in-design kind of task, because additionally you get to benefit from having designers also think much more in the sprints, not like, oh, yeah, I have my ticket and it's moving on my board for like three fucking months of like, oh, cool, we're in discovery. And I think it's important to also like have this mindset of breaking things down, having it in small pieces. But yeah, I think that's a completely different topic and I can share more once I successfully managed to integrate this with my current company. It's definitely one of my to-dos. But just to brainstorm here, you can establish the ticket workflow in the usual software development workflow at a label and create a filter and a board for the label with all the tickets your design team is working on. And that was exactly what I was thinking. The only pain here is that if we have different workflows or different projects, we would have to add this to every single. No, no, you don't. You can just map the workflows to the columns because in general they are almost the same, right? So if it's called work in progress or in development, you can just match both of the statuses to one column and then you would still. I would pretty much add like five different statuses that would then map to either in preparation or in design, depending on whatever the team prefers. Cool. But back to like really hardcore and zero usage, like do you have one tip that you would give everyone? Yeah, I have millions, but I would say the number one tip is, especially as a product and engineering team, sit down and think about how your workflow should look like. And once you have discussed that and decided on something, whether you are one team or many teams, I mean, the more teams you are, the more important it is to align on those. Then sit down and try to translate it into a Jira workflow and start working with it. And then I have an additional one for the Jira team, actually. So I like using Jira still and still using it even as a independent coach. So I would love to see more of the classic reporting functionalities in next gen to be able to use it as well as the ability to work with different sprints in one project. Fair enough. I think that's a nice wishlist. We can make sure to send it over to Jira and maybe they want to listen to this episode. And the ETA is yesterday. I was so happy I'm not working with you anymore. All right. With that said. Thanks, Alex. Thanks, Christian. Everyone have a beautiful day.