Have you done a project without keeping track of the tasks? Trusting your memory or your notepad notes? Those asd.txt and temp1.txt files? Well, well, well… not good my friend, not good. I completely believe when you say that you have a great memory or that you remember every line of code you have written, but, do you know what other teammates do? And what happens if you leave the project to join a new one? For these and other many many reasons is that we need to use tracking tools. Today, I’ll talk about the one that I have used the most: Jira
So first of all, Jira or any task tracker for that matter, it’s a good thing, if it’s your first time using it don’t panic! It doesn’t mean that you’re now going to be micromanaged or anything like that. In this first post, I’d like to give you a brief overview of what Jira is about and how it can make our work lives easier with simple configurations. Jira allows you to create and keep track of all the tasks that any project requires, it doesn’t matter if it’s a new development, maintenance, customer service, etc., you’ll be able to keep track of every tasks from the smallest one to the bigger components, it all depends on how you use it. It also gives us the ability to go back and verify what has been done, what’s missing and what’re we doing right now… Imagine you need to improve a functionality that was completed weeks or months ago and the person who did it is no longer at the company, well, you can easily look for the ticket in Jira and see what was built, how and why.. You won’t have to be looking at thousands on files trying to determine where to look at. It also allows you to create all type of reports, from the more detailed ones to those control freaks out there to the high level ones.
I’d like to call Jira like the source of the truth for every project, meaning that if there’s not a task created, then the work was not done yet or won’t be done, basically because it doesn’t exist, like the tree that falls in the forest.
To be completely honest with you, I have gone through not great experiences using Jira in the past, terrifying actually… however, it was not because of the tool, it was us… Jira can be configured as simple or as complicated as you want it to be. So yeah, I have had pretty bad experiences with it due overcomplicated workflows or thousands and thousands of (required) fields to fill per task, most of them unnecessary. But with experience and better knowledge of the tool, it could be very beneficial and it could have a great impact on your day by day work. So, if you had bad experiences with it before, you know, hate the player but don’t hate the game.
As you can imagine, Jira is a long long topic so for now I’m going to focus on three key points: Summary, Assignee and Status, I truly believe that if you keep these three points well defined and up to date you’ll see immediate tangible improvements in your processes. Let’s start with the first one: Summary
Summary
What needs to be done? As simple as that. I personally like to use a format like: Implement this, Implement that, Update this, Update that but I have seen other people adding summaries like: Sign in module, is that wrong? Not at all, however, I like to do it this way so whoever reads the ticket would quickly understand that ‘something’ needs to be added, deleted or fixed. No matter how you decide to create your sentences for the Summary, I strongly suggest to keep consistency on your narrative so your teammates don’t get confused by receiving mixed messages.
The summary is also very important because you can search for past tickets by it, therefore, please do not name your tickets with random generic terms like: Clean up data base or Delete tables, believe me there will be a time when you’ll need to know why or when did you delete such tables and you’ll find yourself searching for old Jira tickets with the word ‘delete’ in the summary and it may be a nightmare to determine which one is the one you’re looking for.
When you type your Summary, keep in mind that it’s not just for you, it’s for everyone in the team therefore, it should be clear and it should give a good idea of what needs to be done, more experienced team members will be even able to determine how long it’ll take them to complete a task just by looking at the Summary.
Assignee
Who owns the ticket? Basically, it let us know who is responsible for the ticket at any given time, this is tied to our next point which is the Status. The assignee should be able to let us know what’s going on with any ticket assigned to him, it could be that nothing is happening because work hasn’t started yet, completely valid. Why is the assignee an important field? Many reasons, one of them is to be able to determine if you’re overloading one teammate with a lot of work or if the opposite, there are teammates with no work assigned, both are equally bad. A ticket can only have one assignee at a time, this is something that could be debatable, I have being in scenarios where a ticket is being worked by two persons at a time and I truly believed then that it didn’t make sense to split the ticket into two… am I wrong? Probably. The truth is that this has happened to me once or twice, 99.99% of the time having just one assignee per ticket makes complete sense.
Status
What’s the current state of the task? I don’t want to overcomplicate this point, so I won’t get into workflows and things like that. Let’s keep it simple and not tied to any methodology. I’ll list three status: Open -> In Progress -> Done. Open defines a tasks that needs to be done, it’s sitting there waiting to be picked out and completed. Why is this status important? Well, it’ll let you know which tasks are not being worked on, it’ll allow you to create a report of the work that is missing and plan it for the future. What can go wrong if a task is in the status Open but it’s actually work that was already done? Hmmm a lot of bad things could happen… first, you’ll report less work than what was actually done, you could assign this task to someone else and that will end up in double work.
In Progress, self-explanatory, this is work that is currently being done by the Assignee and therefore, it can’t be assigned to a different person. This status will allow you to create a report of what’s the team actively doing at any point in time, one team member can have more than one ticket assigned at any time, but only one or perhaps two could be In Progress at any given time, unless you work with a team of robots, in that case, that number could be higher 😉
Done, the work is completed and we can forget about it and move on with our lives… or to the next ticket. You may think that this is so simple, however, sometimes there’s a gray area where the work is not in progress but it’s not done, what to do in this scenario? Well, you can create an intermediate status, Blocked for example if you’re waiting for something else to be completed or you can send it back to Open… In any case, always remember that done is done, not partially done or almost done.
There’s still A LOT to cover guys, but for now, I think this would give you an idea of what’s Jira, why a lot of us use it every single day and can’t live without it… even when they keep changing the look and feel every other day which drives us crazy!
