SDLC Tasks
Creation, processing, and monitoring the tasks are the basic activities ensuring the progress of software development. A task is the main entity of the whole development process since it contains information about the requriements to the responsible person, work progress, and result.
Access to tasks
| Operation | pda_admin | pda_user | Other roles |
|---|---|---|---|
| Create | + | The operation is allowed but the user can only fill in the Project field with the projects in which they are a team member or a team leader. | - |
| Write | + | The operation is allowed for any user with the role, if the Project field is empty. If the Project field is filled in, allowed for:
If the field Product or Product module is filled in, allowed for the product and product module owner. The user can only select a project where they are a team member or a team leader. | - |
| Read | + | + | |
| Delete | + | Allowed for the team leader of the project to which the task is related. | - |
Task types
Depending on the complexity of the project, selected approach and the workflow peculiarities, you can use various task types. The SDLC application offers the following task types out of the box:
| Task type | Description |
|---|---|
| Epic | This task type involves substantial amount of work. It includes one or more features and describes business requirements of the solution. |
| Feature | This is a considerable amount of work that results in the implementation of a certain product functionality. It includes one or more user stories and describes a business requirement the solution covers. |
| User story | This is a task that contains the requirements given from the consumer's perspective. |
| General task | This is a universal task type that can be divided into subtasks. |
| Defect | This is an error that needs to be fixed. The defects can exist independently or be related to an epic or a feature. |
| Subtask | This is a special task type used for the workload decomposition. The subtasks are always subservient to tasks of other types. |
Task types hierarchy
- The 1st and 2nd level tasks are the product level tasks. They are added by a product owner or team leader if the project is dedicated to a product.
- The 3rd level tasks are the project level tasks. They are implemented by the project team and may be included in the 1st and 2nd level tasks.
- The 4th level tasks are subtasks used for the decomposition of higher level tasks.
Create a task
To create a task, complete the following steps:
- Find the required task type in the SDLC → Tasks section of the navigator. Open the list for the required task type.
- Click New and fill in the form fields.
- Click Save or Save and exit to apply the changes.
You can also create new tasks in the backlog management widget (for Kanban projects) or sprint planning widget (for Scrum projects).
Task form fields
- General
- Additional
- Developer Panel
| Field | Mandatory | Description |
|---|---|---|
| Name | Y | Specify the task title. |
| State | N | Select the task state. The available options vary depending on the current task state. The field appears after saving the record and is automatically filled in with New. |
| Blocked | N | Select the checkbox to prohibit the transition of task to another state. When the checkbox is selected, the State field is read-only and the task card cannot be dragged between the columns. The field appears after saving the record. |
| Parent task | N | Specify a higher level task that includes this task. Depending on the type of the created task, the following types are available for selection:
The field is not available for Epics. |
| Priority | N | Specify the task priority. Available options:
|
| Rank | Y | Specify the task rank. The lower the rank is, the higher the task priority is. The field is not available for Subtasks. |
| Description | N | Add the task description. |
| Assigned to | N | Specify the employee responsible for the task. |
| Work notes | N | Add work notes. |
| As a | Y | Specify the consumer of the functionality that will be implemented in the User story. The field is available only for User stories. |
| I want | Y | Describe the functionality that will be implemented in the User story. The field is available only for User stories. |
| So that | Y | Specify the consumer pains that will be solved by the functionality implemented in the User story. The field is available only for User stories. |
| Acceptance criteria | Y | Specify the parameters that the task must comply with to be considered completed. The field is available only for Features and User stories. |
The tab is not available for the Subtasks.
| Field | Mandatory | Description |
|---|---|---|
| Project | N | Specify the project to which the task belongs. |
| Release | N | Specify the release that will include the task result. The field is only available for the tasks related to the projects dedicated to product development (the Product development checkbox is selected on the project form). |
| Product | Y | Specify the product to which the task is related. The field is only available for the tasks related to the projects dedicated to product development (the Product development checkbox is selected on the project form). |
| Product module | N | Specify the product module to which the task is related. The field is only available for the tasks related to the projects dedicated to product development (the Product development checkbox is selected on the project form). |
| Detected in release | N | Specify the release in which the defect was found. The field is only available for Defects. |
| Sprint | N | Specify the sprint that includes the task. The field appears only if the task belongs to a Scrum project. The field is not available for Subtasks. You cannot change the value of the field for the Released and Canceled tasks. |
| Story points | N | Estimate the task in story points – standard units of task complexity, amount of work and involved risks. The field appears only if the task belongs to a Scrum project. |
| Planned time to spend | N | Specify the planned amount of time required to complete the task. The field is located on the General tab on the Subtask form. |
This section contains the data on the current task received from the Git integration module. Read the detailed description of the panel in the Developer Panel article.
Several related lists are located on the task forms.
For Epics and Features:
- Child Tasks – the list of tasks for which the current task is the parent task.
For the tasks of all types except for Subtasks:
- Subtasks – the list of subtasks related to this task.
Tasks state model
The life cycles of all task types, except for Subtasks, are identical by default for the facilitation of the workflow.
If necessary, you can customize the SDLC Task and Subtask state models.
SDLC task state flow
Task states description
| State | Description | Available transitions |
|---|---|---|
| New | The task is added. |
|
| Backlog | The task was added to the backlog and can be taken to work. |
|
| Development | The assigned user started working on the task. |
|
| Review | The work on the task is completed. |
|
| Testing | The task is currently in testing. |
|
| Done | The task is completed and ready for release. |
|
| Released | The task is included in a released version. The state is assigned automatically after the release of the version that includes the task. | |
| Canceled | The task was canceled. |
Subtask state flow
Subtask states description
| State | Description | Available transitions |
|---|---|---|
| New | The subtask has been created. |
|
| In progress | The assigned user has started working on the subtask. |
|
| Done | The subtask has been completed. | |
| Canceled | The subtask has been canceled. |
History of task state changes
You can see the time spent by the task in each state in the SDLC application. To do so, open the SDLC Task State Changes (pda_task_state_history) table. Use that data to create the reports illustrating the work progress on the tasks.
All users with access to SDLC can read this table. Nobody can create records from the form, update, and delete them.
SDLC Task State Change form fields
| Field | Description |
|---|---|
| SDLC task | The task the change of which is logged in the record. |
| Project | The project for which the change is logged. If the task project changes, the value contains the previous project. If the project was not specified for the task when the change record was created (before the change), the field is empty. |
| Previous state | The task state the time in which is logged in the record. |
| Current state | The task state after the change that triggered the creation of the record. |
| Period start | The date and time when the task moved to the Previous state in the specified Project, or when the Project was changed for the task. If this is the first change record for the task, the field value equals the date and time of the task creation. |
| Period end | The date and time when the task moved to the Current state in the specified Project, or left the project if the current and previous states are the same. |
| Time in state | The time that passed between the Period start and Period end. It shows the time spent by the task in the Previous state in the specified Project. |
New records are created automatically when:
- the value of the Project field changes for the task.
- the value of the State field changes for the task.
- the values of both Project and State fields change for the task.
The records are created for each project, which means that each record shows the time spent by the task in a specific state in one project. The table below contains examples of cases that can trigger the creation of a change record. Each tab corresponds to fields the changes of which were the trigger, and illustrates the values of the change record fields in such a case.
- State changed
- Project changed
- State and Project changed
The task spent one hour in the Backlog state in Project 1 and moved to the In progress state in the same project.
| Field | Value |
|---|---|
| Project | Project 1 |
| Current state | In progress |
| Previous state | Backlog |
The task spent one hour in the Backlog state in Project 1 and moved to Project 2 in the same state.
| Field | Value |
|---|---|
| Project | Project 1 |
| Current state | Backlog |
| Previous state | Backlog |
The task spent one hour in the Backlog state in Project 1 and moved to Project 2 in the In progress state.
| Field | Value |
|---|---|
| Project | Project 1 |
| Current state | In progress |
| Previous state | Backlog |