This document describes the life cycle of a given task in the TyBugs project management software. A task is a single unit of work, and it may represent a defect report, a scheduled change, a leave period, a feature request, or any other discreetly trackable item. A task does not represent ongoing duties or responsibilities which have no fixed start or end date, and cannot be judged as complete in a discreet fashion.
The process for creating a task is always the same, however the handling of the task may vary depending on who is entering the task and what the task represents. This could be simplified into the following roles. It should be noted that these roles are stereotypes and that a given user will sometimes step outside their typical role due to the needs of the occasion.
- External Tester– Somebody who has the ability to assign tasks against a given project, but who generally has minimal visibility of existing tasks assigned against the project, or of the internal workings of the project team. The external tester’s tasks are often filtered for clarity and relevance, rather than taken at face value. The external tester may have priorities that vary from those of the project team. The external tester may or may not have access to “pre-release” versions of the product (ie. limited-distribution product releases for the purposes of testing.)
- Quality Assurance Team Member- A project team member who is primarily responsible for testing products prior to release. The QA team is responsible for systematic testing (to cover all areas of the product), ad hoc testing (to find problems that are not addressed by the formal test plan) and verification of fixed bugs (to ensure that the bug is actually fixed, and to ensure that the fix does not introduce additional problems in related parts of the product.)
- Development Team Member- A project team member who is primarily responsible for implementing new features and fixing known bugs. The development team will usually not create new tasks, but will instead complete existing tasks that they are assigned. In some cases, the development team may split tasks into a group of related sub-tasks, or add new tasks recommending future work related to their findings on their current work task.
- Build Engineer- The person responsible for product builds for a particular product. This person may be instructed to create builds on a regular schedule, on a trigger condition, or on demand. This person may introduce new tasks if a build failure needs addressing by the development team, but generally provides a transformative function for existing tasks.
Each team for a product will typically have some formal representative, whether a full-time manager or a “first among equals”. This person is responsible for presenting the team’s needs to other teams, and for accepting process change requests from other teams. This person is also responsible for ensuring that their team follows any formal policies that have been agreed upon.
- The External Test Manager is responsible for the External Testers, and ensures that they have the necessary information to focus their testing efforts. This person is also responsible, where necessary, for the process of filtering incoming tasks from the External Testers.
- The Quality Assurance Team Lead is responsible for maintaining the formal test plan, for ensuring that the QA team maintains a high standard of reporting, and for ensuring that testing tasks are processed in a timely fashion (ie. that important tasks are tackled quickly, and that less important tasks are not left to rot.)
- The Development Team Lead is responsible for ensuring that work tasks are assigned to appropriate development team members, and that the scheduled tasks are completed in a timely fashion. Where particular types of tasks or particular team members form a regular problem, it is the development team lead’s responsibility to work with the team members to improve performance, and work with the Project Manager to ensure realistic expectations. This person is also ultimately responsible with providing the Quality Assurance team with any information, builds and services required for them to carry out their testing function.
Creation of a Task
With the above roles in mind, tasks then typically flow from the following sources:
- Bugs and feature requests entered by external parties.
- Bugs and enhancement requests entered by the Quality Assurance team.
- High-level tasks introduced by internal design functions (a design team, team design meetings, individual responsibilities, etc.)
- Architectural tasks introduced by the development team lead in order to support high-level goals.
- Bug reports from development team members.
- Lower-level tasks introduced by the development team lead when providing a work breakdown for a high-level task.
- Lower-level tasks introduced by the development team members when an assigned task can be further broken down.
In the case of bug reports or functionality requests, these tasks flow to a single “incoming” pool of tasks. In the case of tasks entered by external testers, the tasks may be filtered by the External Test Manager prior to entering the “incoming” pool.
In the case of tasks which result directly from the breakdown of an existing task, the new tasks should be initially assigned directly to the person who was responsible for the parent task.
Processing of Incoming Tasks
As tasks enter the system and make their way to the “incoming” pool of tasks, someone must be responsible for deciding what to do with the task. Specifically, the person must be able to answer the following types of question:
- How relevant is this task to our projects in the short term?
- How relevant is this task to our projects in the long term?
- How time consuming is this task likely to be?
- Do we have enough information to make these decisions?
- Does this task represent a fundamental shift of direction?
- Who is responsible for completing this task?
The answers do not need to be explicit, or completely accurate, but the responsible person must have both the knowledge and the authority to be able to make these kinds of judgement call. If there are cases where the person does not have sufficient knowledge or authority, there needs to be a clear technique for escalating the issue (ie. to a higher-level manager, to the design team, etc.)
In the case where a task is not clearly worded, key information is missing, or the wording is such that significant additional work is likely necessary in order to clarify the task, the responsible person should generally send the task back to the originator for additional clarification, or forward the task to the Quality Assurance team in order to narrow down the task parameters.
In cases where the task has substantially low relevance to the project in the near-to-medium term, the responsible person should consider whether to reject the task, or to place it into a holding pool.
Finally, all tasks which are to be processed should be forwarded to the relevant team members or (where appropriate) their managers.
Tasks are considered rejected if they are marked as “Complete” in all branches in which they exist. This can occur during early filtering if it is determined that the task is somehow invalid or does not match the project goals. This can also occur later in the life-cycle of the task if it is determined that the original report was in error, or if a work request is being cancelled for any reason.
A valid bug report which is fixed (either as a result of the task, or prior to the task being undertaken) should not be marked as rejected in this fashion. Instead, it should be left as “open” in the branch in which it was reported, and marked “complete” in the appropriate later branch. If the fix branch is unknown, the task should be marked “complete” in the branch in which it was tested and determined as fixed. If the task was marked complete based on an assumption that it was already fixed as the result of some other change, then it should be marked “complete” in the branch containing that change, or in the very latest branch of the product if the details of the fix are not known. It is better to have some product versions incorrectly marked as faulty, rather than have some product versions incorrectly marked as fixed.
Break-down of Tasks
When a task is received for work, it should first be broken into smaller sub-tasks if appropriate. This allows the sub-tasks to be tracked individually, helps ensure that individual components of the task are not overlooked, and potentially allows the task to be split over several resources.
It is typically the team manager’s role to break down tasks before assigning them to the individual team members, however this does not prevent team members from further breaking down the tasks if appropriate. Generally speaking, initial duration estimates and priorities should be provided during the first complete breakdown. This allows scheduling to operate prior to the final assignment of tasks. Dependencies should also be set correctly during the breakdown so that the subtasks are correctly attributed as required for their parent task completion.
All users of the TyBugs system should work through their assigned tasks in the order specified by the Gantt chart. The team leads are responsible for ensuring that this is practiced. Additionally, all discreet work tasks should be added as tasks in TyBugs.
The nature of work on a particular task depends on the reason for the assignment and to whom the task was assigned. If a comment was made during the task assignment, then the receiver should consider that comment before proceeding with any work. This may often be a request for clarification (rather than a request to work on the task itself) or instructions which modify how the receiver should process the task. The receiver may also wish to check the task history if it is clear that a number of users have had input on the task.
In the absence of any special instructions, the task should be processed on its face value. If appropriate, the task should be broken down into sub-tasks. Team leads should pass tasks to their team where appropriate.
If no duration estimate is provided for a task, the next action should be to provide a duration estimate. It is understood that the initial estimate is not a guarantee of duration, but rather an educated guess at how long the task should take to complete under normal conditions. The act of assigning a duration may cause the task to be rescheduled. Duration estimates should always err on the side of caution, since they cannot take into account any unexpected interruptions or delays. There are always unexpected interruptions and delays.
Where the first task on a user’s schedule cannot be processed for some reason, the user needs to ensure that the task is moved from their schedule in some fashion. In the event that a task has an unstated dependency, the dependency should be added to the task. This should suffice to push the task away from being the first on the schedule. Arbitrary dependencies must not be used as a technique for pushing an unwanted task further back in the schedule.
Unless otherwise specified, the user should undertake the work in the latest version of the branch in which the task was raised. When work is completed (and any changes are submitted to source control, if appropriate) the user should mark the task as “complete” in the latest version of the branch in which it was completed. The task should then be assigned to “<nobody>“, or to a specific user if that particular user is known to be particularly relevant (ie. a development team member may assign a fixed task to another development team member who requested the task and who has the domain-specific knowledge relevant to verify the changes.)
If the task is already marked completed, and is assigned for testing, then the work involved is simply to test the task. In this case, the tester should mark the task as “Verified Complete” if the change was successful, or “Re-opened” if the change was not successful.The task should then be assigned to “<nobody>”.
Requests for Clarification
If it is found that a task is lacking some key information, or that the expectations are not fully clear, the receiver may opt to either:
1. Reassign the task to another user for further clarification, and request that they assign it back. This is suitable for quick clarifications of small incoming tasks where the task is not part of a detailed schedule.
2. Create a dependency task, assigned to another user, requesting that they provide clarification on the original task. This is preferred since it provides more accurate scheduling details.
Testing of Completed Tasks
Completed tasks that are assigned to a particular user are handled as described above. Completed tasks that are assigned to “<nobody>” are handled by the QA team processes, such as:
- Testing of completed tasks as product builds are completed. Each completed build should be tested to ensure that tasks marked as “complete” in that branch are actually complete.
- Testing of completed tasks which remain untested from earlier versions of a product. This should not be necessary under normal usage, but may become necessary if the QA team has previously been unable to keep up with the testing workload.
- Testing of outstanding completed tasks not associated with a product. This should not be necessary under normal usage.
The tester should mark the task as “Verified Complete” if the change was successful, or “Re-opened” if the change was not successful.The task should then be assigned to “<nobody>”.
In some scenarios, it may not be possible to test a particular task in a particular branch. This may result when a fix is integrated into a branch but the functionality is not expressed in that branch. In this scenario, the QA team should ignore the task. Once the fix is verified in a more appropriate branch, the verified status will eventually propagate to all branches and result in the bugs no longer showing as “Unverified“. While it may seem logical to remove the branch assignment from such tasks, this can be counter-productive, as further integrations from the branch in question may lead to the task being moved into a branch where it is again expressed. If the branch assignment was removed, this would result in all downstream branches having no visibility of the task, regardless of whether or not they express the behaviour.
+ Assigned To: <nobody>
+ Dependencies: 0
+ Status: !Complete