Task assignment is half of success. It sounds like a line from a training manual, but after many years of working with development teams I am convinced it is also a very expensive cliché. "Make it look nice" does not work. "Make it like our competitor's" does not work either. "Well, you know what I mean" works worst of all, because at that moment the programmer nods honestly and really does understand. Just something else.
I have seen the same scene many times. A manager writes a one-line task on Friday evening, on Monday the programmer brings the result, the manager looks at it in horror, the programmer looks back offended, and the client looks at a calculator. A week of work went into discovering that everyone was talking about different things. Nobody is guilty here, there is only a badly transmitted thought.
A programmer does not read minds, he compiles them
Imagine you order a sword from a blacksmith and tell him: "I need a good sword." The blacksmith will make a good sword. By his own idea of good. It may turn out to be a heavy two-hander, while you needed a light rapier for fencing in a gym. The blacksmith is not to blame, he made an excellent thing. Just not the right one.
With a programmer it gets even more interesting. Code is a literal thing. A computer cannot "fill in the gaps", it executes exactly what is written. And a programmer translating your task into code has to make dozens of small decisions you never even thought about. What happens if the field is empty? What does a user without permissions see? What if the order is cancelled halfway? Every such spot left without an answer will be filled by the programmer himself, by his logic, not by the logic of your business. These are exactly the cracks where bugs, rework and mutual complaints later live.
So a good task is not the one with many words. A good task is the one that leaves the least room for other people's guesses.
Anatomy of a task that gets done the first time
The draft of this article had a short checklist, and it is still correct. But every item has its own story behind it, so let me unfold it.
Title. It answers the question "what exactly needs to change". Not "Problem with orders", but "Allow the customer to cancel an order before shipment". Half a year later, someone should be able to find the task in the tracker by its title and understand what it is about without opening it. If you cannot read the title out loud at a stand-up without explanations, it is a bad title.
Description and context. Here you write not only "what" but also "why". This is the most underrated item. When a programmer understands which business problem he is solving, he notices half of the edge cases himself and suggests solutions simpler and cheaper than you would have invented. Once a client asked us to build a complex filter with twenty parameters for a report. We asked why. It turned out the accountant searches for three specific payment types once a month. We made three buttons. We saved the client two weeks of development and the accountant her nerves.
Logic. The steps of the scenario through the user's eyes: opened, clicked, saw, received. Plus the forks: what if there is no data, if an error occurs, if the user has another role. You do not need three pages of prose for this, a numbered list is enough.
Acceptance criteria. How will we check that the task is done? This item turns the argument "I feel it's not ready" into a verifiable fact. For example:
- the customer sees the "Cancel" button only on orders with the status "New" or "Confirmed";
- after cancellation the manager gets a notification within a minute;
- a cancelled order does not appear in the sales report but stays in the customer's history.
When acceptance criteria are written down, the programmer can check his own work before handing it over. That is cheaper than any tester.
Mockups and screenshots. If the task has a visual part, one picture replaces a page of text. It does not have to be a Figma design. A screenshot of the current screen with a red arrow and the note "button goes here" already works better than the most detailed verbal description. Back in the day I drew diagrams with a ballpoint pen on a napkin and took a photo. It worked.
The mistakes I see most often
The first one: the nesting doll task. "Build a user account area." Inside there is registration, password recovery, profile, order history, notifications and a couple of other universes. Such a task cannot be estimated, cannot be verified and never ends. If a task cannot be done in one to three days, cut it. Big chunks live in the project plan, while the tracker gets small, finished and verifiable pieces.
The second one: a solution instead of a problem. "Add a date column to the table." Fine, we will. But why? Maybe what you really needed was sorting by date, and the column is not needed at all. Describe the problem you are solving and offer the method as an option, not an order. An experienced programmer often knows a shorter road.
The third one: the task in a messenger. A four-minute voice message, then three clarifications in another chat, then a call where everyone "agreed" but nobody wrote anything down. A week later nobody remembers what was agreed. A task should live in one place, and every clarification should be added to its description. It is boring. It works.
The fourth one: silent acceptance. The programmer delivered, the manager looked, said nothing, and a month later it turned out that "actually, it's wrong". Feedback is needed immediately. Otherwise the mistake has time to grow new code around it like barnacles, and fixing it costs many times more.
A dialogue instead of an order
There is one more thing that instructions rarely mention. Assigning a task is not a one-way action, it is a short dialogue. A good programmer asks questions after reading a task. If there are no questions at all, it is not always a sign of a perfect task. Sometimes it means the person is shy to ask or has already invented everything for you.
I ask my teams to retell the task in their own words in two or three sentences after reading it. It takes a minute and catches more misunderstandings than any regulation. If the retelling matches what was in your head, start. If not, you have just saved a week.
And one more rule: the estimate is given by the person who does the work. A manager can ask, can bargain, can cut the scope. But setting a deadline from above without asking the executor is like scheduling the weather for the weekend. You can do it, nothing will change.
What to do tomorrow
Take the last five tasks you assigned and reread them through the eyes of someone who was not on your calls. Is it clear from the text what to do, why, and how to check the result? If even one of them lacks acceptance criteria, add them. It is the cheapest improvement of a development process that I know.
Make yourself a task template with five fields: title, context, logic, acceptance criteria, mockup. You do not have to fill all of them every time, but an empty field should be a conscious decision, not forgetfulness.
At Ingello Systems we went even further: we do not describe a large part of typical tasks in words at all, we describe the system formally, with data and screen schemas, and the Fractal generator turns that description into code. When the description is precise, there is simply nothing left to argue about "what was meant". But even if code generation is far away for you, a precise task already brings you a third of the way into that world. Code, like a sword, starts with a drawing.
