Introduction
Order execution is usually related to the creation or repair of something. In most cases, one person invents something; the second one realizes it. The thing that links these two people - the designer with the contractor - is the TASK. This subject is important because all of us (bosses, managers, low-level workers, programmers, physical workers, etc.) have to know what needs to be done to achieve the goal - we have to KNOW, not GUESS.
Task definition can be any document that helps others understand WHAT and HOW should be done to realize a new feature or fix an existing one. This article describes how tasks can be defined to make them ready for estimation in terms of time (and costs of course) and realization, bearing a very low risk that the deadline isn't met.
What are the advantages of a well-defined task?
Delay risk minimization
The better requirements are defined, the smaller mistakes that happen during time estimations. If we want to promise someone that a task will be completed before the deadline, we have to know how much time we need for its realization (otherwise, we can't be considered as experts - sorry). Of course, we might be lucky and estimate the time properly, but it's too risky to be serious.
Expected result
The ordering party is sure that the result will be as they wish - the contractor doesn't have to guess what they want (conjectures are usually a source of misunderstandings).
Don't waste time on conjecture
We should know what the purpose is and what should be done to achieve it. If you decided to start working on the task, you shouldn't have additional questions about this task that could become significant blockers. The next thing is problem reporting ASAP - you HAVE TO alarm the supervisor that you encountered a problem during the work on the task - they need to know that and should help you. Next, if you're not able to estimate a task, feel free to create additional "investigation tasks." Such tasks come in handy for preparing the necessary knowledge for realizing a given task - it's a manifesto of professionalism, it isn't a triumph of form over content because you say that you see a problem out loud.
You know who is responsible
The contractor should be known so that you can contact them during task execution or afterward to provide feedback (both positive and negative), or just to ask about something.
Concentration on the task at hand
Well-defined tasks don't require any additional work, questions, and time spent waiting for the answers - all of these things are distractors, making tasks more time-consuming and less attractive. We often start working on the next task while we're waiting for an answer regarding the first one. This isn't a good solution because when we get the answer, we need to get back to the previous task, recall what we did there and where we are now - and only then go forward. The same happens when we get back after some time to a task that we've already started.
Components of a ready task
What to do?
We have to specify the goal. Otherwise, the contractor doesn't know if the task is done or not - the expected effect has to be known.
How to do it?
A well-defined task needs to contain as much information as is required to deliver the result. It's ideal when we know what knowledge the contractor has and don't need to describe everything with unnecessary details (I know myself best) - it obscures the content. On the other hand, we can suppose that the programmer doesn't know enough about logistics in a transport company - the task creator should provide all the required details to enable the contractor to implement business logic. In the end, we have to remember that outside special cases, "How to do it?" should contain a business description rather than a technical one.
How to test?
It's very good practice to add a short description of how to test the task and the acceptance criteria - it's mainly for testers or business guys.
Who is responsible?
If we decided that we'd realize our task in time slices, we should always assign a person who will be responsible for that task. It's mainly useful for that person - thanks to this, they can schedule the tasks in better order and finish them on time.
Where is the help?
It may happen that despite a good definition of the task, the contractor will need to contact a person who knows more about this task - the creator, someone who knows the domain, or teammates with more experience - to resolve problems or suggest something. It's good to know who could (probably) help us. This is a particularly important point for new team members.
Task size
"Isn't the task too big?"
"Maybe we should split this…"
"I think that this task is too small…"
"We can realize these 2 features as part of this task - don't waste time creating another one…"
Divide and conquer
The task size is one of the most common problems during the process of defining it. We wonder about how large it should be, how many features we can describe, etc. There is no good answer to this question (maybe one: "It depends" - but we hate this answer). However, we can try to answer this question: "Can we extract an independent part of this task?". If yes, then JUST DO IT! Of course, if tasks depend on each other, we have to organize them in an appropriate order to be able to process them as separate tasks.
One of the best approaches to creating tasks is to start from the end (goal). Let's imagine that we have to create an IT system for a transportation company… The goal is to build the whole system but we can easily indicate its components: GUI, databases, services, hardware infrastructure, etc. We can treat each of these components as separate parts of the system and divide them again and again. In the end, we should have tasks which are small enough to be doable at a finite amount of time by an executive unit (person, team, company). It's just an example - we have to remember that task complexity is different for people: "an IT system of the transport company" can be an indivisible task for the management of the transport company but it's a big project for the contractors which will (probably) be divided into hundreds (or thousands) tasks.
Where's effective delivery here?!
We have only described how to define tasks so far, while the main subject of this article is an effective feature delivery. That's right, but as you remember, I said that the task is what we find between client and contractor. So, no well-defined task = no effective delivery. Every client wants their order to be completed in the right way - this is what they pay for! To make that happen, clients need to know what they want and contractors need to know what needs to be done. If there is no understanding here, there's a good chance that tasks won't be done properly - something may seem obvious to one person, but it might not be that obvious to someone else. I think it's clear that a poorly-defined task is a fault that lies on both sides:
- the ordering party should define the specification clearly and in detail
- the contractor should inquire about unknowns/details.
I hope that you know now why such a big part of this article is about task definition.
Of course, we can deliver tasks without a good definition, but it's risky. The system can work properly but doesn't care about corner or random cases. Let's go back to the system for a transportation company… the system works, there are no issues, but it doesn't care about traffic jams or road accidents - in this situation, we cannot trust a system which, for instance, prepares the customer service timetable.
Additionally, we should remember that many projects are huge and time-consuming. Such projects can't be prepared at once in detail, and that's why the tasks shouldn't be prepared well in advance. You may have to redefine a task later on, and there will be time for all this.
Conclusion
It would be enough to write: "Define tasks so that the contractor doesn't have to ask you any additional questions!" - THE END. If you order something, you have to believe that the contractor can use tools to reach the goal but doesn't need to know your domain very well. The contractor is a professional in their domain - and you are in yours! So, if you want to get a well-done product, provide well-defined tasks and be ready to assist the contractor - then both you and the contractor will be pleased with the results. On the other hand, if you're a contractor, it's also worth knowing what tasks should look like. Why? Because YOU will be working on them, and YOU will be accounted for them.
PS. Everybody knows that task definition is the hard part of the job, but remember...
NO PAIN, NO GAIN!