A well-written task is a cornerstone of every project. The result of a software development process can depend on the tiniest nuances in a single sentence.

To enhance our tasking skills, our Project Manager Olesya has recently shared many important insights. Now we share them with you!

Simply put, a task is a piece of work to be done. A set of tasks is what constitutes a project. But there is more to it than that.

Olesya said that tasks are also the language of our communication. You can miss a meeting. You can work remotely and be unable to see the team at all. But tasks are a universal way of communicating. It is through a task that a software developer receives instructions from a manager. When the developer communicates “Done, check it” to QA engineers, it is also through a task. When the QA tester or QA analyst gives feedback, it is in the form of a task, and so on.

So, if tasks are a language, there must be rules. Following them will make mutual understanding easier.

Why you should learn to create tasks

You probably thought, “But tasks are a manager’s prerogative.” Yes, but there are some situations when a developer works with a manager one day, and the next day the latter is gone. And the tasks need to be constructed either way because they track your time. When a client asks about the work at the end of the month, you need something to show. And you can forget the details if you track the same task for a long time.

Therefore, you need to create tasks consistently. You should gather information from different sources: Slack, Skype, other task managers, and channels the client uses to communicate. You might use a project task list template for your convenience. Then you confirm the tasks and begin working.

Anti-pattern tasks

Together with the PM, we examined common mistakes in tasking. If you want to know how to design a website more efficiently through better-constructed tasks, read on!

A task without details. A coherent description is key. If a task leaves you with many questions, that is not a well-thought-out task. Sometimes, you can make the mistake of creating such tasks “for yourself,” hoping you will keep the details in your head. But they can fade away easily, especially if the task is prolonged or postponed. Moreover, if you pass the task on to somebody else due to certain circumstances, they won’t make sense of it.

Huge description. The other side of the medal is when there is too much information. Such tasks make your attention scattered. But there are situations when lengthy tasks are unavoidable: too many details need to be included. In this case, you should highlight the key points. Or use check-lists instead of a comma-separated text. It will help ensure that nothing will be missed.

Imprecise description. Make sure to include all the necessary details. For example, where should the new section be located, what design and mandatory components to create, etc. Also, all the information should be readily accessible. If you include links, they must be working and lead to something specific. If you are referencing a document, add a page number. As for designs, it’s often better to include screenshots.

Ambiguous language. Any imprecisions should be avoided at all costs. You may write a perfect task with all the details and best formatting, but a single typo will ruin everything. If a task can be perceived in two different ways, what does a web developer do? They will most definitely understand it wrong—Murphy’s law at its best.

Incomprehensible task. If you communicate with the client directly and receive unclear instructions, always ask until you understand. Don’t be afraid of the client’s dissatisfaction with the questions. It’s more important to make them happy with the results.  Ask as soon as you receive the task. The longer you wait, the more troubles and conflict it will cause. However, if you are a new manager, and some tasks are unclear to you, it’s best to go to the team first. If nobody seems to understand it too, then it’s time to ask the client. This way, you will save both your own and your company’s reputation.

Ready solution. When a client gives you a specific task (for example, to change color to blue), you should double-check if this solution is really satisfactory. Ask questions: will it really help? Can it cause contrast issues? Maybe color is not the problem, and it’s better to change the font instead? Talk to the client about the reason why they gave you this exact task. Ready solutions are not always the best.

No acceptance criteria. All tasks should have metrics. If you are asked to “improve performance,” you need to know how much, compared to what, etc. Relying exclusively on bug tracking software won’t be enough if the task is vague.

Ideal tasks

We all admit: ideal tasks in software development are pretty rare. At the beginning of the project, you are more likely to write it out carefully and in detail. But when it’s near release or bug-fixing stage, you need to react quickly and often lack time to elaborate.

However, we should strive towards the ideal at all times. Our PM suggested that we apply the Golden Circle concept to tasking. It was developed by Simon Sinek, who said that “Why? How? What?” are the three central questions any business should answer. A well-constructed task should include at least answers to “Why?” and “What?” – the problem we solve and the result we expect. You can include “How?” if the task is for you. But if you give it to somebody, try to leave the “How?” out. The person in charge should have room for maneuver.

Consider these eight points when writing an ideal task:

1.       Problem. Include only related info about the issue you solve.
2.       Goal. Don’t forget to define what this task is for.
3.       Acceptance criteria. It can be as simple as a design reference to check if it matches with the result.
4.       Deadline. Estimate.
5.       Chain of tasks. Divide the project into tasks, then decide on their order and prioritize.
6.       Size matters. If the task is week-long, it’s hard to stay motivated. Try splitting it into smaller tasks.
7.       Bug tracking system. Always note all your tasks, don’t let the information disseminate on different channels. You will be thankful for it later.
8.       Attachments. Even if the task looks small and easy, add a screenshot or other illustration. You can forget what you meant, and the picture will come in handy.

So how to estimate if the task is ideal? If the doer never asked a question.

We wish you the perfect tasks and the best results. Did you like the insights from our PM as much as us? Comment and Share!