Effective setting and management of tasks in IT projects
In this article, I will share the results of my research and practical recommendations for improving the process of setting and managing goals, which we now apply in our work.
Templates and examples of tasks will be at the end of the article.
Description of tasks
Purpose of description
Provide maximum context with minimum complexity. The simpler the task description, the more profitable it is to do so. The clearer the description, the lower the chance of making mistakes due to misunderstanding or spending a lot of time on analysis.
How to make task descriptions easier and more understandable to fill out and study? – Design templates.
Task types
I took examples of descriptions from agile methodologies as a basis and divided them into types:
Epic (Big task)
Feature (New functionality)
Bug (Bug fix)
Enhancement
Refactoring
Technical Debt
Research
Docs (Documentation)
But simple separation is not enough: each of the standard templates needs to be given a specific description.
For example, you won't describe “Expected behavior” and “Actual behavior” in “Feature” because it probably belongs to the “Bug” type. At the same time, “Feature” has its own points that will help to describe much better what and why the performer needs to do.
Description templates
So, these empty templates need to be enriched with descriptive points. They should be specific to this type and encourage the task initiator to convey the full context. In addition, this will help the task creator think about additional questions that did not initially arise.
At the same time, simply adding items may not be enough. For example, the item “Environment” may be understood differently by everyone, but the team needs precise details: application version, OS version, browser, etc.
Therefore, it would be great to additionally add a comment describing each item of the task (1-2 sentences should be enough).
The commented templates I use will be at the end of the article.
Of course, these are not dogmas. It is not necessary to use all types or the same description structure as written in the templates.
Main thought: Provide a simple tool that tells the person how to convey enough context depending on the type of change. It's up to you and your team to decide what works best.
Why bother?
Put yourself in the initiator's shoes:
I know what needs to be done and why.
I know how it should work (from a business perspective).
I know the priority and dependencies of this task (with other tasks or teams). Of course, in reality, the initiator will not necessarily know all the points, but I want you to get it the main idea: only the initiator at the start can pass the maximum available context to the executor and be responsible for it.
Now let's look at it from the performer's point of view when he receives an empty ticket:
I see the title, but what exactly needs to be done?
How will this affect the performance of the product/feature, etc.?
What is the urgency and priority?
Who should I contact with questions? And what is the result? And as a result, the performer is forced to go and shake the initiator.
Why waste time on this? Wouldn't it be better for the performer to only ask questions on specific points in the task that remain unclear to him? This will waste much less time, nerves and “thought fuel”.
But there are situations that are even more frightening: even after clarifying the context of the task with the initiator (1t of time spent), the two of you no longer supplement the task with a description, because both of you “It's already clear”. And then it happens:
You got distracted by another big task, went on vacation, or got sick and lost context.
You transfer the task to another performer (QA for verification or delegate to a colleague) and again forced to convey the full context. As a result, you spend 2t time. If this chain continues (Nt grows), then even a small task can take a lot of time and effort.
Key points when describing tasks
The task initiator should provide as much context as possible.
Use templates with comments to simplify the description process.
Include all relevant information: objectives, expected results, acceptance criteria, requirements, constraints.
Be explicit about task dependencies and relationships.
Record any questions that arise along with the answers.
Add labels, priorities, and due dates to make it easier to find and prioritize tasks.
Task management
Okay, let's say we've solved the “empty tickets” problem. The next problem will be “staling” tasks.
The Importance of Updating
It is imperative to supplement the task as it is being completed and maintain its relevance. Treat this as one of the important and continuous processes.
For example, how will your QA (or even you after vacation) know that:
The requirements have changed.
Something else came up during the process that requires attention.
New dependencies with other tasks or commands have appeared. No way, except for a random insight “oh, I need to tell”. Otherwise, most often, the task will not be completed in full.
Key aspects of task management
Update the description regularly: changes in requirements, new dependencies, and so on point by point.
Please comment on any significant changes and why they were made.
Describe additional conditions, such as how to test the changes made (enable feature flags or ab tests).
Advantages of the approach
Saving time and team resources: Less effort to clarify requirements and context, reducing the need for unnecessary clarifications and approvals.
Improved task planning and estimation: Which contributes to better planning of sprints and projects.
Convenience of working with deferred tasks: You can quickly return without a long “immersion”.
Potential risks and problems
It is important not to overload the description with unnecessary details, but to highlight the main points.
A detailed description takes time, especially at the start.
This pays off in fewer errors and misunderstandings during implementation, as well as reduced time for retransmitting context.
Resistance to the “I'm too lazy” or “I don't have time” command:
Find out the reasons for the reluctance to follow the process. Perhaps the process is not entirely convenient for you or the team is currently a “sweatshop”. These issues should be worked through and the process should be adapted to the needs of the team (or discarded and looked for something else to do).
In extreme cases, if there is no clear answer and reasons for not accepting the process, and the resistance is more likely to be associated with an individual employee (while the rest of the team is fine with it) – think about the employee's inconsistency with the team's requirements. I'm serious. It is worth getting rid of the anchor, otherwise, with the unwillingness to “waste his time”, he will waste the entire team's time many times over.
Conclusion
In conclusion, I would like to emphasize that effective task setting and management is not just a formality, but one of the key factors for the success of IT projects. By applying the proposed recommendations, we were able to reduce the time for clarifying requirements by 30% and reduce the number of task returns for revision by almost half.
I hope that following the suggested recommendations will allow you to increase the efficiency of setting and executing tasks. This will lead to time savings, increased predictability of development, and improved quality of results.
I would be glad to hear your experience and opinion in the comments. What problems with setting tasks have you encountered in your practice? What methods have proven most effective for you?
Task templates with comments I moved it to Notion for convenience.
Thank you for reading to the end. This is my first article and I will be glad if it is useful to you.
P.S. If you are interested in learning more about development, product management and building processes in a team, I invite you to subscribe to my Telegram channel maxxborer.t.mewhere I share additional materials in short post format.
