JIRA Tutorial for NGOs. How to write tasks?
We don’t get any financial benefits from creating Jira tutorials. We only offer this program as one of the best project management tools. Nonprofit organizations can apply for Jira for free.
In this part of our series of tutorials for non-profits, we want to look at one of the most important parts of using JIRA – how to write tasks and tickets for your coworkers. Project management software can only take us so far. Create the environment, when everyone can see what tasks what they have to do. Make communication easier. See how much time I have for this particular job or even the whole project. But all the data that is inserted to the Jira is created by the users. So it is incredibly important to make sure that what we are creating is understandable by others.
Even the best system can fail, if people who are using it, are doing it in the wrong way. So here are a couple of simple rules, when you are creating tickets for your team. We want to focus this lesson on the nontechnical users of Jira. Especially on NGOs who want their job of making the world a better place, a little bit more effective.
If you want to know how to write tasks, this will be one of the most important parts. Everyone that is working on the project with you, have to know immediately what they have to do, just by looking at the title. So it has to be:
- To the point and concise
- Short, without any bigger details (save them for the description)
- With a clear declaration of what has to be done
Why titles are so important? Because it is what users see when they are looking at the board. So this is what they are going to see the most from the tasks that were put upon them. You don’t have to be too descriptive in them, but make them clear. This way you can avoid so many communication errors about what has to be done. When you are starting your adventure with JIRA, remember to ask your colleagues if they understand your ticket correctly. This way, you will learn fast what is working, and how you should your words in the title.
How good title looks like?
“Write the article for the blog about Blockchain for e-health”
Works as a title, because:
- There is a clear indication of what has to be done (“write”) and deliver (“blog post”)
- The topic is precise, so the user knows it from the start (“Blockchain for e-health”)
- There aren’t too many words, so there is no place for misconceptions
On the other hand, the same tasks could look like this:
“We need to post something about health and new technologies. Could you do that?”
This, of course, is the terrible title because:
- Coworker can’t be sure what he has to do (post can mean social media posts, blog post, even internal newsletter)
- The topic isn’t precise. There are so many technologies for healthcare, so a person who got these tasks can waste a lot of time. Search for many various things, instead of a specific one, can be a waste
- The topic is too long with sentences that aren’t bringing anything to the tasks. “Could you do that” maybe is polite. However, it also wastes time.
Description – time for details
This is a place, where you can use details about the task. But remember – you still have to use your words as effectively as you can. What does this mean? Long descriptions with a lot of paragraphs will make your coworkers confused and even bored. Go straight to the point and limit yourself. Attention span is falling with each year, so remember this, when you are writing your description of the tasks. Short sentences and bullet points should be your best friends. Of course, if there are the very important details, that has to be a part of this task, include them. But think how you can communicate them in one or two sentences maximum.
If your description is getting too long, maybe it would be a good idea to divide these tasks into smaller ones? Many details can be lost during long paragraphs, but when you have a ticket with a description in 2-3 sentences, you can be sure, there is no much space for miscommunication. At the start of using Jira, always remember to ask if all of the people in the team are on the same page. Different people can understand the same paragraph completely different. Knowing how to write tasks also means improving your communication inside the team.
Going back to our example from the last paragraph, let’s see some example descriptions:
“Write 300-400 words article for the blog about the Blockchain for e-health.
- Target audience: young people interested in new technologies
- Language: simple, without technical details
- Use 2-3 pictures from the free stock photo website (for example: https://unsplash.com)
- Remember about good catchy title and SEO rules
When maybe not the best, this description should give all the needed details for the coworker to start working on the task. He knows how long text he has to write, who is his audience, what type of language he should use. Thanks to using the bullet point, all of the details are clear and separate from each other. Giving the source to the site with pictures could potentially save him a lot of time. Certainly, not everyone has the same knowledge as you. It sometimes better to write about basics – but shortly. Also, a quick reminder at the end will make your coworker especially careful at the details that are most important for you.
And a bad one…
How could this description also look? For instance, like this:
“I need a long story about how this new blocks, linked by cryptography can be used in the healthcare systems. It is a decentralized, distributed and public digital ledger that is used to record transactions across many computers so that any involved record cannot be altered retroactively, without the alteration of all subsequent blocks. I think this is a very interesting topic, it can bring the audience we want for our medium. Choose some pictures from the internet (but for free) to illustrate this. I want it to be popular and promote us.”
Everyone can already see, what is wrong with this description. Not only it is too long, but at the same time, it is very vague. Without being precise, the coworker doesn’t know how much he has to write (“long” can mean different things for different people). The topic of the text isn’t clear and use the language that could be potentially not understood by people who have to do this task. Some of the sentences aren’t bringing any new information or even just voice an opinion. This kind of description could potentially make the work on this task at least two times longer. As you can see, knowing how to write tasks, can help your coworkers do better work at their job.
All descriptions should have the list of deliverables. What are they? Things that should be a product of this task. That way, it is easy to measure at the end of this ticket, if it was a success or a failure. We are using the add-on, that is allowing us to do the “to-do” list. When someone is finishing one part of his tasks, he can easily check-in, what he’s done.
This is pretty self-explanatory. When you are creating a large number of tickets for a project, remember to always set the priority level on each of them. This way it is easier for you to decide, what should be done first and what can be done later. This also helps your coworkers. When they are getting a new task, they can quickly see what do to. If they have to put everything else aside for this, or they can finish what they are working on right now.
Of course, in the beginning, the status should be put in the “to-do” column on the board. But it is good to remind the rest of the team to move them to other columns during work. Like “in progress”, “done” or other that you’ve created. Thanks to this you can easily see the progress of the project or even catch out when the tasks that should be a priority are left behind.
Project management software is here for you, to catch out mistakes that could be done, without the transparency they are providing. Use them, as best you can, to make your work more efficient. Knowing how to write tasks, will help you be a better project manager.
If you want to know more about JIRA and how to get if for free for your organization, check the other parts of our tutorials: