Six Mistakes
When Defining Tasks in IT Projects

We Anticipate Risks and Offer Simple Solutions.

Software development encompasses more than just programming. Every project starts with defining requirements and creating a technical specification. Skipping this stage can lead to project delays or delivering results that don't meet the customer's expectations.

To understand the most common mistakes in task definition and their consequences, we spoke with Ekaterina Podaruyeva, Head of the QA Department at SimbirSoft. We discussed the importance of documenting all agreements, involving a system analyst in the process, and other steps to avoid potential project issues.

Error 1: Incomplete Task Descriptions in Task Trackers

Companies typically use task trackers like Jira or Kaiten to define tasks, offering various fields for describing what developers, analysts, or other specialists need to do.

One of the key sections in a new task is the "Description." Filling it out is not complicated, but often, the initial task discussion occurs at a higher level, involving the development manager and the system analyst. They jointly decide on the specifics of the task and its format.

When such a task is transferred to a task tracker, the author might overlook providing a detailed description and fill in only the task name, adding a few sentences to other sections. Why does this happen? The author might assume that since the feature's description already exists in the knowledge base, team members should understand what is expected of them and the desired outcome.

However, with this approach to task definition, even an experienced specialist deeply involved in the project might miss important requirements or interpret them differently than originally intended.

Possible Risks:

· Developers and QA specialists spend more time resolving issues. Imagine a developer receiving a task with just a name. Before beginning to write code, they need to search for requirements in the knowledge base. If the requirements are poorly described, they'll need to consult with the analyst for clarification. Similarly, when the task reaches the QA engineer, they will follow the same process: researching requirements in the knowledge base and clarifying them with colleagues. This causes delays and distracts developers and QA engineers from their primary tasks.

· Tasks may be sent back for revisions. Without a detailed description and requirements, the developer may not fully understand what is expected, likely resulting in the task being returned for revisions. The task assigner will be asked to provide clarification.

· Dissatisfaction of business or users with the end result. When developers can't find complete requirement descriptions, they might implement the functionality as they interpret it. The QA specialist, while checking the result, relies on the developer's understanding of the task. This introduces the risk of delivering something different from what the customer or end users expect. Consequently, product refinement may be necessary, or the product's popularity might suffer due to subpar functionality, potentially resulting in the loss of users.

What to Do?

Discuss the task-setting process with your team. Explain to participants why it's crucial to provide detailed task descriptions consistently, even when the knowledge base already contains the necessary information.

When creating and formulating development tasks, consider the following key points in the description:

· Clear task name.

· Requirements for the functionality and performance of the product or system to be implemented.

· Links to design layouts and an architectural description, including structure, components, and their interactions.

· Testing and quality control requirements, including acceptance criteria.

· The specific list of items will vary depending on the project's specifics. It's advisable to discuss these within your team and establish a standardized task template.

Error 2: Insufficient Description of Previous Development Stages or Complete Absence

In some cases, projects lack a description of previous development stages, either partially or entirely. This means functions, components, and modules of the system have been developed without established requirements. This situation can occur in teams without a system analyst or during urgent development when descriptions are postponed to the backlog.

Possible Risks: The primary risk is regression bugs. When making improvements to such systems, developers may inadvertently disrupt critical parts of the program since it's challenging to assess the impact of changes on existing modules.

What to Do?

· Record all clarification questions regarding development and information on existing dependencies in the knowledge base. This reduces the time needed to address problems when they arise.

· If the project lacks requirements for individual modules and functionality, create separate tasks to describe them. Specify deadlines and responsible individuals.

Error 3: Assigning One Task to Multiple Teams

Occasionally, when developing a new feature, both backend and frontend teams are assigned a single task with a general description. This might seem convenient since all information is consolidated in one place. However, this approach has downsides.

Possible Risks:

· Challenges in defining metrics and task statuses. One team may complete its part of the work before the others, but the task cannot progress to the next status while other specialists are still working on it. This leads to time loss and project management difficulties.

· Violation of the principle of early testing. For example, a QA specialist may not notice that the backend developer has already completed their part of the work, and API testing can commence without waiting for the frontend work. This delays the early detection of bugs.

· Lack of essential details for implementing the required functionality. Such "general" tasks essentially replicate requirements from the knowledge base. Ideal tasks are specific and tailored to individual specialists, clearly defining what they need to do and how to do it, along with relevant links to requirements, layouts, and other necessary information.

What to Do?

· Create epics (in Agile terminology, these are large tasks that can be divided into smaller ones) and subtasks. The overarching task serves as the epic and contains subtasks for each team, each with a specific description tailored to the team's work.

· Monitor the status of all subtasks in the task tracker and adhere to the principle of early testing: each subtask can and should be tested as soon as it's ready, without waiting for the others. When all subtasks are ready and tested, the epic is transitioned to the "Ready for Testing" status and undergoes comprehensive testing.

Error 4: Development Without Analytics

Consider an extreme case: nearing the end of a sprint or just before release, an urgent task emerges. There's insufficient time to document requirements, and the developer begins implementation after discussing it with the technical team.

Possible Risks

1. Increased Time Spent on Problem-Solving: After development, when the task is handed over to a QA specialist, they might need to consult with the developer to understand the system changes. This can divert the developer from other tasks, causing delays.

2. Incorrect Implementation: Without proper requirements, the developer may misunderstand the team leader and client expectations, leading to erroneous functionality implementation, requiring subsequent corrections.

3. Production Bugs: Regression bugs, as discussed earlier, might be missed by both the developer and QA. These issues could emerge after the release, impacting specific functionality or the entire application.

4. Gap in System Description: Such tasks often go unrecorded in the knowledge base, potentially leading to testing and bug localization challenges down the line.

What to Do?

· Document All Requirements in Task Comments: If requirements are missing, consider the task incomplete and label it as technical debt until a comprehensive description is added to the knowledge base and verified for compliance.

· Involve a System Analyst: Task descriptions should be passed to a system analyst who can prepare detailed descriptions and conduct reviews, which will then be documented in the knowledge base.

Error 5: Insufficient Task Description for Analysts

Tasks for system analysts may be inadequately formulated, with brief or missing descriptions. Some tasks may only have a title, lacking details about requirements, responsible individuals, and other critical sections.

Possible Risks

1. Incorrect Task Estimations: Analysts cannot accurately estimate task completion time without a detailed description. For instance, updating existing development requirements might require significantly less time than creating requirements from scratch.

2. Integration Bugs: Analysts may overlook the interaction description of new code with adjacent systems, as this information wasn't specified in the task. This can lead to critical bugs surfacing post-release or during testing.

What to Do?

· Require Discussion with the Author: System analysts should discuss the task with the author before beginning work. Any additional information obtained during this discussion should be documented in the task description.

· Collaborate with Developer and QA: Prior to task commencement, discuss it with the developer and a QA specialist. This ensures that their input is considered during the requirement description phase rather than during implementation.

Error 6: Lack of Sources of Requirements

When a system analyst lacks knowledge about the business specifics and user preferences, they might incorrectly describe system logic and formulate development requirements.

What to Do?

· Engage a Consultant or Expert: Identify a client contact or industry expert for inquiries about business specifics. Conduct a preliminary meeting with this individual or department, emphasizing the importance of collaboration with the system analyst.

· Onboarding for Specialists: Conduct onboarding sessions to immerse specialists in the project's specifics, including goals, target audience, competitive advantages, and other nuances. The development team should grasp both the technical and business aspects of the product. To avoid extensive onboarding for everyone, add essential project and industry information to the knowledge base after client or expert approval.

Key Takeaways

In summary, here are the key takeaways:

· Detailed requirement descriptions save time and reduce IT product development costs.

· Failure to describe development stages can lead to regression bugs when new code interferes with existing code.

· A system analyst can mitigate risks by working on requirements and promptly documenting system descriptions in the knowledge base.

· The development team should possess knowledge not only of the technical aspects but also the business aspects, including the target audience, competitive differentiation, ultimate goals, and more.